From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gfRDn-0005xt-3o for qemu-devel@nongnu.org; Fri, 04 Jan 2019 10:17:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gfRDj-00078M-W3 for qemu-devel@nongnu.org; Fri, 04 Jan 2019 10:17:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58128) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gfRDj-00077l-Mx for qemu-devel@nongnu.org; Fri, 04 Jan 2019 10:17:11 -0500 Date: Fri, 4 Jan 2019 10:17:09 -0500 From: "Michael S. Tsirkin" Message-ID: <20190104101326-mutt-send-email-mst@kernel.org> References: <20190103175113.18196-1-pbonzini@redhat.com> <20190103130406-mutt-send-email-mst@kernel.org> <714a115f-835b-0041-426b-d16f9439ebc1@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <714a115f-835b-0041-426b-d16f9439ebc1@redhat.com> Subject: Re: [Qemu-devel] [PATCH] include: update Linux headers to 4.21/5.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , Cornelia Huck , QEMU Developers 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 wrote: > >> > >> On Thu, Jan 03, 2019 at 06:51:13PM +0100, Paolo Bonzini wrote: > >>> Signed-off-by: Paolo Bonzini > >> > >> 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 > >