[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Kernel Modules in Fedora -x



On 8/3/07, Kelly <lightsolphoenix gmail com> wrote:
> And this is why IMO non-kernel-packaged modules should be provided as plugins
> to DKMS.  Then you don't have the "you have to repackage the modules after
> every kernel update" problem, because DKMS will do it automatically upon
> restart.  And since this is for modules NOT considered "important" (as in,
> they wouldn't serve any real purpose in the main kernel), I don't see why
> having a dependency on the build tools is so bad.

the fact that dkms itself doesn't depend on the build tools as
packaged already sort of already speaks to the issue of making dkms
payloads explicitly require gcc and friends.  Forget about making them
depend on build tools its only complicating the argument you really
want to make.  Just argue for things that depend on dkms in to fedora
sans any mention of build tools requirement. Anyone who wants to use
dkms can install the build tools needed to rebuild dkms payloads on
their own.

The question that needs to be asked and answers is this:
Is there room in the baseline Fedora repository for dkms enabled
payloads or not?

I'm all in favor of the upstream mantra, but I have to wonder, could
dkms payloads be part of a multi-step mechanism that Fedora could use
to try to help the upstreaming of out-of-tree modules? Can we have a
process where out-of-tree stuff shows up first as dkms enabled
payloads, that do not do anything out of the box, that expert users
can use and report bugs against and whatnot? And then from there
establish the upstreaming dialog that allows the module to be moved
into the fedora kernel package once its clear there is a dedicated
maintainer who is going to champion the upstreaming cause?

If a timeout clock on out-of-tree kernel modules in our kernel package
is an icky idea for some people. Would a timeout on dkms payloads in
fedora be less-repugnant?

I'd like to see a way that we could play around with experimental
stuff for a limited time, and then for the items that have
maintainership momentum towards upstream we make a longer term
commitment and include it in the kernel tree while the upstreaming
finalizes.  I think limited time (aka deadman walking)  dkms payloads
might make be that first experimental step, especially if they do not
work out of the box to draw a clear expectation boundary for
end-users.  "This doesn't work out of the box, because these are
experimental and we want help getting them in shape for inclusion in
the mainline kernel."

Or is dkms only being included in the repo for do-it-yourself end-user
convenience?  Since we are shipping it it would be nice if we could
leverage it as part of an upstreaming process.

thoughts?

-jef


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]