[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] include: update Linux headers to 4.21/5.0
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] [PATCH] include: update Linux headers to 4.21/5.0 |
Date: |
Fri, 4 Jan 2019 09:38:50 +0100 |
On Fri, 4 Jan 2019 09:07:23 +0100
Paolo Bonzini <address@hidden> wrote:
> On 03/01/19 20:26, Peter Maydell wrote:
> > On Thu, 3 Jan 2019 at 18:19, Michael S. Tsirkin <address@hidden> wrote:
> >> 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).
In this case, just note that in the change log? I'd prefer to do it in
a single commit if there are dependencies.
> 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.
TBH: Just say no to that submodule idea :)
The need to adapt the script is rare enough for a simple note in the
change log to be sufficient if the change can't be split out.