3:01 p.m.
I'd like to just do a brief poll here just to see how many are yay or
nay for kmods. And I'm not talking about their current implementation
or the other various ways that the idea can be accomplished, but rather
on the idea of having kernel modules as separate packages in general.
If you're against the general idea and want to follow up with reasons
why that's fine. I just want to avoid implementation discussions at the
moment if possible.
josh
3:07 p.m.
Josh Boyer wrote:
I'd like to just do a brief poll here just to see how many are
yay or
nay for kmods. And I'm not talking about their current implementation
or the other various ways that the idea can be accomplished, but rather
on the idea of having kernel modules as separate packages in general.
If you're against the general idea and want to follow up with reasons
why that's fine. I just want to avoid implementation discussions at the
moment if possible.
Yay. They're a source of great pain and suffering, but a necessary evil
in some cases to make a few applications (such as a certain open-source
{p,d}vr) more accessible to the masses.
--
Jarod Wilson
jwilson(a)redhat.com
3:21 p.m.
On 06/19/2007 04:01 PM, Josh Boyer wrote:
I'd like to just do a brief poll here just to see how many are
yay or
nay for kmods. And I'm not talking about their current implementation
or the other various ways that the idea can be accomplished, but rather
on the idea of having kernel modules as separate packages in general.
If you're against the general idea and want to follow up with reasons
why that's fine. I just want to avoid implementation discussions at the
moment if possible.
Necessary evil.
3:44 p.m.
Josh Boyer wrote:
I'd like to just do a brief poll here just to see how many are
yay or
nay for kmods. And I'm not talking about their current implementation
or the other various ways that the idea can be accomplished, but rather
on the idea of having kernel modules as separate packages in general.
If you're against the general idea and want to follow up with reasons
why that's fine. I just want to avoid implementation discussions at the
moment if possible.
I'm not sure where I stand, on one hand I would love to see something like the
UVC driver to be in a kmod until merged upstream, to add support for recent
webcams.
OTOH, maintaining kmods and especially keeping the repo depsolving 100% with
them may be a pain.
I think that atleast we need a rule that if it isn't heading upstream, there
need to be real good reasons to have it in Fedora, if it is heading upstream I
think providing a kmod for a while as a service might be a good idea.
Does anyone know for example why the lirc kernel module has never gone upstream?
Regards,
Hans
4:13 p.m.
Josh Boyer wrote:
> I'd like to just do a brief poll here just to see how many are yay or
> nay for kmods. And I'm not talking about their current implementation
> or the other various ways that the idea can be accomplished, but rather
> on the idea of having kernel modules as separate packages in general.
>
> If you're against the general idea and want to follow up with reasons
> why that's fine. I just want to avoid implementation discussions at the
> moment if possible.
>
Yay, mainly due to my recent issue with kqemu. There are many useful kernel
modules that are not in mainline for any number of reasons. Barring the
usual license issues and guidelines, I don't think there has to be a reason
kmods are not in Fedora if they are not headed upstream. I think the goal
should be kernel inclusion of course and my concern would be that projects
get lazy - "Don't worry about clearing the code with akpm, Fedora/we will
just create a kmod for it".
The technical arguments may of course weigh heavily against it - I'm all to
aware of dep issues as I already use kmods from an external repo.
Regards
Chris
--
http://www.chruz.com
4:14 p.m.
Hans de Goede wrote:
Josh Boyer wrote:
> I'd like to just do a brief poll here just to see how many are yay or
> nay for kmods. And I'm not talking about their current implementation
> or the other various ways that the idea can be accomplished, but rather
> on the idea of having kernel modules as separate packages in general.
>
> If you're against the general idea and want to follow up with reasons
> why that's fine. I just want to avoid implementation discussions at the
> moment if possible.
>
I'm not sure where I stand, on one hand I would love to see something
like the UVC driver to be in a kmod until merged upstream, to add
support for recent webcams.
OTOH, maintaining kmods and especially keeping the repo depsolving 100%
with them may be a pain.
I think that atleast we need a rule that if it isn't heading upstream,
there need to be real good reasons to have it in Fedora, if it is
heading upstream I think providing a kmod for a while as a service might
be a good idea.
Does anyone know for example why the lirc kernel module
Modules. There are a TON of 'em.
has never gone upstream?
Christoph Bartelmus seemed to have very little interest in getting
things upstream, but *just* posted a "Help Wanted" email to the lirc
mailing list on the 16th. Excerpted from that:
----8<----
3. kernel module clean-up: the final goal should be a kernel
integration, but there a several fine-grain steps inbetween, like
correct usage of __init, __exit, remove all compile time dependancies,
enable support for more than one serial port at a time in lirc_serial,
remove 2.4 compatibility code, etc.
----8<----
--
Jarod Wilson
jwilson(a)redhat.com
4:21 p.m.
Jarod Wilson wrote:
Hans de Goede wrote:
> Josh Boyer wrote:
>> I'd like to just do a brief poll here just to see how many are yay or
>> nay for kmods. And I'm not talking about their current implementation
>> or the other various ways that the idea can be accomplished, but rather
>> on the idea of having kernel modules as separate packages in general.
>>
>> If you're against the general idea and want to follow up with reasons
>> why that's fine. I just want to avoid implementation discussions at the
>> moment if possible.
>>
>
> I'm not sure where I stand, on one hand I would love to see something
> like the UVC driver to be in a kmod until merged upstream, to add
> support for recent webcams.
>
> OTOH, maintaining kmods and especially keeping the repo depsolving
> 100% with them may be a pain.
>
> I think that atleast we need a rule that if it isn't heading upstream,
> there need to be real good reasons to have it in Fedora, if it is
> heading upstream I think providing a kmod for a while as a service
> might be a good idea.
>
> Does anyone know for example why the lirc kernel module
Modules. There are a TON of 'em.
> has never gone upstream?
Christoph Bartelmus seemed to have very little interest in getting
things upstream, but *just* posted a "Help Wanted" email to the lirc
mailing list on the 16th. Excerpted from that:
----8<----
3. kernel module clean-up: the final goal should be a kernel
integration, but there a several fine-grain steps inbetween, like
correct usage of __init, __exit, remove all compile time dependancies,
enable support for more than one serial port at a time in lirc_serial,
remove 2.4 compatibility code, etc.
----8<----
Minor correction: Christoph said a few years back he had no problem if
someone wanted to work on integrating the drivers into the kernel, but
didn't have the time to tackle it himself.
Hm... So I may have just found a(nother) pet project...
--
Jarod Wilson
jwilson(a)redhat.com
10:10 p.m.
On Tue, 2007-06-19 at 17:21 -0400, Jarod Wilson wrote:
Minor correction: Christoph said a few years back he had no problem
if
someone wanted to work on integrating the drivers into the kernel, but
didn't have the time to tackle it himself.
Hm... So I may have just found a(nother) pet project...
I'm happy to help work on this too.
Jon.
10:08 p.m.
On Tue, 2007-06-19 at 15:01 -0500, Josh Boyer wrote:
I'd like to just do a brief poll here just to see how many are
yay or
nay for kmods. And I'm not talking about their current implementation
or the other various ways that the idea can be accomplished, but rather
on the idea of having kernel modules as separate packages in general.
What's the alternative? There is no practical, real alternative.
Jon.
8:04 a.m.
On Tue, 2007-06-19 at 23:08 -0400, Jon Masters wrote:
On Tue, 2007-06-19 at 15:01 -0500, Josh Boyer wrote:
> I'd like to just do a brief poll here just to see how many are yay or
> nay for kmods. And I'm not talking about their current implementation
> or the other various ways that the idea can be accomplished, but rather
> on the idea of having kernel modules as separate packages in general.
What's the alternative? There is no practical, real alternative.
Depends. Using a 3rd party repository is an alternative, and is fairly
practical. That is already done for some of the binary-only modules.
But anyway, my original question was pertaining to Fedora proper so I'll
stick with that for now.
In Fedora, we currently only have 2 kmods. That's it. Other's have
been requested but have either been denied for one reason or another, or
have been superseded by newer kernels (ala some of the wireless drivers
that got pulled in with the wirless-dev tree).
It is not beyond reason that those two kmods could be added as patches
to the kernel package itself and simply built with it. This, of course,
does not scale to large numbers of external drivers but I don't really
see us actually _getting_ large numbers of external drivers that are
actually approved. It might have some pain in rawhide, but the current
kmod maintainers are pretty responsive from what I've seen.
I'm mostly just rambling. In the past, there has been some vocal
dissent for having kmods period, so I wanted to know the opinions from
people on a more targeted list than fedora-devel.
josh
8:21 a.m.
On Wed, 2007-06-20 at 08:04 -0500, Josh Boyer wrote:
I'm mostly just rambling. In the past, there has been some
vocal
dissent for having kmods period, so I wanted to know the opinions from
people on a more targeted list than fedora-devel.
Officially, there may only be two, but obviously third parties will
supply others - so we need the infrastructure.
In fact, I'm working on a project to allow automatic, online driver
updates via kmods - I'll have more to say in due course on that.
Jon.
8:46 a.m.
On Wed, 2007-06-20 at 09:21 -0400, Jon Masters wrote:
On Wed, 2007-06-20 at 08:04 -0500, Josh Boyer wrote:
> I'm mostly just rambling. In the past, there has been some vocal
> dissent for having kmods period, so I wanted to know the opinions from
> people on a more targeted list than fedora-devel.
Officially, there may only be two, but obviously third parties will
supply others - so we need the infrastructure.
In fact, I'm working on a project to allow automatic, online driver
updates via kmods - I'll have more to say in due course on that.
Is that why there are the "updates" and "weak-updates" directories
in /lib/modules/`uname -r`/ today?
I've been wondering about those. And what would they be used for? E.g.
updating e1000 when there's a bugfix that doesn't really require the
whole kernel to be spun again?
josh
12:21 p.m.
Josh Boyer wrote:
On Wed, 2007-06-20 at 09:21 -0400, Jon Masters wrote:
> On Wed, 2007-06-20 at 08:04 -0500, Josh Boyer wrote:
>
>> I'm mostly just rambling. In the past, there has been some vocal
>> dissent for having kmods period, so I wanted to know the opinions from
>> people on a more targeted list than fedora-devel.
> Officially, there may only be two, but obviously third parties will
> supply others - so we need the infrastructure.
>
> In fact, I'm working on a project to allow automatic, online driver
> updates via kmods - I'll have more to say in due course on that.
Is that why there are the "updates" and "weak-updates" directories
in /lib/modules/`uname -r`/ today?
I've been wondering about those. And what would they be used for? E.g.
updating e1000 when there's a bugfix that doesn't really require the
whole kernel to be spun again?
Yes, an updated e1000 driver could land in updates (though kmod tends to
use 'extra' instead of 'updates', but other repos kernel module packages
use updates). The weak-updates is only used by RHEL at the moment, as
far as I recall. Basically, you install kmod-foo for kernel
2.6.18-8.el5, and when you install kernel 2.6.18-8.0.3.el5, a symlink
back into the -8.el5 module tree for that kmod-foo gets created in
-8.0.3.el5's weak-updates folder. A kernel-provided driver will take
precedence, but if none is provided, the one in weak-updates will get
used instead. Because of the stable kabi, drivers from an earlier kernel
*should* work just fine with a newer one. Or something more or less like
that...
--
Jarod Wilson
jwilson(a)redhat.com
9:55 a.m.
On Tue, 2007-06-19 at 15:01 -0500, Josh Boyer wrote:
I'd like to just do a brief poll here just to see how many are
yay or
nay for kmods. And I'm not talking about their current implementation
or the other various ways that the idea can be accomplished, but
rather on the idea of having kernel modules as separate packages in
general.
Absolutely not, ever.
If you're against the general idea and want to follow up with
reasons
why that's fine.
If it's good enough for Fedora to ship and support, we can put it in the
main kernel package. Besides; if it's good enough for Fedora to ship and
support, then it should be upstream already anyway and thus should get
into our main kernel package by _default_.
And if it isn't good enough for upstream to ship and support, why in
$DEITY's name would we want to ship it, again?
--
dwmw2
10:12 a.m.
On Wed, 2007-06-20 at 22:55 +0800, David Woodhouse wrote:
On Tue, 2007-06-19 at 15:01 -0500, Josh Boyer wrote:
> I'd like to just do a brief poll here just to see how many are yay or
> nay for kmods. And I'm not talking about their current implementation
> or the other various ways that the idea can be accomplished, but
> rather on the idea of having kernel modules as separate packages in
> general.
Absolutely not, ever.
> If you're against the general idea and want to follow up with reasons
> why that's fine.
If it's good enough for Fedora to ship and support, we can put it in the
main kernel package. Besides; if it's good enough for Fedora to ship and
Which is something I suggested later in this thread.
And if it isn't good enough for upstream to ship and support, why
in
$DEITY's name would we want to ship it, again?
*cough* squashfs *cough cough* wireless-dev *cough* CFS *cough hack* xen
*cough*
Ok, out of those really only squashfs and xen aren't immediately headed
towards some kind of upstream inclusion.
josh
10:16 a.m.
On Wed, 2007-06-20 at 11:15 -0400, Chuck Ebbert wrote:
On 06/20/2007 11:12 AM, Josh Boyer wrote:
>
>> And if it isn't good enough for upstream to ship and support, why in
>> $DEITY's name would we want to ship it, again?
>
> *cough* squashfs *cough cough* wireless-dev *cough* CFS *cough hack* xen
> *cough*
>
... exec-shield
Ooh, forgot about that one. And of course, utrace at the moment.
But I didn't want to mention them because I don't want to piss Roland
off ;)
josh
10:39 a.m.
On Wed, 2007-06-20 at 10:12 -0500, Josh Boyer wrote:
> If it's good enough for Fedora to ship and support, we can
put it in the
> main kernel package. Besides; if it's good enough for Fedora to ship and
Which is something I suggested later in this thread.
> And if it isn't good enough for upstream to ship and support, why in
> $DEITY's name would we want to ship it, again?
*cough* squashfs *cough cough* wireless-dev *cough* CFS *cough hack* xen
*cough*
And a bunch of drivers too. I remember the USB DSL drivers around FC4
timeframe, because the complexity of setting that crap up in FC3
offended me so much. PlayStation 3 support in F7. There's _plenty_ of
stuff we've shipped in our main kernel package because it's _almost_
upstream and it's (almost) good enough. There's no need to package them
separately¹ -- either we're willing to ship and support them, or we
aren't.
Ok, out of those really only squashfs and xen aren't immediately
headed
towards some kind of upstream inclusion.
Is squashfs not headed upstream? Obviously Xen was and is a massive
fscking abortion, but I don't think anyone's holding that up as a
shining example of how we should do stuff -- quite the opposite, in
fact.
--
dwmw2
¹ Except for the illegal crap like nVidia and ATI drivers, but those aren't
relevant to this particular discussion anyway.
10:45 a.m.
On Wed, 2007-06-20 at 23:39 +0800, David Woodhouse wrote:
> Ok, out of those really only squashfs and xen aren't
immediately headed
> towards some kind of upstream inclusion.
Is squashfs not headed upstream?
squashfs gets posted every few months, people come back with complaints,
the maintainer disappears for four to six months and then comes back
with things fixed and goes at it again. That's been the treadmill with
squashfs for over a year now :-/
Someone just asked again recently on the squashfs list about upstream,
so that's usually enough to kick off another go at it...
Jeremy
10:46 a.m.
On Wed, 2007-06-20 at 23:39 +0800, David Woodhouse wrote:
On Wed, 2007-06-20 at 10:12 -0500, Josh Boyer wrote:
> > If it's good enough for Fedora to ship and support, we can put it in the
> > main kernel package. Besides; if it's good enough for Fedora to ship and
>
> Which is something I suggested later in this thread.
>
> > And if it isn't good enough for upstream to ship and support, why in
> > $DEITY's name would we want to ship it, again?
>
> *cough* squashfs *cough cough* wireless-dev *cough* CFS *cough hack* xen
> *cough*
And a bunch of drivers too. I remember the USB DSL drivers around FC4
timeframe, because the complexity of setting that crap up in FC3
offended me so much. PlayStation 3 support in F7. There's _plenty_ of
stuff we've shipped in our main kernel package because it's _almost_
upstream and it's (almost) good enough. There's no need to package them
separately¹ -- either we're willing to ship and support them, or we
aren't.
> Ok, out of those really only squashfs and xen aren't immediately headed
> towards some kind of upstream inclusion.
Is squashfs not headed upstream? Obviously Xen was and is a massive
I think it's been tried twice now. The first time, there were
legitimate review issues. The second time was mostly people whining
about pointless crap. I think Philip lost interest after that.
josh
10:12 a.m.
David Woodhouse wrote:
And if it isn't good enough for upstream to ship and support, why
in
$DEITY's name would we want to ship it, again?
From http://fedoraproject.org/wiki/Objectives :
* To be on the leading edge of free and open source technology, by
adopting and helping develop new features and version upgrades.
TBF, there are several other bullet items there that support your other
points.
--
Peter
6:47 a.m.
On Tue, Jun 19, 2007 at 03:01:07PM -0500, Josh Boyer wrote:
I'd like to just do a brief poll here just to see how many are
yay or
nay for kmods. And I'm not talking about their current implementation
or the other various ways that the idea can be accomplished, but rather
on the idea of having kernel modules as separate packages in general.
If you're against the general idea and want to follow up with reasons
why that's fine.
I'm late in the query, but definitely, yes. People come screaming at
ATrpms to get kmdl updates which can't go in as afast into either
the kernel sources proper or a patch into the kernel rpm.
Any kernel module project will have external kernel module build
setups available before being able to get into the kernel, even the
ones that already have a slot there.
Arguing that one should wait for the vanilla kernel to incorporate
those patches while OTOh we are talking about how to evr
CVS/svn/git/hg cuts of everything else is a bit
hypocritical. Especially with all the patching that still happens in
the Fedora kernel.
I just want to avoid implementation discussions at the moment if
possible.
Unfortunately the (bad) implementations and lack of a standard (and
"standard" is not always what is written in the guidelines ...) add to
the problem enormously. I don't think you can really separate the
discussion. If you had a nicely working scheme everybody would
support, you wouldn't have that much hostility against packaging
kernel modules.
Heck, *some* of the patches to the Fedora kernel could be managed as
external kernel modules and save the pain of upgrading the main kernel
package when such a subsystem is touched. In fact many such changes
that people would like to see fixed have to wait to queue up to make a
kernel update worthwhile for all Fedora users.
Anyway the latter is a pipe dream - unless the kernel packager group
at Fedora sees truly painlessly working kernel module packages there
won't be any such outsourcing.
But getting an infrastructure that supports building sane kernel
module packages would be a plus in any relation, even if not used by
Fedora itself for more than half a dozen packages. As a fact currently
several repos are looking at using koji and one blocker is whether
adding kernel module support would be possible.
There are also some RHEL-only related benefits to endorse external kernel
module packages, but I won't dwel into that on *fedora-kernel* :)
--
Axel.Thimm at ATrpms.net
8:34 a.m.
/me is late in the game -- I was on vacation in the past two weeks and
tried to keep a bit away from the keyboard
On 19.06.2007 22:01, Josh Boyer wrote:
I'd like to just do a brief poll here just to see how many are
yay or
nay for kmods. And I'm not talking about their current implementation
or the other various ways that the idea can be accomplished, but rather
on the idea of having kernel modules as separate packages in general.
My 2 cent these days are this: I think we should have a kind of
"experimental and unsupported repository area" in the scope of the
Fedora-Project where we could have
- kernel-module packages for the Kernels released by Fedora
- alternate kernels
- stuff that replaces packages from the Distribution. No, no big repo --
just specific experimental areas like we had in the past as well ("AIGLX
for FC5")
Reasons for that option: there is a strong opposition against kernel
module packages or heavily patches kernels (¹) which afaics directly and
indirectly the main reason why we only have two kernels module packages
in Fedora (²). People on the other hand sometimes need kernel module
packages, and we don't have the man-power to submit all of them to the
kernel ourselfs (where they should be).
How to move on? My plan was to wait for the new elected Board and FESCo
and ask them what they want (now that we have a merged world) -- *if
they want* kernel module packages directly in the Package Repository (³)
make the infrastructure better (automatic build for packages after a
kernel gets build for updates or updates-testing [we maybe could need
something similar to solve situations like the firefox-update
dilemma...]; enhance the current kernel module packaging standard in so
we can do ship pre-build packages while make it possible for users to
use dkms or a dkms-like solution) and tell packagers that kmods are
really allowed and wanted.
CU
thl
(¹) -- no, I don't want them either
(²) -- there were some in the queue, but afaics a lot of people
(including me) choose to not review them/help them into the repo as many
people loudly yelled "no seperate kernel modules packages in Fedora" the
last time the topic was discussed (even if the Board gave a "go"
(³) -- which I doubt
6149
days inactive
6155
days old
kernel@lists.fedoraproject.org
22 comments
11 participants
participants (11)
-
Axel Thimm -
Christopher Brown -
Chuck Ebbert -
David Woodhouse -
Hans de Goede -
Jarod Wilson -
Jeremy Katz -
Jon Masters -
Josh Boyer -
Peter Jones -
Thorsten Leemhuis