Re: Kernel Modules in Fedora -x

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

 



On Fri, 3 Aug 2007 13:25:38 -0800
"Jeff Spaleta" <jspaleta@xxxxxxxxx> wrote:

> On 8/3/07, Kelly <lightsolphoenix@xxxxxxxxx> 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?

I think we are thinking of similar things, but to be sure I'll ask this
question:

By DKMS payloads, are you referring to DKMS-packaged source RPMs for
the modules in question?  So that a user would install dkms-foo-mod and
then use dkms to build and install it?

josh

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux