Preparing the kernel for UEFI secure boot [LWN.net]

Preparing the kernel for UEFI secure boot

Posted Sep 11, 2012 10:22 UTC (Tue) by intgr (subscriber, #39733)
In reply to: Preparing the kernel for UEFI secure boot by jpfrancois
Parent article: Preparing the kernel for UEFI secure boot

> Going mainline is not an option for low volume independent hardware vendor.

I'm surprised to hear this from an LWN reader. Surely the cost of maintaining an out-of-tree driver for years to come is greater than spending the one-time effort to get it merged, and then minimal QA in the future to make sure it still works?

Greg Kroah-Hartman has been trying hard to dispel this myth for more than half a decade. Linux contains support for lots of exotic devices and that have maybe a dozen users worldwide.

See for example http://www.kroah.com/log/linux/ols_2006_keynote.html

> "My driver is only for an obscure piece of hardware, it would never be accepted

> This just is not true at all. We have a whole sub-architecture that only has 2 users in the world out there. We have drivers that I know have only one user, as there was only one piece of hardware ever made for it. It just isn't true, we will take drivers for anything into our tree, as we really want it.

(Log in to post comments)

Preparing the kernel for UEFI secure boot

Posted Sep 11, 2012 11:21 UTC (Tue) by jpfrancois (subscriber, #65948) [Link]

This is not the cost of mainlining, but :
overlap with existing driver.
inclusion of features that do not belong in the hardware.

For instance, I doubt you could convince a V4L2 maintainer that a driver doing BGGR to UYVY (ie format conversion) inside the driver is appropriate, and they would be right, this is not a good technical solution, the right thing to do is do the postprocessing in userspace.

However we have a customer with a lot of existing code using UYVY format, and for some reason, they don't think they can introduce soft debayering in these existing tools. So we provide a hack that as legitimately no place in mainline

Even without this unusual use case, not an option does not mean "won't be accepeted in mainline" but not interesting because :
-not flexible enough
-time to market (and time to bugfix / new feature)
-uncertain cost / benefice ratio.

In fact, distro balkanization is a problem that can be easily avoided by distributing the source instead of the binary. UEFI is potentially a huge hurdle to module source distribution. However according to M Garett :

"We're planning on using Suse's approach of permitting local key management at the shim level, and I spent some time discussing this with Vojtech last week. In combination with the above, this should provide a workable mechanism for permitting the end-user to install module signing keys. "

So it seems out of tree module will remain a possibility.