Re: [Qemu-devel] [PATCH] include: update Linux headers to 4.21/5.0

[Paolo Bonzini]

On 03/01/19 20:26, Peter Maydell wrote:
> On Thu, 3 Jan 2019 at 18:19, Michael S. Tsirkin <address@hidden> wrote:
>>
>> On Thu, Jan 03, 2019 at 06:51:13PM +0100, Paolo Bonzini wrote:
>>> Signed-off-by: Paolo Bonzini <address@hidden>
>>
>> Note that in the past we just updated what we needed.
> 
> Not if I noticed it -- our copies of the Linux headers
> are supposed to always be synchronized entirely from
> a commit of Linux upstream master. Ad-hoc cherry-picked
> changes can easily be accidentally undone by a later sync
> by somebody else. This is why we have an automatic
> script to do header synchronization, so we don't have
> to manually write and review header updates.

I agree, and shortlog seems to agree too in general.  Most commits look like

      linux-headers: Update to v3.10-rc5
      linux-headers: update to 3.11
      linux-headers: Update to 4.2-rc1
      linux-headers: sync against v4.14-rc1
      linux-headers: update to 3.12-rc1
      linux-headers: update to 3.18-rc5
      update linux headers to kvm/next
      synchronize Linux headers to 4.0-rc3
      linux-headers: update to 4.13-rc0
      linux header sync against v4.13-rc1

and so on.


>> I'd prefer the shell script part and the new vhost_types header which
>> are actually reviewable to be split out to a separate patch.
> 
> I agree that shell script changes should be their own patch.
> My view is that a header-update commit should be entirely
> and nothing but the automatically generated results of
> running scripts/update-linux-headers.sh, with a commit
> message that says "Generated by running update-linux-headers.sh
> on upstream kernel commit xxxx".

The problem with this approach is that the old script does not work with
the new commit and the new script does not work with the old commit.
Doing the update in the same commit as the script update means that it's
clear from the commit message on which Linux commit you should run it
(though in this case I should have specified 4.21-rc1 or 5.0-rc1).

Another way would be to make Linux a submodule.  Then you'd upgrade the
submodule and the script in one commit, and then generate the headers at
compile-time or release-time.  This however wouldn't be as nice for
users of the git repo.  That's the reason why I went for the single
commit, but of course I can split it and will in v2.

Paolo

> Doing by-hand updates to the headers is quite a common
> error; I'm not sure if we can automatically catch it
> with checkpatch. ("Any change to include/standard-headers
> or linux-headers/ must be a commit that touches only files
> in those subdirectories and whose commit message is in
> a standard format", perhaps.)
> 
> thanks
> -- PMM
>