kernel ebuild that backports a driver

[Luigi Semenzato]

What's the recommended way of writing an overlay-specific kernel ebuild which simply replaces and adds files from a newer kernel version?

The standard way is to put patches in files/*.patch, and I found nothing else in cros-kernel2.eclass.  Patches work, but hide the fact that the files are completely clobbered (or added).  Is it worth writing a bit of machinery in src_prepare to allow copying files?

Or maybe patches are better because they won't apply if the original sources change, and it's better to be aware of that?

Thanks!

[Mike Frysinger]

there is no support for this other than patches in files/ as you found.  even that is not really recommended and is largely used for POC devices that haven't finished merging yet.  it's all GPL code, so of course it's going to be public.

if you intend on the drivers/changes to be long lived, better to talk to the kernel team about merging the patches directly.

-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev

[Dominik Behr]

Luigi, we are backporting drivers and even entire subsystems (like I did with DRM for AMD in kernel 4.14) from newer kernels all the time. Just commit it to the kernel. We only temporarily use kernel ebuilds in board overlay with few custom patch files.

For particularly large backports we do so called "forklifts" where we put all the changes into a branch and we submit it as merge commits.

The rules are, all changes need to be rebased on top of our current kernel and bisectable, and tagged with appropriate tag (UPSTREAM, BACKPORT, FROMGIT/FROMLIST).

So, just backport this driver. Sean's kernel patch review script will tell you if you do anything wrong ;-)

Also, sync with the appropriate team if you touch their area of responsibility. Which driver do you want to backport?

Also, consider just moving your board to a newer kernel. We have 6.1 now you can use. It is as easy as changing use flags for your board.

[Luigi Semenzato]

Thank you for confirming and for the advice.  I am seeing that another overlay uses that module in that kernel version, so I may have to be a bit careful (i.e. not do it).

I could also try switching to the newer kernel.  But IIRC that could be a lot of work, and hard to predict how much.

[Luigi Semenzato]

Thanks!  I need to do this for the USB_F_UAC2 module (CONFIG_USB_F_UAC2), backporting from 6.1 to 5.4.  There is another user of that module in 5.4 in the private overlays.  I'll see what the owners of that kernel think.  Also thank you for encouraging me to look into uprevving the kernel!

[ggg]

On Wednesday, May 10, 2023 at 5:19:21 PM UTC-7 seme...@google.com wrote:

What's the recommended way of writing an overlay-specific kernel ebuild which simply replaces and adds files from a newer kernel version?

The standard way is to put patches in files/*.patch, and I found nothing else in cros-kernel2.eclass.  Patches work, but hide the fact that the files are completely clobbered (or added).

The "commit" message of the patch can explain the entire file is being replaced (and explain why). This fact doesn't need to be hidden.

But the hurdle is getting any other Chrome OS kernel dev to look into the ebuild for the patches in the first place. Since we have local chromeos-X.Y branches in a public git repo, Kernel devs (like me) assume all changes are directly applied to the public repo. 

 

  Is it worth writing a bit of machinery in src_prepare to allow copying files?

Or maybe patches are better because they won't apply if the original sources change, and it's better to be aware of that?

I think it depends on the patch and how long it needs to be supported. For short term stuff (less than a year), yes, being aware of changes and maintaining the patch is a good idea. For longer term, the maintenance cost is likely to climb the older the kernel (and change) gets - especially if the kernel dev moves on to something else and stops maintaining the patch. So what Mike said.

And one nit with Mike's comment:

> it's all GPL code, so of course it's going to be public.

IANAL: AFAIK, Kernel source is not "all GPL code".  Most files/drivers are GPL but some are BSD (or both). BSD can be public but doesn't have to be. The problem is we (as kernel devs) can't authoritatively tell from the license header in the file.

Do I like this? No. I strongly prefer GPL and committing anything (BSD or GPL) to our public git repo is naturally public.

cheers,

grant

Thanks!

[Luigi Semenzato]

Thank you Grant.  Yes good point on visibility.  Hopefully whoever works on this project will understand they need to look at the overlay.  There are changes to the .config too.

[Mike Frysinger]

On Thu, May 11, 2023 at 12:49 PM ggg <grun...@chromium.org> wrote:

And one nit with Mike's comment:

> it's all GPL code, so of course it's going to be public.

IANAL: AFAIK, Kernel source is not "all GPL code".  Most files/drivers are GPL but some are BSD (or both). BSD can be public but doesn't have to be. The problem is we (as kernel devs) can't authoritatively tell from the license header in the file.

the kernel, when put out as a binary, is a combined work.

it's also simply the morale thing to do as an open source project.

-mike