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 <m...@redhat.com> wrote:
> >>
> >> On Thu, Jan 03, 2019 at 06:51:13PM +0100, Paolo Bonzini wrote:
> >>> Signed-off-by: Paolo Bonzini <pbonz...@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
> >
