[libcamera-devel] [PATCH 01/13] include: linux: Update kernel headers to version v5.19

[Kieran Bingham]

Quoting Kieran Bingham (2022-08-02 13:52:43)
> Quoting Laurent Pinchart via libcamera-devel (2022-08-02 11:21:23)
> > Hi Jacopo,
> > 
> > On Tue, Aug 02, 2022 at 09:52:08AM +0200, Jacopo Mondi wrote:
> > > On Mon, Aug 01, 2022 at 10:47:04PM +0300, Laurent Pinchart wrote:
> > > > On Mon, Aug 01, 2022 at 05:16:29PM +0200, Jacopo Mondi wrote:
> > > > > On Mon, Aug 01, 2022 at 03:05:31AM +0300, Laurent Pinchart via libcamera-devel wrote:
> > > > > > Update kernel headers to v5.19 using utils/update-kernel-headers.sh and
> > > > > > re-instating libcamera local modifications.
> > > > >
> > > > > Don't we need something better than this ?
> > > > >
> > > > > should we regularly rebase the libcamera-changes on top of a new
> > > > > header export per each kernel release ?
> > > > >
> > > > > Otherwise updating headers and re-applying the local modifications in
> > > > > one go makes it impossible to actually track what's local and what's
> > > > > upstream ?
> > > >
> > > > This patch was possibly easier to generate than it is to review. The
> > > > update-kernel-headers.sh script undoes all the local changes, and I've
> > > > then used git add -p to avoid picking up the reverts. This is a manual
> > > > process that can lead to errors.
> > > 
> > > The error-proness is what I'm concerned with
> > > 
> > > > On the review side, it's really about making sure that the update
> > > > doesn't drop any of the features we depend on. It may seem error-prone
> > > > too, but most (not all though) of the local changes we carry will be
> > > > detected at compilation time of reverted.
> > > 
> > > True that
> > > 
> > > > The best way to avoid all this is of course to upstream all the changes,
> > > > and that's something we keep working on, with various delays depending
> > > > on the features. For instance, patches 02/13 and 03/13 in this series
> > > > will effectively disappear once we upgrade to the v5.20 kernel headers.
> > > > Other changes take longer to upstream.
> > > >
> > > > I'm open to other ideas to improve the process, but completely
> > > > overwriting the headers and then reapplying local changes on top will
> > > > break compilation during bisection.
> > > 
> > > I can only suggest to do that on the side and compare the output.
> > > But that's a suggestion for review more than for development.
> > 
> > We could indeed post the change as two patches, one that overwrites
> > everything, and the second one that reapplies our local changes, and
> > squash when pushing.
> 
> I wouldn't even squash. We could simply keep re-cherry-picking the
> add-on commits. That would make it clear that the import overwrites the
> additions, and then we clearly bring them back in reviewable chunks 'on
> top' of the latest kernel headers.

Argh, except that would break compilation bisectability ... so yes, we
would have to squash them :-(