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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
