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
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.
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.
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
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
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 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...
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.
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.
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
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.
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
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...
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?
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
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
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.
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
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
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.
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* :)
/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
kernel@lists.fedoraproject.org