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

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Jan 04, 2019 at 09:07:23AM +0100, Paolo Bonzini wrote:
> On 03/01/19 20:26, Peter Maydell wrote:
> > On Thu, 3 Jan 2019 at 18:19, Michael S. Tsirkin <mst@redhat.com> wrote:
> >>
> >> On Thu, Jan 03, 2019 at 06:51:13PM +0100, Paolo Bonzini wrote:
> >>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> >>
> >> 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.

I would do

update-linux-headers.sh: add support for Linux 4.21-rc1

Since 4.21-rc1 header abc moved from foo/ to bar/ update
script accordingly.

---

linux-headers: update to 4.21-rc1

Generated by running update-linux-headers.sh on upstream kernel commit xxxx



> 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
> >