kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting)

[Thorsten Leemhuis]

On 06.09.2007 20:43, Jeff Spaleta wrote:
>>> The complexity of separately-packaged kernel modules is unnecessary, and the users' problems with upgrading when the modules are not built synchronously with the kernel will no longer be possible.
>> Same for dkms, as modules might break if the api changed.
> 
> slightly less complex for dkms, because with dkms you don't have to
> deal with synchronously building the modules on the central build
> system.

Yeah -- so we offload the trouble to the user. And that's not the right
thing to do IMHO. We should provide pre-compiled kernel-modules if we
want to ship kernel-modules. dkms optional for that that want it: sure.

But the signals from FESCo are afaics: no kernel-modules at all. And I
think that's the right thing to do in the merged Fedora world.

> [...]
> I think dkms works as a piece of technology as far as it can. The
> question really is, would providing dkms source payloads in Fedora
> help drive mainlining of kernel modules or does it discourage the
> necessary upstream discussions.

It would, just as kmods do -- that's why we put a high entry-burden for
kernel modules in Extras, and that's the reason why there are only two,
and that's the reasons why we didn't work further on getting kmods
automatically build when a new kernel gets shipped.

>  If providing dkms source payloads can
> help move things into upstream via feedback, then I'm all for it. But
> if its just going to be a way for people to get around the hard work
> of getting a module upstreamed, then I'm not for it.

>From http://lwn.net/Articles/248195/ (subscriber only ATM)

[...]a really bad driver can create obscure problems all over the
kernel. But the fact of the matter is that an ugly driver is more likely
to be fixed in-tree than out. Linus asserted that anytime a distributor
ships an out-of-tree driver, the process has failed. [...]

Further: to avoid that driver authors "get around the hard work of
getting a module upstreamed" was exactly the reasons why we put such a
high entry burden for kmods into Fedora . The policy is still there at
http://fedoraproject.org/wiki/Extras/GetKernelModulesUpstream
and that shouldn't be altered just because we use a different packaging
standard for modules now; if we want to alter it we can continue with an
improved version of kmods or kmdls (that afaics both Axel and I are
working on); we should just ban kernel modules completely, as dwmw2
proposed.

> Which is why I'd
> be interested in setting an explicit expiration date for any dkms
> payload.

Been there, discussed that multiple times already and chose to not go
that route every time because that creates even more trouble for users
"Hey, foo was supported in F7 and F8, why isn't it anymore in F10 and
F11? Fedora is so stupid, I switch to foo instead!".

CU
knurd