Hi folks,
I've started playing around with virtualization at work and the first thing I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It was GPL'd in February and although I realise Axel is packaging kmdl/kmods it would be good to know if this is being queued up for mainline. If not then can it be backported for Fedora kernels. If that is not possible then can it be moved into the default repos to save users (me) bolting on another repo (no offence Axel).
Please forgive dual list posting but I know DJ reads the kernel list and might want to comment whereas I'm not sure AT does. And vice versa.
Regards Chris
On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote:
I've started playing around with virtualization at work and the first thing I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It was GPL'd in February and although I realise Axel is packaging kmdl/kmods it would be good to know if this is being queued up for mainline.
not afaik.. I've not heard of anyone working on it since its initial opensource'ing, which seemed to be a reactionary thing in response to kvm's gaining popularity.
If not then can it be backported for Fedora kernels.
It was fairly big (but not really invasive fwir), but it's still a delta that we'd perpetually have to carry vs upstream. Each patch adds a burden towards rebasing, and with no clear path for this to get upstream, it's questionable how long we'd have to carry it, so I'm not too enthusiastic to be honest.
Dave
On 6/16/07, Dave Jones davej@redhat.com wrote:
On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote:
I've started playing around with virtualization at work and the first
thing
I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It
was
GPL'd in February and although I realise Axel is packaging kmdl/kmods it would be good to know if this is being queued up for mainline.
not afaik.. I've not heard of anyone working on it since its initial opensource'ing, which seemed to be a reactionary thing in response to kvm's gaining popularity.
If not then can it be backported for Fedora kernels.
It was fairly big (but not really invasive fwir), but it's still a delta that we'd perpetually have to carry vs upstream. Each patch adds a burden towards rebasing, and with no clear path for this to get upstream, it's questionable how long we'd have to carry it, so I'm not too enthusiastic to be honest.
well but kqemu seems not to break that often I just recompile it after each kernel release and it just works. the code might be big but it does not depend on (fast) changing interfaces.
On Thu, Aug 02, 2007 at 08:20:26PM +0200, dragoran wrote:
On 6/16/07, Dave Jones davej@redhat.com wrote:
On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote:
I've started playing around with virtualization at work and the first
thing
I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It
was
GPL'd in February and although I realise Axel is packaging kmdl/kmods it would be good to know if this is being queued up for mainline.
not afaik.. I've not heard of anyone working on it since its initial opensource'ing, which seemed to be a reactionary thing in response to kvm's gaining popularity.
If not then can it be backported for Fedora kernels.
It was fairly big (but not really invasive fwir), but it's still a delta that we'd perpetually have to carry vs upstream. Each patch adds a burden towards rebasing, and with no clear path for this to get upstream, it's questionable how long we'd have to carry it, so I'm not too enthusiastic to be honest.
well but kqemu seems not to break that often I just recompile it after each kernel release and it just works. the code might be big but it does not depend on (fast) changing interfaces.
I'm really against merging more 'not upstream' things. We make a big deal about how close to upstream we are, and frankly in the last year or so, we've _sucked_ at keeping that statement true. Whilst some stuff is likely to end up in upstream at some point (utrace for eg), other stuff is perpetual baggage that is a pita when it comes to rebasing. Each release, we're getting closer though, as more and more old stuff gets thrown away. For eg, for F7, no-one cared enough about tux to really keep it maintained. Result - gone. Xen became such a hindrance it ended up having to go to its own package. The wireless stuff seems to be a sliding patchset, where the stuff it contains ends up upstream, but at the same time, a new batch of not yet upstream stuff arrives. I'm hoping eventually that too will settle down, but adding a driver here and a driver there is a path that I'd really rather we didn't travel due to the ongoing maintainence headache that it involves.
A much better way to get this stuff into Fedora is to find out why it isn't getting upstream, and get involved with whatever cleanup work is necessary to get it there.
Dave
On Thu, 2 Aug 2007, Dave Jones wrote:
A much better way to get this stuff into Fedora is to find out why it isn't getting upstream, and get involved with whatever cleanup work is necessary to get it there.
Upstream (of which a lot of people are working at RedHat as well, so telling them to go upstream is kinda moot) often don't even start to listen. There is no politics in the kernel, because kernel people are just not enganging in an discussion at all.
Paul
Paul Wouters wrote:
On Thu, 2 Aug 2007, Dave Jones wrote:
A much better way to get this stuff into Fedora is to find out why it isn't getting upstream, and get involved with whatever cleanup work is necessary to get it there.
Upstream (of which a lot of people are working at RedHat as well, so telling them to go upstream is kinda moot) often don't even start to listen. There is no politics in the kernel, because kernel people are just not enganging in an discussion at all.
Who even submitted these patches upstream to start engaging in a discussion?
Rahul
Rahul Sundaram wrote:
Paul Wouters wrote:
On Thu, 2 Aug 2007, Dave Jones wrote:
A much better way to get this stuff into Fedora is to find out why it isn't getting upstream, and get involved with whatever cleanup work is necessary to get it there.
Upstream (of which a lot of people are working at RedHat as well, so telling them to go upstream is kinda moot) often don't even start to listen. There is no politics in the kernel, because kernel people are just not enganging in an discussion at all.
Who even submitted these patches upstream to start engaging in a discussion?
in case of kqemu nobody... seems qemu upstream isn't really interessted in doing this.
On Fri, Aug 03, 2007 at 03:02:37PM +0200, dragoran wrote:
listen. There is no politics in the kernel, because kernel people are just not enganging in an discussion at all.
Who even submitted these patches upstream to start engaging in a discussion?
in case of kqemu nobody... seems qemu upstream isn't really interessted in doing this.
Simple observation: kqemu has not been discussed on the kernel list. This is a public list so not a single person since the start of 2007 and maybe before has raised it. That seems to make it less of a priority to the world than some ancient 8bit ISA controller cards
dragoran wrote:
Rahul Sundaram wrote:
Paul Wouters wrote:
On Thu, 2 Aug 2007, Dave Jones wrote:
A much better way to get this stuff into Fedora is to find out why it isn't getting upstream, and get involved with whatever cleanup work is necessary to get it there.
Upstream (of which a lot of people are working at RedHat as well, so telling them to go upstream is kinda moot) often don't even start to listen. There is no politics in the kernel, because kernel people are just not enganging in an discussion at all.
Who even submitted these patches upstream to start engaging in a discussion?
in case of kqemu nobody... seems qemu upstream isn't really interessted in doing this.
So all the harping on about whether Red Hat developers are involved upstream or not, kernel politics etc is irrelevant. Red Hat kernel developers wouldn't prefer discussing patches to the kernel here either.
If anyone is really interested in getting Kqemu in the Fedora, encourage the Kqemu developer to submit his patches to LKML instead of focusing on getting the Fedora kernel maintainers to patch the kernel.
Rahul
I'm somewhat interested; is there an exact reason why DKMS hasn't been added to the main repository? I stopped using all other methods of handling non-vanilla kernel modules when I found it, because it really does make life that much easier.
On 8/2/07, Kelly lightsolphoenix@gmail.com wrote:
I'm somewhat interested; is there an exact reason why DKMS hasn't been added to the main repository?
I'm confused.... on my f7 system dkms is listed as available from yum.
yum -C list dkms
Available Packages dkms.noarch 2.0.16-1.fc7 fedora
-jef
On Thursday, August 02, 2007 7:15 pm Jeff Spaleta wrote:
I'm confused.... on my f7 system dkms is listed as available from yum.
You're right; it is. Okay, then I'm going to rephrase this:
Why can't kqemu be included in main as a DKMS module? It's already in FreshRPMs that way, and it seems to me that would be a more effective way of dealing with it than to directly embed it in the kernel (since it would allow kqemu to be upgraded separate from the kernel itself, and make kernel debugging easier).
Kelly wrote:
You're right; it is. Okay, then I'm going to rephrase this:
Why can't kqemu be included in main as a DKMS module? It's already in FreshRPMs that way, and it seems to me that would be a more effective way of dealing with it than to directly embed it in the kernel (since it would allow kqemu to be upgraded separate from the kernel itself, and make kernel debugging easier).
It would require end users to have compiler tools on their systems and it was frowned upon to ship packages with that requirement. I'm sure the archives have much more discussion of this.
On Friday, August 03, 2007 11:05 am Todd Zullinger wrote:
It would require end users to have compiler tools on their systems and it was frowned upon to ship packages with that requirement. I'm sure the archives have much more discussion of this.
Following that logic, all the -devel packages should be removed as well, because they require compiler tools.
Last time I checked, DKMS and the modules are kept separate from the main kernel, so the separate packages can have dependencies on the compiler tools without requiring them for the main kernel. DKMS isn't a requirement for everybody, is it?
On 03.08.2007 17:29, Kelly wrote:
On Friday, August 03, 2007 11:05 am Todd Zullinger wrote:
It would require end users to have compiler tools on their systems and it was frowned upon to ship packages with that requirement. I'm sure the archives have much more discussion of this.
https://www.redhat.com/archives/fedora-devel-list/2007-January/msg01211.html was the last important discussion (including comments from Jeremy). Kelly, please take a look there, this discussion likely won't lead anywhere if nothing changed in between. As kmods are on the way out in general in Fedora (which is something I in parts agree with) it's even more unlikely now.
CU knurd
On Fri, 03 Aug 2007 17:57:46 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
As kmods are on the way out in general in Fedora (which is something I in parts agree with) it's even more unlikely now.
kmods as separate packages is what's hopefully on the way out. Out of tree modules can still be included in the main kernel rpm. It makes things tramendously easier to keep them in the kernel tree so that they are built right along with the kernel. It's easier on the end user's system too as they always get a kernel with the module they need.
And now the kernel maintainers would be the deciders as to what goes in our out of our kernel, so the same criteria that is used for the kernel is now used for kernel modules which is completely fair (everybody plays by the same rules)
Jesse Keating wrote:
On Fri, 03 Aug 2007 17:57:46 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
As kmods are on the way out in general in Fedora (which is something I in parts agree with) it's even more unlikely now.
kmods as separate packages is what's hopefully on the way out. Out of tree modules can still be included in the main kernel rpm. It makes things tramendously easier to keep them in the kernel tree so that they are built right along with the kernel. It's easier on the end user's system too as they always get a kernel with the module they need.
Only thing is DaveJ sorta kinda said no thanks to carrying any additional out-of-tree stuff in the kernel package.
https://www.redhat.com/archives/fedora-kernel-list/2007-August/msg00011.html
And now the kernel maintainers would be the deciders as to what goes in our out of our kernel, so the same criteria that is used for the kernel is now used for kernel modules which is completely fair (everybody plays by the same rules)
See above... :)
On Fri, 03 Aug 2007 13:22:18 -0400 Jarod Wilson jwilson@redhat.com wrote:
Only thing is DaveJ sorta kinda said no thanks to carrying any additional out-of-tree stuff in the kernel package.
https://www.redhat.com/archives/fedora-kernel-list/2007-August/msg00011.html
And now the kernel maintainers would be the deciders as to what goes in our out of our kernel, so the same criteria that is used for the kernel is now used for kernel modules which is completely fair (everybody plays by the same rules)
See above... :)
I'm OK with that. The reasons he states are valid whether they are in the kernel or packaged separately. In fact, things are /worse/ of it's packaged separately.
This was also before we had the source control merged and it would have been possible for somebody outside of Red Hat to help with the kernel and anything we carry /in/ the kernel.
On Fri, 3 Aug 2007 13:30:17 -0400 Jesse Keating jkeating@redhat.com wrote:
This was also before we had the source control merged and it would have been possible for somebody outside of Red Hat to help with the kernel and anything we carry /in/ the kernel.
Obviously I need to get my eyes checked. This was 2007, not 2006 (:
On 03.08.2007 19:13, Jesse Keating wrote:
On Fri, 03 Aug 2007 17:57:46 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
As kmods are on the way out in general in Fedora (which is something I in parts agree with) it's even more unlikely now.
kmods as separate packages is what's hopefully on the way out.
As I said, I agree in parts with it -- I'm these days against having them in the "Fedora Everything" spin. But I still think we should have a place for kernel-module packages in the Fedora project. A kind of "alphaworks", "testing kitchen" or something like that for this and other stuff that's not in shape for Fedora proper (or rawhide) yet -- with a big fat warning sign "use on your own risk" "this *will* eat babies" on the front of course. Sure, some people won't read that, but that's not enough reasons to *not* do it IMHO.
Out of tree modules can still be included in the main kernel rpm.
Not all. And that's part of the reason why there was a certain interest from some people inside Red Hat to have a packaging standard tested and used in Fedora that can get reused for RHEL (which is the case). Well, some Red Hat people kick kernel modules packages out of Fedora now, so I expect you guys can fight that out own your own inside Red Hat.
I'm just wondering in general about the current happenings -- some months ago the Board issued a statement to allow kmods but now a new FESCo shoots it down again. Well, not my business as well.
[...]
CU knurd
On Fri, 03 Aug 2007 19:47:01 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
Not all. And that's part of the reason why there was a certain interest from some people inside Red Hat to have a packaging standard tested and used in Fedora that can get reused for RHEL (which is the case). Well, some Red Hat people kick kernel modules packages out of Fedora now, so I expect you guys can fight that out own your own inside Red Hat.
I never understood why we did out of spec modules in RHEL. It's just plain stupid, and it didn't work worth a damn. One "bright" idea was to let Fedora come up with a way to make it better. Well I have a way, and it's you don't do it. If it hurts when you poke yourself in the eye, no amount of finger protection is going to help. You've got to stop poking yourself in the eye.
I'm just wondering in general about the current happenings -- some months ago the Board issued a statement to allow kmods but now a new FESCo shoots it down again. Well, not my business as well.
We're not saying no to non-upstream kernel modules, which is at the heart of what the board wants (at least from my understanding of the topic). All we're doing is trying to redefine the delivery mechanism so that it is easier for all parties involved. Currently, FESCo itself has to approve any and all kmod packages, yet the kernel team is allowed to put whatever they want into the kernel rpm whether it is upstream or not. To me it makes sense to grant the kernel team the same right they have now, over all kernel modules. That would leave us with A) still the ability to ship out of upstream kernel modules, and B) an approval process for what is acceptable in this nature to have in Fedora. As a bonus we make it far more convenient to produce and consume these things.
Jesse Keating wrote:
I never understood why we did out of spec modules in RHEL. It's just plain stupid, and it didn't work worth a damn.
I thought RHEL made some effort to avoid breaking the 3rd party modules that their customers rely on with every kernel update (and that's probably a very large reason they have customers...) while Linus and fedora refuse to provide a stable interface.
One "bright" idea was to let Fedora come up with a way to make it better.
You mean - like actually define an interface and stick to it at least through a kernel major revision number?
On Fri, 3 Aug 2007, Les Mikesell wrote:
I thought RHEL made some effort to avoid breaking the 3rd party modules that their customers rely on with every kernel update (and that's probably a very large reason they have customers...) while Linus and fedora refuse to provide a stable interface.
One "bright" idea was to let Fedora come up with a way to make it better.
You mean - like actually define an interface and stick to it at least through a kernel major revision number?
Hear hear! Being able to do:
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,22)
and having that work properly on both Linus and RedHat kernels would be a huge win. Right now for openswan, these are all off-by-one for RedHat kernels.
Paul
Paul Wouters wrote:
On Fri, 3 Aug 2007, Les Mikesell wrote:
I thought RHEL made some effort to avoid breaking the 3rd party modules that their customers rely on with every kernel update (and that's probably a very large reason they have customers...) while Linus and fedora refuse to provide a stable interface.
One "bright" idea was to let Fedora come up with a way to make it better.
You mean - like actually define an interface and stick to it at least through a kernel major revision number?
Hear hear! Being able to do:
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,22)
and having that work properly on both Linus and RedHat kernels would be a huge win. Right now for openswan, these are all off-by-one for RedHat kernels.
We actually fixed that just a few weeks ago in rawhide, and carried the changes back to the 2.6.22.1 kernels in FC6 and F7.
On Fri, 3 Aug 2007, Jarod Wilson wrote:
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,22)
and having that work properly on both Linus and RedHat kernels would be a huge win. Right now for openswan, these are all off-by-one for RedHat kernels.
We actually fixed that just a few weeks ago in rawhide, and carried the changes back to the 2.6.22.1 kernels in FC6 and F7.
Excellent. Thank you!
Paul
One thing that concerns me (or I am not clear on what is being proposed) is that if out-of-tree drivers are merged with the kernel package, we will have a distro that works with the stock kernel but drop in a custom kernel and suddenly everything breaks.
Mark Bidewell
On Fri, 3 Aug 2007 16:31:06 -0400 "Mark Bidewell" mark.bidewell@alumni.clemson.edu wrote:
One thing that concerns me (or I am not clear on what is being proposed) is that if out-of-tree drivers are merged with the kernel package, we will have a distro that works with the stock kernel but drop in a custom kernel and suddenly everything breaks.
How is that different from today? Unless you build those out of tree kmod packages against your custom kernel, they'll go boom.
But if they're in the kernel package, and you customize your kernel based on that package, you'll get those mods you want for free.
The issue (to me at least) would be "do I know before I start what functionality is provided by the base kernel and what is provided by third party modules.?" My nightmare scenario goes like this.
1) I install fedora feature X works due to non-upstream patch. 2) Build custom kernel. feature X no longer works.
Using Nvidia as an example...(I realize that they will nver be included in the kernel).
If I see build a custom kernel, I know I will need to rebuild the nvidia drivers. If these drivers were in the kernel rpm, I might carelessly assume that my video card is handled by upstream and be in for a nasty shock.
In the case of multiple packages I know what will need to be redone. If the module is in the kernel RPM due to a patch,etc; I would have a much harder time determining what to rebuild.
My vote would be for: kernel rpm == upstream (kernel.org) as much as possible with only rare exceptions (devicescape wireless stack for example).
Mark Bidewell
On 8/3/07, Jesse Keating jkeating@redhat.com wrote:
On Fri, 3 Aug 2007 16:31:06 -0400 "Mark Bidewell" mark.bidewell@alumni.clemson.edu wrote:
One thing that concerns me (or I am not clear on what is being proposed) is that if out-of-tree drivers are merged with the kernel package, we will have a distro that works with the stock kernel but drop in a custom kernel and suddenly everything breaks.
How is that different from today? Unless you build those out of tree kmod packages against your custom kernel, they'll go boom.
But if they're in the kernel package, and you customize your kernel based on that package, you'll get those mods you want for free.
-- Jesse Keating Fedora -- All my bits are free, are yours?
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, 2007-08-03 at 16:50 -0400, Mark Bidewell wrote:
My vote would be for: kernel rpm == upstream (kernel.org) as much as possible with only rare exceptions (devicescape wireless stack for example).
Yes. We're not proposing that every man and his dog should suddenly be permitted to commit their kernel hack du jour to the Fedora kernel. The kernel would have a few very carefully selected additions which are very close to being merged upstream, just like it's _always_ had.
On Fri, 03 Aug 2007 13:18:46 -0500 Les Mikesell lesmikesell@gmail.com wrote:
I thought RHEL made some effort to avoid breaking the 3rd party modules that their customers rely on with every kernel update (and that's probably a very large reason they have customers...) while Linus and fedora refuse to provide a stable interface.
This is only helpful in RHEL5. not really helpful in 4/3/2.1 and I'm not entirely convinced that it's a good thing either. I just don't know the problem space well enough.
One "bright" idea was to let Fedora come up with a way to make it better.
You mean - like actually define an interface and stick to it at least through a kernel major revision number?
Which is again not helpful in Fedora as we jump major numbers all the time. The very crux of my argument is that if it's good enough to be in Fedora, it's good enough to be in the kernel package. And if it's not, it's not.
On Fri, 3 Aug 2007, Jesse Keating wrote:
Which is again not helpful in Fedora as we jump major numbers all the time. The very crux of my argument is that if it's good enough to be in Fedora, it's good enough to be in the kernel package. And if it's not, it's not.
I disagree. Take the KLIPS openswan kernel module. Most openswan users want it because without the kernel module's ipsecX interfaces, sysadmins find it too hard to configure their firewals properly (especially with NAT added to the mix, and NETKEY's odd packet flow you can't tcpdump properly).
There are valid reasons for this code not to be included in the kernel, and we wishewe could restart a dialog with kernel developers to phase out the dual stack issues. The Openswan project now loses most of its time by playing catch up to massive changes in 2.6.2x kernels.
But there is really no valid reasons for not including it in Fedora, since the code has proven to be rock solid for 5+ years, is widely used and widely prefered over the NETKEY code by those sysadmins involved.
The reason why I haven't submitted a kmod package for KLIPS, is that for it to work properly with NAT, one small patch to udp.c is needed (two if you want to add support for clashing IP's in transport mode IPsec required for running a more then one-user L2TP server), and my attempt years ago to get that patch in (even disabled so people would have to rpmbuild it but no other people could possible be affected) was unsuccessful.
openswan klips has been in the ATrpms kernel since they started. Debian provides klips kernel module packages. Distributions like Fedora should enable such choice.
Paul ps. if there are redhat/linux kernel develpors following this thread, I'm more then happy to talk about our extensive work done to gut KLIPS of its own crypto and pfkey code and make it call ESP() and cryptoapi, and about the whole acrypto vs OCF requirements and implementations to move things to a unified stack everyone can be happy with.
On Fri, 3 Aug 2007 14:35:38 -0400 (EDT) Paul Wouters paul@xelerance.com wrote:
There are valid reasons for this code not to be included in the kernel
What are the reasons? Just because it's in the kernel package doesn't mean it will be probed at boot up. Why is it acceptable to have this outside the kernel as a package, but not inside the kernel package?
Les Mikesell wrote:
I thought RHEL made some effort to avoid breaking the 3rd party modules that their customers rely on with every kernel update (and that's probably a very large reason they have customers...) while Linus and fedora refuse to provide a stable interface.
The goal of Fedora is to be as close to upstream as possible - not to have more customers^Wusers or win popularity contests.
RHEL has customers -- customers who pay good money so that Red Hat can pay developers to spend time backporting things to maintain ABI.
Fedora has users -- users who get a very current open source OS at no cost.
If you really need what RHEL provides, use RHEL or CentOS. Why should Fedora duplicate that?
One "bright" idea was to let Fedora come up with a way to make it better.
You mean - like actually define an interface and stick to it at least through a kernel major revision number?
Right, and have davej and the kernel team spend all of their time backporting? I'd rather have the kernel updated in a timely manner. The place to argue for a stable interface is upstream. Hasn't this been said over and over before?
Todd Zullinger wrote:
RHEL has customers -- customers who pay good money so that Red Hat can pay developers to spend time backporting things to maintain ABI.
Which, if someone would pick an interface and stick to it, wouldn't have to be done at all.
If you really need what RHEL provides, use RHEL or CentOS. Why should Fedora duplicate that?
When something works right, everyone can use the same thing. But people also need something RHEL and CentOS don't provide, which is current application versions.
One "bright" idea was to let Fedora come up with a way to make it better.
You mean - like actually define an interface and stick to it at least through a kernel major revision number?
Right, and have davej and the kernel team spend all of their time backporting?
There would be no need to backport if the kernel had an interface.
I'd rather have the kernel updated in a timely manner. The place to argue for a stable interface is upstream. Hasn't this been said over and over before?
I just appreciate the fact that on my Windows and Mac boxes I don't have to get or rebuild every vendor-supplied driver after every system update and I think Solaris works that way too. I'm not convinced it's necessary. As an interesting aside - has anyone considered the viability of building fedora's userland around the opensolaris kernel like http://www.gnusolaris.org/gswiki is doing with ubuntu?
On Fri, 2007-08-03 at 14:37 -0500, Les Mikesell wrote:
I just appreciate the fact that on my Windows and Mac boxes I don't have to get or rebuild every vendor-supplied driver after every system update and I think Solaris works that way too.
OTOH, you can't update to 64-bit Vista, because there are no drivers. And what's the solution to that? Have driver producers license and escrow their source code to Microsoft, so that they can distribute the drivers with the OS. Sounds like a good idea. Why isn't Linus doing that? Oh wait, he is. :)
/abo
Alexander Boström wrote:
On Fri, 2007-08-03 at 14:37 -0500, Les Mikesell wrote:
I just appreciate the fact that on my Windows and Mac boxes I don't have to get or rebuild every vendor-supplied driver after every system update and I think Solaris works that way too.
OTOH, you can't update to 64-bit Vista, because there are no drivers. And what's the solution to that? Have driver producers license and escrow their source code to Microsoft, so that they can distribute the drivers with the OS. Sounds like a good idea. Why isn't Linus doing that? Oh wait, he is. :)
That sometimes works, sometimes doesn't. It's not really the business of an OS to own and restrict everything that touches it, whether on the driver or application interfaces. Attempting that will limit what users can do with it. Would you, for example, put all of your critical data on a firewire drive while you upgrade through the kernels used from FC5 to current?
Les Mikesell wrote:
That sometimes works, sometimes doesn't. It's not really the business of an OS to own and restrict everything that touches it, whether on the driver or application interfaces. Attempting that will limit what users can do with it. Would you, for example, put all of your critical data on a firewire drive while you upgrade through the kernels used from FC5 to current?
I assume you know very well that discussing this here isn't going to change how the upstream kernel works. Either go to LKML and see if you can convince anyone with your arguments or drop it.
Rahul
On 05/08/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Les Mikesell wrote:
That sometimes works, sometimes doesn't. It's not really the business of an OS to own and restrict everything that touches it, whether on the driver or application interfaces. Attempting that will limit what users can do with it. Would you, for example, put all of your critical data on a firewire drive while you upgrade through the kernels used from FC5 to current?
I assume you know very well that discussing this here isn't going to change how the upstream kernel works. Either go to LKML and see if you can convince anyone with your arguments or drop it.
Can I take it by that statement you mean that the Fedora project has no influence over the state of the upstream kernel? That would be a pretty sad state of affairs, given the size and influence of the project's main contributor.
As the person who started this whole argument by querying kqemu's inclusion (or lack thereof) into the kernel, I can also state I started this here rather than on the LKML because:
-There is more chance of me getting an answer here -I do not subscribe to LKML and do not wish to in order to ask one question -I prefer the ... how shall I put this .. ambience.. of the fedora-devel to LKML
I think this is also a good forum to debate things in before poking a nose in LKML, to also glean information as to varying modules and their progression towards inclusion - yes I remain the eternal optimist.
It is also sad to see you are yet again ordering people about on a public mailing list. If you are not interested in the discussion, you do not need to read or reply to it, the latter being an option I would personally prefer.
Regards Chris
Chris Brown wrote:
On 05/08/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Les Mikesell wrote:
That sometimes works, sometimes doesn't. It's not really the business of an OS to own and restrict everything that touches it, whether on the driver or application interfaces. Attempting that will limit what users can do with it. Would you, for example, put all of your critical data on a firewire drive while you upgrade through the kernels used from FC5 to current?
I assume you know very well that discussing this here isn't going to change how the upstream kernel works. Either go to LKML and see if you can convince anyone with your arguments or drop it.
Can I take it by that statement you mean that the Fedora project has no influence over the state of the upstream kernel? That would be a pretty sad state of affairs, given the size and influence of the project's main contributor.
As the person who started this whole argument by querying kqemu's inclusion (or lack thereof) into the kernel, I can also state I started this here rather than on the LKML because:
And I added my comments because RHEL demonstrates that a distribution does not have to pass upstream breakage directly to users, and the centosplus kernel shows that it can be pretty solid even if you leave in the parts that RHEL removes.
-There is more chance of me getting an answer here -I do not subscribe to LKML and do not wish to in order to ask one question -I prefer the ... how shall I put this .. ambience.. of the fedora-devel to LKML
I don't see much hope for changes in kernel development unless/until someone puts together a really nice distribution around opensolaris so there is some other choice, but there is plenty of competition now at the linux distribution level and fedora has a somewhat-deserved reputation for breaking things with updates in the middle of a version cycle. Since fedora already has a very fast version turnover, why can't kernel updates be held back to security patches within a version or made 'opt-in' in the updater so users with working systems don't have unpleasant surprises?
I think this is also a good forum to debate things in before poking a nose in LKML, to also glean information as to varying modules and their progression towards inclusion - yes I remain the eternal optimist.
It is also sad to see you are yet again ordering people about on a public mailing list. If you are not interested in the discussion, you do not need to read or reply to it, the latter being an option I would personally prefer.
The discussion I'd like to see is to what extent stability matters and whether users that need it should just look for some other distro that includes firefox 2.x (etc.) but isn't so aggressive with kernel changes?
Les Mikesell wrote:
And I added my comments because RHEL demonstrates that a distribution does not have to pass upstream breakage directly to users,
That involves tedious back porting. Not something we have the resources in Fedora. Fedora has a explicit goal to be close to upstream and the explicit non-goal to support proprietary components.
Rahul
* Les Mikesell [06/08/2007 20:14] :
The discussion I'd like to see is to what extent stability matters and whether users that need it should just look for some other distro that includes firefox 2.x (etc.) but isn't so aggressive with kernel changes?
IMHO, We'll only be able to have this discussion once people stop presenting API/ABI changes as breakage. Once we've got that straw man out of the way, we might be able to discuss this constructively.
Emmanuel
Emmanuel Seyman wrote:
- Les Mikesell [06/08/2007 20:14] :
The discussion I'd like to see is to what extent stability matters and whether users that need it should just look for some other distro that includes firefox 2.x (etc.) but isn't so aggressive with kernel changes?
IMHO, We'll only be able to have this discussion once people stop presenting API/ABI changes as breakage. Once we've got that straw man out of the way, we might be able to discuss this constructively.
Interfaces broken by mid-version updates are just as broken in fedora as they would be in RHEL and it's not any more a straw man for one distribution than another unless you are willing to say that one is only suitable for testing. If you want to say the changes are a good thing, then lets see them in RHEL too. But, if you want to put that aside for the moment, firewire will make a great example. Do you forsee a time when you would keep your own backups or valuable data on a firewire drive under fedora?
* Les Mikesell [07/08/2007 16:45] :
Interfaces broken by mid-version updates are just as broken in fedora as they would be in RHEL and it's not any more a straw man for one distribution than another unless you are willing to say that one is only suitable for testing.
This implies (to varying degrees) several things :
- The two distributions target the same audience. - The two distributions claim equivalent support of API/ABI stability. - API/ABI changes are broken for the sheer heck of it. - Updates have no features other than changes in API/ABI.
These implications range from "not true" to "false". Put together, they make a poor representation of the reasons why Fedora sticks to upstream whereas RHEL promises API/ABI stability which is why I call this a straw man.
If you want to say the changes are a good thing,
then lets see them in RHEL too.
Ad hominem tu quoque. FWIW, its stagnation is one of the reasons I do not use RHEL (or clone thereof).
But, if you want to put that aside for
the moment, firewire will make a great example. Do you forsee a time when you would keep your own backups or valuable data on a firewire drive under fedora?
Not having any firewire materiel, I can't answer the question. What exactly is the problem with firewire support in Fedora ?
Emmanuel
Emmanuel Seyman wrote:
- Les Mikesell [07/08/2007 16:45] :
Interfaces broken by mid-version updates are just as broken in fedora as they would be in RHEL and it's not any more a straw man for one distribution than another unless you are willing to say that one is only suitable for testing.
This implies (to varying degrees) several things :
- The two distributions target the same audience.
- The two distributions claim equivalent support of API/ABI stability.
- API/ABI changes are broken for the sheer heck of it.
- Updates have no features other than changes in API/ABI.
These implications range from "not true" to "false". Put together, they make a poor representation of the reasons why Fedora sticks to upstream whereas RHEL promises API/ABI stability which is why I call this a straw man.
What I'm looking for from this discussion is a definition of the target audience for fedora. Nobody expects perfection, but is there really an audience that doesn't care if their devices stop working or not?
If you want to say the changes are a good thing,
then lets see them in RHEL too.
Ad hominem tu quoque. FWIW, its stagnation is one of the reasons I do not use RHEL (or clone thereof).
Agreed at the application level, but not for the kernel. I have yet to see a mid-version kernel change that mattered to me in any situation where the machine was working to begin with. Enhancing hotplug support is nice but that's the sort of change that could be made at major version releases which come around fast enough anyway in fedora.
But, if you want to put that aside for
the moment, firewire will make a great example. Do you forsee a time when you would keep your own backups or valuable data on a firewire drive under fedora?
Not having any firewire materiel, I can't answer the question. What exactly is the problem with firewire support in Fedora ?
There have been large chunks of time that it hasn't worked or disks wouldn't be recognized even if it saw a raw IEEE device. I gave up and switched the machines that needed it to Centos with the centosplus kernel so I don't know the current state except that I've seen comments about a complete rewrite coming so it must still leave something to be desired (and even on Centos I don't trust it beyond connecting temporarily for backup copies). Anyway it's a good device to talk about in any discussion of included vs. vendor-supplied drivers or user expectations vs. experience in general.
Les Mikesell wrote:
What I'm looking for from this discussion is a definition of the target audience for fedora.
I remember pointing out this to you atleast twice but see http://fedoraproject.org/wiki/Objectives
Nobody expects perfection, but is there really an
audience that doesn't care if their devices stop working or not?
Don't confuse robustness with ABI breakage.
There have been large chunks of time that it hasn't worked or disks wouldn't be recognized even if it saw a raw IEEE device. I gave up and switched the machines that needed it to Centos with the centosplus kernel so I don't know the current state except that I've seen comments about a complete rewrite coming so it must still leave something to be desired
The rewrite is already in Fedora 7 (and will be in RHEL 5.1).
Rahul
Rahul Sundaram wrote:
What I'm looking for from this discussion is a definition of the target audience for fedora.
I remember pointing out this to you atleast twice but see http://fedoraproject.org/wiki/Objectives
There's some mention of usability and robustness there that don't match my experience except around mid to late FC3 and FC6.
Nobody expects perfection, but is there really an
audience that doesn't care if their devices stop working or not?
Don't confuse robustness with ABI breakage.
Robustness is something you can observe without knowledge of internals. Why something breaks is not particularly relevant. The question is, to what degree can you expect it to not break?
There have been large chunks of time that it hasn't worked or disks wouldn't be recognized even if it saw a raw IEEE device. I gave up and switched the machines that needed it to Centos with the centosplus kernel so I don't know the current state except that I've seen comments about a complete rewrite coming so it must still leave something to be desired
The rewrite is already in Fedora 7 (and will be in RHEL 5.1).
Can you - or someone - comment on whether you'd trust it with your working copy of something important?
On Tue, 07 Aug 2007 13:34:49 -0500 Les Mikesell lesmikesell@gmail.com wrote:
Can you - or someone - comment on whether you'd trust it with your working copy of something important?
All my development happens on Fedora, I push the code up to hosted.fp.o periodically. The only real thing stopping me from having more on Fedora is the timeline. There are servers that I just don't want to touch, save for the few updates that apply to that install set, for years, and for that I have RHEL, the Long Term Fedora. Everything else is Fedora.
On Tue, 7 Aug 2007 14:46:04 -0400 Jesse Keating jkeating@redhat.com wrote:
Can you - or someone - comment on whether you'd trust it with your working copy of something important?
All my development happens on Fedora, I push the code up to hosted.fp.o periodically. The only real thing stopping me from having more on Fedora is the timeline. There are servers that I just don't want to touch, save for the few updates that apply to that install set, for years, and for that I have RHEL, the Long Term Fedora. Everything else is Fedora.
Sorry, I misread the question. Ignore my reply.
Jesse Keating wrote:
On Tue, 07 Aug 2007 13:34:49 -0500 Les Mikesell lesmikesell@gmail.com wrote:
Can you - or someone - comment on whether you'd trust it with your working copy of something important?
All my development happens on Fedora, I push the code up to hosted.fp.o periodically. The only real thing stopping me from having more on Fedora is the timeline. There are servers that I just don't want to touch, save for the few updates that apply to that install set, for years, and for that I have RHEL, the Long Term Fedora. Everything else is Fedora.
My "day job" is RHEL kernel stuff. And yet, my personal web and mail server, home file server, home workstation, office workstation and laptop all run Fedora (and F7 at the oldest now). I most definitely trust Fedora with my working copy of something important -- like the PITA backport patches I'm working on for the RHEL kernel... ;)
Jarod Wilson wrote:
Jesse Keating wrote:
On Tue, 07 Aug 2007 13:34:49 -0500 Les Mikesell lesmikesell@gmail.com wrote:
Can you - or someone - comment on whether you'd trust it with your working copy of something important?
All my development happens on Fedora, I push the code up to hosted.fp.o periodically. The only real thing stopping me from having more on Fedora is the timeline. There are servers that I just don't want to touch, save for the few updates that apply to that install set, for years, and for that I have RHEL, the Long Term Fedora. Everything else is Fedora.
My "day job" is RHEL kernel stuff. And yet, my personal web and mail server, home file server, home workstation, office workstation and laptop all run Fedora (and F7 at the oldest now). I most definitely trust Fedora with my working copy of something important -- like the PITA backport patches I'm working on for the RHEL kernel... ;)
Oh, just saw Jesse's reply and read further up the thread... The "it" was the new firewire stack, not Fedora, right?
FWIW, I do have a few firewire hard drives and a firewire dvd burner that all work just fine with the new stack, haven't had any issues whatsoever. (anything firewire that touches libavc1394, libraw1394 or libiec61883 is another issue though...)
Jarod Wilson wrote:
Oh, just saw Jesse's reply and read further up the thread... The "it" was the new firewire stack, not Fedora, right?
Yes, thanks.
FWIW, I do have a few firewire hard drives and a firewire dvd burner that all work just fine with the new stack, haven't had any issues whatsoever. (anything firewire that touches libavc1394, libraw1394 or libiec61883 is another issue though...)
Do you know if a firewire drive will work reliably as a raid1 mirror with a matching internal drive? With the older stack it isn't recognized in time at boot-up to automatically connect the md device. You can add it and the re-sync generally works if the partition is not too busy, but it tends to be failed out of the array if it is left connected when the partition is very active.
Les Mikesell wrote:
Jarod Wilson wrote:
Oh, just saw Jesse's reply and read further up the thread... The "it" was the new firewire stack, not Fedora, right?
Yes, thanks.
FWIW, I do have a few firewire hard drives and a firewire dvd burner that all work just fine with the new stack, haven't had any issues whatsoever. (anything firewire that touches libavc1394, libraw1394 or libiec61883 is another issue though...)
Do you know if a firewire drive will work reliably as a raid1 mirror with a matching internal drive?
Not a clue, never tried.
With the older stack it isn't recognized in time at boot-up to automatically connect the md device.
It is if you load the firewire modules in your initrd. :)
You can add it and the re-sync generally works if the partition is not too busy, but it tends to be failed out of the array if it is left connected when the partition is very active.
I wonder if the cfs scheduler would help with this any. And/or shutting off beagle (which likes to absolutely slaughter the i/o on my workstation).
Jarod Wilson wrote:
Do you know if a firewire drive will work reliably as a raid1 mirror with a matching internal drive?
Not a clue, never tried.
With the older stack it isn't recognized in time at boot-up to automatically connect the md device.
It is if you load the firewire modules in your initrd. :)
Hmmm, would that happen by itself if the drive is attached during an install with the new system?
You can add it and the re-sync generally works if the partition is not too busy, but it tends to be failed out of the array if it is left connected when the partition is very active.
I wonder if the cfs scheduler would help with this any. And/or shutting off beagle (which likes to absolutely slaughter the i/o on my workstation).
The place I want it is as a 3rd member of a RAID1 set that is used for the pooled file storage for backuppc - which hardlinks all identical files it finds across your backup set. This is extremely busy during backups and takes an impractically long time to copy with tar or other file-oriented means because of the way hardlinks are re-constructed (many days for a 250 gig drive), while a raid-sync will complete in a couple of hours. There's probably a better way to do that now with LVM snapshots but that's getting off the topic of reliability.
Les Mikesell wrote:
Jarod Wilson wrote:
Do you know if a firewire drive will work reliably as a raid1 mirror with a matching internal drive?
Not a clue, never tried.
With the older stack it isn't recognized in time at boot-up to automatically connect the md device.
It is if you load the firewire modules in your initrd. :)
Hmmm, would that happen by itself if the drive is attached during an install with the new system?
I'm reasonably certain that's the case.
You can add it and the re-sync generally works if the partition is not too busy, but it tends to be failed out of the array if it is left connected when the partition is very active.
I wonder if the cfs scheduler would help with this any. And/or shutting off beagle (which likes to absolutely slaughter the i/o on my workstation).
The place I want it is as a 3rd member of a RAID1 set that is used for the pooled file storage for backuppc - which hardlinks all identical files it finds across your backup set. This is extremely busy during backups and takes an impractically long time to copy with tar or other file-oriented means because of the way hardlinks are re-constructed (many days for a 250 gig drive), while a raid-sync will complete in a couple of hours. There's probably a better way to do that now with LVM snapshots but that's getting off the topic of reliability.
Wait... So you're essentially creating a cloned volume on the firewire disk via a raid resync, rather than having the initial backup written with the firewire disk connected in the raid set? If so, that's moderately amusing... :)
Jarod Wilson wrote:
The place I want it is as a 3rd member of a RAID1 set that is used for the pooled file storage for backuppc - which hardlinks all identical files it finds across your backup set. This is extremely busy during backups and takes an impractically long time to copy with tar or other file-oriented means because of the way hardlinks are re-constructed (many days for a 250 gig drive), while a raid-sync will complete in a couple of hours. There's probably a better way to do that now with LVM snapshots but that's getting off the topic of reliability.
Wait... So you're essentially creating a cloned volume on the firewire disk via a raid resync, rather than having the initial backup written with the firewire disk connected in the raid set? If so, that's moderately amusing... :)
The object is to make copies that can be rotated offsite weekly and that's the first way I found that actually worked. In earlier attempts I tried to use one internal, one external drive as a mirrored set, just failing/removing the external drive and adding a different one periodically. That didn't work well because the drive would frequently be marked as failed even though it really didn't have a problem, and on any reboot it would have to be re-synced manually. Also while trying to do it this way I had an actual failure on the internal drive which took some contortions to recover. So, I created a 3-member raid1 with one device specified as "missing" and now have 2 internal drives that run mirrored all the time and at weekly intervals add the external drive and wait for the sync. Then I momentarily stop the backuppc service, unmount the drive, fail the device in the raid, and remove it. I can then access the external drive with a laptop and could do disaster recovery restores without any other special equipment. Backuppc's compression/pooling scheme crams about 700gigs worth of archives on the 250 gig disks that I am using and it beats trying to find things on tapes. But, for some reason the drive works fine for the 2+ hour sync procedure but will generally fail out of the raid if I forget and leave it connected through the nightly backups. My guess is that it isn't doing as many retries on soft errors or timeouts as a raid member as a standalone device would.
On 8/7/07, Jarod Wilson jwilson@redhat.com wrote:
[...]
You can add it and the re-sync generally works if the partition is not too busy, but it tends to be failed out of the array if it is left connected when the partition is very active.
I wonder if the cfs scheduler would help with this any. And/or shutting off beagle (which likes to absolutely slaughter the i/o on my workstation).
cfs is a cpu scheduler we already have a fair io scheduler (cfq ;) ) but cfq got some improvements too (uses a rbtree now like cfs)
dragoran wrote:
On 8/7/07, *Jarod Wilson* <jwilson@redhat.com mailto:jwilson@redhat.com> wrote:
[...] > You can add it and the re-sync generally works if the partition is not > too busy, but it tends to be failed out of the array if it is left > connected when the partition is very active. I wonder if the cfs scheduler would help with this any. And/or shutting off beagle (which likes to absolutely slaughter the i/o on my workstation).
cfs is a cpu scheduler we already have a fair io scheduler (cfq ;) ) but cfq got some improvements too (uses a rbtree now like cfs)
Just throwing it out there, because the responsiveness of my desktop went up like 100x while doing heavy lifting in the background (like a kernel build) when I 1) upgraded it to a kernel w/cfs and 2) shut off beagle indexing.
Jarod Wilson wrote:
dragoran wrote:
On 8/7/07, *Jarod Wilson* <jwilson@redhat.com mailto:jwilson@redhat.com> wrote:
[...] > You can add it and the re-sync generally works if the partition is not > too busy, but it tends to be failed out of the array if it is left > connected when the partition is very active. I wonder if the cfs scheduler would help with this any. And/or shutting off beagle (which likes to absolutely slaughter the i/o on my workstation).
cfs is a cpu scheduler we already have a fair io scheduler (cfq ;) ) but cfq got some improvements too (uses a rbtree now like cfs)
Just throwing it out there, because the responsiveness of my desktop went up like 100x while doing heavy lifting in the background (like a kernel build) when I 1) upgraded it to a kernel w/cfs and 2) shut off beagle indexing.
the worst thing you can do is to let beagle index a dir where you build stuff... (I still use beagle but I excluded them).
dragoran wrote:
cfs is a cpu scheduler we already have a fair io scheduler (cfq ;) ) but cfq got some improvements too (uses a rbtree now like cfs)
Just throwing it out there, because the responsiveness of my desktop went up like 100x while doing heavy lifting in the background (like a kernel build) when I 1) upgraded it to a kernel w/cfs and 2) shut off beagle indexing.
the worst thing you can do is to let beagle index a dir where you build stuff... (I still use beagle but I excluded them).
Yep, I now know this, and have since rpm -e'd beagle into oblivion -- I've never really cared enough to use it (I run OS X too, and never use spotlight). But before I nuked beagle, with it running in conjunction with cfs, it was nowhere near as bad as prior to cfs, so at least in my single use case, empirical evidence says cfs is good. :)
Jarod Wilson wrote:
I've never really cared enough to use it (I run OS X too, and never use spotlight). But before I nuked beagle, with it running in conjunction with cfs, it was nowhere near as bad as prior to cfs, so at least in my single use case, empirical evidence says cfs is good. :)
did I ever said it wasn't ;) ? I only had small issues with it that ingo fixed quickly before cfs was in fedora.
Les Mikesell wrote:
Rahul Sundaram wrote:
There's some mention of usability and robustness there that don't match my experience except around mid to late FC3 and FC6.
You can continue changing interfaces quite rapidly without affecting robustness. If there are problems with robustness file bug reports. Did you file any?
Robustness is something you can observe without knowledge of internals. Why something breaks is not particularly relevant.
Pretty much. So your real concern is not ABI but things not breaking. So if anything included in Fedora breaks report it. If it is not Fedora specific consider reporting upstream.
Can you - or someone - comment on whether you'd trust it with your working copy of something important?
I don't have firewire devices but if my data is important to me, I would consider doing automated backups. All my work is done in Fedora. So I do absolutely depend on it.
Rahul
Rahul Sundaram wrote:
There's some mention of usability and robustness there that don't match my experience except around mid to late FC3 and FC6.
You can continue changing interfaces quite rapidly without affecting robustness. If there are problems with robustness file bug reports. Did you file any?
Yes, in the firewire case, but I couldn't wait the several months it took before disks were recognized again. Then for most of FC5 the update kernels wouldn't boot on an ibm xseries 225 but I didn't have any idea what to report. Eventually on the mail list someone suggested a bios update which I did to coincide with installing FC6. After the bios update, older versions wouldn't work but the new ones did.
Robustness is something you can observe without knowledge of internals. Why something breaks is not particularly relevant.
Pretty much. So your real concern is not ABI but things not breaking. So if anything included in Fedora breaks report it. If it is not Fedora specific consider reporting upstream.
But I don't necessarily want to limit my machine to fedora-owned drivers. If that is a restriction, then it should be stated clearly where a new user would see it before installing.
Can you - or someone - comment on whether you'd trust it with your working copy of something important?
I don't have firewire devices but if my data is important to me, I would consider doing automated backups.
Yes, I don't expect it to be more robust than the underlying disk drive. I was just hoping for an educated guess about another months-long interval where it wouldn't work at all. Or if it will be solid enough to leave in a raid-mirror configuration?
All my work is done in Fedora. So I do absolutely depend on it.
It's probably not coincidental that fedora works nicely on your hardware. It hasn't been that way for me much of the time and the user mail list makes it look like others have many of the same issues.
Les Mikesell wrote:
But I don't necessarily want to limit my machine to fedora-owned drivers. If that is a restriction, then it should be stated clearly where a new user would see it before installing.
Fedora cannot in anyway help with third party proprietary kernel drivers. That has been said several times quite prominently.
It's probably not coincidental that fedora works nicely on your hardware. It hasn't been that way for me much of the time and the user mail list makes it look like others have many of the same issues.
Fedora works quite nicely on my system because I specifically got a box which doesn't require anything proprietary to work. Well except the wireless firmware.
Rahul
Rahul Sundaram wrote:
But I don't necessarily want to limit my machine to fedora-owned drivers. If that is a restriction, then it should be stated clearly where a new user would see it before installing.
Fedora cannot in anyway help with third party proprietary kernel drivers. That has been said several times quite prominently.
"Not helping" is unrelated to actively breaking in mid-version updates. If you plan the latter, just say so up front - and in a way that points out this difference from RHEL. And anyone who wants current apps on a box that keeps working will just have to learn a different administration style.
It's probably not coincidental that fedora works nicely on your hardware. It hasn't been that way for me much of the time and the user mail list makes it look like others have many of the same issues.
Fedora works quite nicely on my system because I specifically got a box which doesn't require anything proprietary to work. Well except the wireless firmware.
I didn't think there was anything unusual or proprietary about my firewire drives or the IBM 225's either - but they both went through many months of not working with various fedora kernels.
Les Mikesell wrote:
"Not helping" is unrelated to actively breaking in mid-version updates. If you plan the latter, just say so up front - and in a way that points out this difference from RHEL. And anyone who wants current apps on a box that keeps working will just have to learn a different administration style.
If you are saying that Fedora is intentionally breaking third party proprietary modules that would be misleading. Fedora stays close to upstream versions and pulling upstream versions can sometimes break these modules. Sometimes new versions are needed for security fixes. In other cases it brings in bug fixes or new desired functionality.
I didn't think there was anything unusual or proprietary about my firewire drives or the IBM 225's either - but they both went through many months of not working with various fedora kernels.
This isn't Fedora specific issue. All distributions suffered from the same problems. Firewire layer in the upstream kernel wasn't robust enough previously. Red Hat rewrote it and it was in Fedora 7 and it hasn't been merged upstream now in the latest kernel.
Rahul
Rahul Sundaram wrote:
Les Mikesell wrote:
"Not helping" is unrelated to actively breaking in mid-version updates. If you plan the latter, just say so up front - and in a way that points out this difference from RHEL. And anyone who wants current apps on a box that keeps working will just have to learn a different administration style.
If you are saying that Fedora is intentionally breaking third party proprietary modules that would be misleading. Fedora stays close to upstream versions and pulling upstream versions can sometimes break these modules. Sometimes new versions are needed for security fixes. In other cases it brings in bug fixes or new desired functionality.
I'm not suggesting that fedora modifies the ABI arbitrarily just to encourage users to switch to RHEL, but if there is there is no expectation that 3rd party drivers that work at the beginning of a version will work after the first update, I think that should be stated more clearly.
I didn't think there was anything unusual or proprietary about my firewire drives or the IBM 225's either - but they both went through many months of not working with various fedora kernels.
This isn't Fedora specific issue.
It is from the perspective I'm trying to get across. I installed and tested a fedora version with the drives in question. They stopped working after some updates, mid-version.
All distributions suffered from the same problems. Firewire layer in the upstream kernel wasn't robust enough previously. Red Hat rewrote it and it was in Fedora 7 and it hasn't been merged upstream now in the latest kernel.
The change that broke things was never pushed into the Centosplus version I ended up using. If fedora must send every new and untested change on to the users, how about some easier way to avoid them if they break your hardware, like making kernel updates opt-in within a release version? An install option that offered to reserve alternate system partitions so you can revert to a known-working version with access to your current home directory after installing the next might be nice too.
Les Mikesell wrote:
I'm not suggesting that fedora modifies the ABI arbitrarily just to encourage users to switch to RHEL, but if there is there is no expectation that 3rd party drivers that work at the beginning of a version will work after the first update, I think that should be stated more clearly.
There is no expectation that any software outside of Fedora repositories can really be supported by anyone within the project. This is just common sense. The fact that we are going to be close to upstream and not consider proprietary kernel modules is clearly stated in the objectives page. The front page of fedoraproject.org and overview is clear about the focus on Free and open source software. \
The change that broke things was never pushed into the Centosplus version I ended up using.
That is because they are just rebuilding the RHEL kernel and RHEL kernel team does the backporting work to remain on pretty much the same kernel. Again Fedora does have that kind of resources nor does match the goal of Fedora. If you want and prefer RHEL or rebuilds just continue using that instead.
If fedora must send every new and untested
change on to the users, how about some easier way to avoid them if they break your hardware, like making kernel updates opt-in within a release version?
Fedora is targeted towards the end users who prefer running close to the latest versions. These are not untested nor is every version in all packages pushed into the stable branches. All updates are opt-in anyway. So if the older version works for you, you don't have to update.
Rahul
Rahul Sundaram wrote:
If fedora must send every new and untested
change on to the users, how about some easier way to avoid them if they break your hardware, like making kernel updates opt-in within a release version?
Fedora is targeted towards the end users who prefer running close to the latest versions. These are not untested nor is every version in all packages pushed into the stable branches. All updates are opt-in anyway. So if the older version works for you, you don't have to update.
Yet another unbootable kernel: 2.6.22.1-32.fc6 wouldn't boot on either a Dell 1600sc or an IBM xserver 225. Is there some way to send a useful bug report when the kernel just hangs during bootup?
On Thu, Aug 16, 2007 at 05:06:37PM -0500, Les Mikesell wrote:
Yet another unbootable kernel: 2.6.22.1-32.fc6 wouldn't boot on either a Dell 1600sc or an IBM xserver 225. Is there some way to send a useful bug report when the kernel just hangs during bootup?
This comes up often enough, that it probably warrants a wiki page.
There are a bunch of 'usual suspect' switches to try booting with to see if they help - first thing to do is get rid of the 'quiet' switch in the boot command line. We want as much info from the kernel as possible, and this just makes it impossible to debug. - acpi=off is a big hammer, and if that works, narrowing down by trying pci=noacpi instead may yield clues - nolapic and noapic are sometimes useful - Given it's new and still seeing quite a few changes, nohz=off may be worth testing. (Though this is F7 and above only) - initcall_debug will print the name of the kernel subsystems it calls during init, the last one will be the interesting one. - a majority of "won't boot" bugs are of the form where it fails to find the root filesystem. Quite often this ends up being a busted initrd for whatever reason. There's not really a good way to debug this other than to pull apart a good and bad one, and see if the bad one lacks modules that were in the good one for eg. - if stuff scrolls by too fast to catch interesting boot messages and you don't have a serial console, boot_delay=1000 will insert a pause after each print. - if you get no output at all from the kernel, sometimes booting with earlyprintk=vga can yield something of interest.
Finally given that there can be pages of spew from this sort of debugging, if you lack a serial console to capture it, slowing down the printk's and taking a photo with a digital camera every pageful will save you a lot of transcribing.
There's probably some other tricks that I'm forgetting right now too, but that's a good start. The problem with "won't boot" bugs is that the causes can be numerous so there's no one size fits all answer.
Dave
- a majority of "won't boot" bugs are of the form where it fails to find the root filesystem. Quite often this ends up being a busted initrd for whatever reason. There's not really a good way to debug this other than to pull apart a good and bad one, and see if the bad one lacks modules that were in the good one for eg.
It would be nice to have the initrd /init shell grok some kernel command line option to enable -x style output for the initrd, so you can tell exactly what commands were run and compare that to output from a working boot.
On Thu, Aug 16, 2007 at 06:20:48PM -0400, Dave Jones wrote:
On Thu, Aug 16, 2007 at 05:06:37PM -0500, Les Mikesell wrote:
Yet another unbootable kernel: 2.6.22.1-32.fc6 wouldn't boot on either a Dell 1600sc or an IBM xserver 225. Is there some way to send a useful bug report when the kernel just hangs during bootup?
This comes up often enough, that it probably warrants a wiki page.
I spent a while writing up some of this and other common problems at http://fedoraproject.org/wiki/KernelBugTriage
Additional content welcomed.
Dave
Dave Jones wrote:
Yet another unbootable kernel: 2.6.22.1-32.fc6 wouldn't boot on either a Dell 1600sc or an IBM xserver 225. Is there some way to send a useful bug report when the kernel just hangs during bootup?
This comes up often enough, that it probably warrants a wiki page.
I spent a while writing up some of this and other common problems at http://fedoraproject.org/wiki/KernelBugTriage
Additional content welcomed.
Thanks - it turned out that this specific problem was fixed in the next kernel update anyway.
On 8/7/07, Les Mikesell lesmikesell@gmail.com wrote:
If fedora must send every new and untested change on to the users, how about some easier way to avoid them if they break your hardware, like making kernel updates opt-in within a release version?
reconfiguring the setting in /etc/sysconfig/kernel don't provide enough protection for you? setting UPDATEDEFAULT=no should keep your current kernel the default, then you can boot to the update kernel when you see fit to.
-jef"runs updates-testing kernels, so saying things are untested is technically incorrect."spaleta
Jeff Spaleta wrote:
On 8/7/07, Les Mikesell lesmikesell@gmail.com wrote:
If fedora must send every new and untested change on to the users, how about some easier way to avoid them if they break your hardware, like making kernel updates opt-in within a release version?
reconfiguring the setting in /etc/sysconfig/kernel don't provide enough protection for you?
If it is expected to not work - and that's been my experience except for FC3 and FC6, that should be the default. Fortunately through my problems with FC5, yum was smart enough not to delete my working kernel and cycled through many others which I would try to boot, then pick the old one from the grub menu when that failed. I'm not sure if that is still the case, though.
setting UPDATEDEFAULT=no should keep your current kernel the default, then you can boot to the update kernel when you see fit to.
People seem to be having problems with udev too these days. Do they have to stay in sync?
-jef"runs updates-testing kernels, so saying things are untested is technically incorrect."spaleta
OK, but what happens if they fail testing? The problem with firewire drives not being recognized wasn't unique to my machine - it couldn't have worked anywhere.
On 8/7/07, Les Mikesell lesmikesell@gmail.com wrote:
OK, but what happens if they fail testing?
I guess will get to that bridge once people relying on firewire drives start running the test update kernels and filing reports.
-jef
Les Mikesell wrote:
If it is expected to not work - and that's been my experience except for FC3 and FC6, that should be the default.
Bug report?
OK, but what happens if they fail testing? The problem with firewire drives not being recognized wasn't unique to my machine - it couldn't have worked anywhere.
Firewire issues were hardware specific. Some worked, others didn't and others had data transfer issues. It wasn't a global problem with all firewire devices. If issues with a particular package are found and reported during updates-testing, then the maintainer has to decide on pushing the update based on that. All this assumes anyone who has the particular firewire devices actually tests the kernel in the the updates-testing repository and files proper bug reports before it hits the updates repository.
Rahul
On Tue, Aug 07, 2007 at 05:08:53PM -0500, Les Mikesell wrote:
I'm not suggesting that fedora modifies the ABI arbitrarily just to encourage users to switch to RHEL, but if there is there is no expectation that 3rd party drivers that work at the beginning of a version will work after the first update, I think that should be stated more clearly.
Its the default Linux assumption always has been. RHEL is kind of special in that it bothers (at great pain and hard work) to preserve bits of kABI
If your 3rd party driver had its dependancies correct your kernel update would have been caught by rpm as violating a requires. Ask your packager
Alan Cox wrote:
I'm not suggesting that fedora modifies the ABI arbitrarily just to encourage users to switch to RHEL, but if there is there is no expectation that 3rd party drivers that work at the beginning of a version will work after the first update, I think that should be stated more clearly.
Its the default Linux assumption always has been. RHEL is kind of special in that it bothers (at great pain and hard work) to preserve bits of kABI
Your assumptions probably are not the same as a typical new fedora user who might not have any assumptions at all - and I think this distinction should be made clear on the fedora project pages.
If your 3rd party driver had its dependancies correct your kernel update would have been caught by rpm as violating a requires. Ask your packager
Is that a recent addition?
On Tue, Aug 07, 2007 at 06:24:02PM -0500, Les Mikesell wrote:
If your 3rd party driver had its dependancies correct your kernel update would have been caught by rpm as violating a requires. Ask your packager
Is that a recent addition?
No. You've been able to require a specific kernel version since ooh Red Hat 3.03 I believe so about ten years ago
On Wednesday 08 August 2007, Alan Cox wrote:
No. You've been able to require a specific kernel version since ooh Red Hat 3.03 I believe so about ten years ago
I don't think the kernel packages until early 2005 provided anything that would have made arch-qualified dependencies possible (eg. requiring a specific i586 kernel over a i686 with the same NEVR), see bug 143160
On Fri, Aug 10, 2007 at 02:44:29PM +0300, Ville Skyttä wrote:
I don't think the kernel packages until early 2005 provided anything that would have made arch-qualified dependencies possible (eg. requiring a specific i586 kernel over a i686 with the same NEVR), see bug 143160
The file paths are different so you can depend on the exact file as well as the package
On Friday 10 August 2007, Alan Cox wrote:
On Fri, Aug 10, 2007 at 02:44:29PM +0300, Ville Skyttä wrote:
I don't think the kernel packages until early 2005 provided anything that would have made arch-qualified dependencies possible (eg. requiring a specific i586 kernel over a i686 with the same NEVR), see bug 143160
The file paths are different so you can depend on the exact file as well as the package
The point of the above bug report is that even no paths that could be sanely used like that existed, and still don't today. Well except of course if one bases the dependency on whether some quite possibly unrelated modules are built or not (eg. powernow-k6.ko is for i586 but not i686, and p4-clockmod.ko is for i686 but not for i586) but I suppose you didn't mean that, and in any case I don't think it satisfies "sanely".
Fedora 1:
$ rpm -qlp kernel-2.4.22-1.2115.nptl.i586.rpm | grep 586 (no output) $ rpm -qlp kernel-2.4.22-1.2115.nptl.i686.rpm | grep 686 /lib/modules/2.4.22-1.2115.nptl/kernel/drivers/sensors/via686a.o
Fedora 7:
$ rpm -qlp kernel-2.6.22.1-41.fc7.i586.rpm | grep 586 /lib/modules/2.6.22.1-41.fc7/kernel/arch/i386/crypto/aes-i586.ko /lib/modules/2.6.22.1-41.fc7/kernel/arch/i386/crypto/twofish-i586.ko $ rpm -qlp kernel-2.6.22.1-41.fc7.i586.rpm | grep 686 /lib/modules/2.6.22.1-41.fc7/kernel/drivers/hwmon/via686a.ko $ rpm -qlp kernel-2.6.22.1-41.fc7.i686.rpm | grep i586 /lib/modules/2.6.22.1-41.fc7/kernel/arch/i386/crypto/aes-i586.ko /lib/modules/2.6.22.1-41.fc7/kernel/arch/i386/crypto/twofish-i586.ko $ rpm -qlp kernel-2.6.22.1-41.fc7.i686.rpm | grep i686 /lib/modules/2.6.22.1-41.fc7/kernel/drivers/hwmon/via686a.ko
After early 2005 it's no longer a problem due to the added Provides that contain the arch.
Chris Brown wrote:
[...] -I do not subscribe to LKML and do not wish to in order to ask one question
you don't have to .. you can just send a mail to lkml and note that you are not subscribed so that people should CC you on replies.
Chris Brown wrote:
Can I take it by that statement you mean that the Fedora project has no influence over the state of the upstream kernel? That would be a pretty sad state of affairs, given the size and influence of the project's main contributor.
Pick the most appropriate list to discuss it. Fedora folks work on GNOME too but doesn't mean you should discuss all the GNOME changes here.
It is also sad to see you are yet again ordering people about on a public mailing list. If you are not interested in the discussion, you do not need to read or reply to it, the latter being an option I would personally prefer.
Nobody is ordering anyone here. Continue discussing it here if you want to. Just pointing out that it isn't going to suddenly convince kernel developers to have a ABI for kernel modules.
Rahul
Have you read Documentation/stable_api_nonsense.txt ?
On 03.08.2007 19:52, Jesse Keating wrote:
On Fri, 03 Aug 2007 19:47:01 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
Not all. And that's part of the reason why there was a certain interest from some people inside Red Hat to have a packaging standard tested and used in Fedora that can get reused for RHEL (which is the case). Well, some Red Hat people kick kernel modules packages out of Fedora now, so I expect you guys can fight that out own your own inside Red Hat.
I never understood why we did out of spec modules in RHEL. It's just plain stupid, and it didn't work worth a damn. One "bright" idea was to let Fedora come up with a way to make it better. Well I have a way, and it's you don't do it. If it hurts when you poke yourself in the eye, no amount of finger protection is going to help. You've got to stop poking yourself in the eye.
There are lot's of cases and situations in the world where kernel-module packages are needed -- updated or new open-source drivers for testing are a valid area IMHO. I think we should not ignore those and other cases completely.
But well, your statement IMHO shows nicely how Fedora sometimes acts. For heavens sake we at least got firefox.i386 due to the multilib mess (and firefox-32 thx to warren) -- otherwise we'd still would leave people out in the cold just do encourage 3rd-party plugin-writers to port their stuff to x86_64. Side not one the current "thinking about the Fedora brand" thread on FAB-list: maybe we should just say "Fedora only gives you what it thinks is good for you, even if it creates trouble and headaches for you".
I'm just wondering in general about the current happenings -- some months ago the Board issued a statement to allow kmods but now a new FESCo shoots it down again. Well, not my business as well.
We're not saying no to non-upstream kernel modules, which is at the heart of what the board wants (at least from my understanding of the topic). All we're doing is trying to redefine the delivery mechanism so that it is easier for all parties involved.
And davej indicated that he does not want more out-of-kernel modules.
That fact and the "at least from my understanding of the topic" IMHO makes it worth to ask the Board for its opinion.
CU knurd
On Fri, 03 Aug 2007 20:24:00 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
There are lot's of cases and situations in the world where kernel-module packages are needed -- updated or new open-source drivers for testing are a valid area IMHO. I think we should not ignore those and other cases completely.
And every single one of those cases has lead to very difficult to manage user situations or lots of really really ugly hacks to make rpm and yum handle this bad situation. You could make the same argument for any big package. Why should oo.org-writer users have to consume an oo.org update just to fix something in oo.org-impress? Surely we should just make all these external srpms that we can build at will right? It's not like we don't update the kernel often, and I think we'd all benefit from making kernel changes at the same time rather than having it happen at random, whenever each of the modules decide to rebuild.
But well, your statement IMHO shows nicely how Fedora sometimes acts. For heavens sake we at least got firefox.i386 due to the multilib mess (and firefox-32 thx to warren) -- otherwise we'd still would leave people out in the cold just do encourage 3rd-party plugin-writers to port their stuff to x86_64. Side not one the current "thinking about the Fedora brand" thread on FAB-list: maybe we should just say "Fedora only gives you what it thinks is good for you, even if it creates trouble and headaches for you".
Don't confuse "how Fedora acts" with my opinions and wishes. I don't have the authority to make new blanket policy and define new rules. All I can do is suggest then and put them up for vote (and in a few places I have the right to vote). All decisions like this are voted on by a panel of your duly elected representatives.
I'm just wondering in general about the current happenings -- some months ago the Board issued a statement to allow kmods but now a new FESCo shoots it down again. Well, not my business as well.
We're not saying no to non-upstream kernel modules, which is at the heart of what the board wants (at least from my understanding of the topic). All we're doing is trying to redefine the delivery mechanism so that it is easier for all parties involved.
And davej indicated that he does not want more out-of-kernel modules.
That fact and the "at least from my understanding of the topic" IMHO makes it worth to ask the Board for its opinion.
Having just had a conversation with Davej on irc, I can offer these tidbits:
<davej> f13/j-rod: so, my stance on not-upstream modules in the fedora kernel...
<davej> if we have someone actually working towards getting that stuff upstream, I have *no* objection to it being included. (well, with some caveats, like some mods are clearly crack)
He then reviewed the two current kmods:
<davej> this doesn't look like it'd need huge amounts of work to get into an upstreamable state
<davej> it'd need to lose crap like devfs support though
<davej> and all the #ifdef KERNEL_VERSION < 2.5.x junk
<davej> but the key blocker is, is someone going to do the work to get it into that state?
<jwb> davej, ok... so given that if the maintainer was willing to work on that would you let them carry it in the main kernel as a patch?
<davej> jwb: if someone was working on it, sure.
<davej> so.. moving on to systrace.. just needs a champion to work on upstream merge really, otherwise it'll just sit there.
So it looks like Dave is absolutely willing to let out of tree kernel modules in, so long as they have a hope of going upstream, or a really really really good reason why we should continue carrying it forward.
He even spoke of perhaps a timeout, where you get one Fedora release to beat it into shape and get it upstream or we re-review it and perhaps toss it out at the next Feature Freeze. Could be doable. But this tells me that a draft to allow this isn't dead in the water on insta-kernel-nack.
On 03.08.2007 21:15, Jesse Keating wrote:
On Fri, 03 Aug 2007 20:24:00 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
There are lot's of cases and situations in the world where kernel-module packages are needed -- updated or new open-source drivers for testing are a valid area IMHO. I think we should not ignore those and other cases completely.
And every single one of those cases has lead to very difficult to manage user situations or lots of really really ugly hacks to make rpm and yum handle this bad situation.
Well, there is a need for those packages, if you like it or not, so we should fine ways to properly support them in rpm and yum. Wich isn#t the biggest problem. The big problem is to ship new modules when new kernels get shipped. We discussed this and gregdek and some others supported the idea to send out a "we are likely pushing kernel-update foo from updates-testing to updates proper in 24 hours" *if such a warning period is possible (e.g. not in the case of security updates). But that idea got lost.
You could make the same argument for any big package. Why should oo.org-writer users have to consume an oo.org update just to fix something in oo.org-impress?
That a different problem -- deltarpm will solve that one afaics.
A similar (but not identical) problem would be pacakges depending on a exact version of firefox or pidgin (?). We have like other such strict dependencies and those share some of the problems with kernel-module packages (the "old kernels stay installed in parallel make the kernel-module case more complicated)".
[...]
But well, your statement IMHO shows nicely how Fedora sometimes acts. For heavens sake we at least got firefox.i386 due to the multilib mess (and firefox-32 thx to warren) -- otherwise we'd still would leave people out in the cold just do encourage 3rd-party plugin-writers to port their stuff to x86_64. Side not one the current "thinking about the Fedora brand" thread on FAB-list: maybe we should just say "Fedora only gives you what it thinks is good for you, even if it creates trouble and headaches for you".
Don't confuse "how Fedora acts" with my opinions and wishes.
I don't -- this is just another case. firefox.i386 in the x86-64 tree is another one.
I don't have the authority to make new blanket policy and define new rules.
But you seem to be really interested in this topic and you are in the committee that is planing to kick kmod's, so it's IMHO your job to ask the Board for its opinion as it allowed kmod#s again not that long ago.
[...]
I'm just wondering in general about the current happenings -- some months ago the Board issued a statement to allow kmods but now a new FESCo shoots it down again. Well, not my business as well.
We're not saying no to non-upstream kernel modules, which is at the heart of what the board wants (at least from my understanding of the topic). All we're doing is trying to redefine the delivery mechanism so that it is easier for all parties involved.
And davej indicated that he does not want more out-of-kernel modules. That fact and the "at least from my understanding of the topic" IMHO makes it worth to ask the Board for its opinion.
Having just had a conversation with Davej on irc, I can offer these tidbits: [...] So it looks like Dave is absolutely willing to let out of tree kernel modules in, so long as they have a hope of going upstream, or a really really really good reason why we should continue carrying it forward.
Which leaves a lot of modules out. zaptel, spca5xx or gspca anyone?
He even spoke of perhaps a timeout, [...]
We talked about that before and people said "to dangerous, as people will yell at us when module foo suddenly vanishes in Fedora (x+2) again.
CU knurd
On Fri, 03 Aug 2007 21:49:46 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
Well, there is a need for those packages, if you like it or not, so we should fine ways to properly support them in rpm and yum. Wich isn#t the biggest problem. The big problem is to ship new modules when new kernels get shipped. We discussed this and gregdek and some others supported the idea to send out a "we are likely pushing kernel-update foo from updates-testing to updates proper in 24 hours" *if such a warning period is possible (e.g. not in the case of security updates). But that idea got lost.
We wouldn't have to worry about that if the modules were /in/ the kernel package itself. Then they'd get built at the same time and all is love. It's not really that bad to wait for your next kernel update to get new modules in place. Every other module has to wait as well.
You could make the same argument for any big package. Why should oo.org-writer users have to consume an oo.org update just to fix something in oo.org-impress?
That a different problem -- deltarpm will solve that one afaics.
A similar (but not identical) problem would be pacakges depending on a exact version of firefox or pidgin (?). We have like other such strict dependencies and those share some of the problems with kernel-module packages (the "old kernels stay installed in parallel make the kernel-module case more complicated)".
Off in the weeds here, sorry I probably took you there.
[...]
But well, your statement IMHO shows nicely how Fedora sometimes acts. For heavens sake we at least got firefox.i386 due to the multilib mess (and firefox-32 thx to warren) -- otherwise we'd still would leave people out in the cold just do encourage 3rd-party plugin-writers to port their stuff to x86_64. Side not one the current "thinking about the Fedora brand" thread on FAB-list: maybe we should just say "Fedora only gives you what it thinks is good for you, even if it creates trouble and headaches for you".
Don't confuse "how Fedora acts" with my opinions and wishes.
I don't -- this is just another case. firefox.i386 in the x86-64 tree is another one.
I don't have the authority to make new blanket policy and define new rules.
But you seem to be really interested in this topic and you are in the committee that is planing to kick kmod's, so it's IMHO your job to ask the Board for its opinion as it allowed kmod#s again not that long ago.
Sure, once the draft shows up I'll run it through the board if dwmw2 doesn't first.
[...]
I'm just wondering in general about the current happenings -- some months ago the Board issued a statement to allow kmods but now a new FESCo shoots it down again. Well, not my business as well.
We're not saying no to non-upstream kernel modules, which is at the heart of what the board wants (at least from my understanding of the topic). All we're doing is trying to redefine the delivery mechanism so that it is easier for all parties involved.
And davej indicated that he does not want more out-of-kernel modules. That fact and the "at least from my understanding of the topic" IMHO makes it worth to ask the Board for its opinion.
Having just had a conversation with Davej on irc, I can offer these tidbits: [...] So it looks like Dave is absolutely willing to let out of tree kernel modules in, so long as they have a hope of going upstream, or a really really really good reason why we should continue carrying it forward.
Which leaves a lot of modules out. zaptel, spca5xx or gspca anyone?
We only looked at the ones currently in Fedora. The rest would have to be reviewed in their own time. And as Davej puts, it's our responsibility and onus to help these people with a grander long term scheme which is getting these things upstream and becoming responsible for them upstream instead of packaging them in N+ distributions.
He even spoke of perhaps a timeout, [...]
We talked about that before and people said "to dangerous, as people will yell at us when module foo suddenly vanishes in Fedora (x+2) again.
The same danger exists when the kernel moves on and these modules no longer compile without change. That is the danger, and why we're not interested unless there is interest in the module owner in getting them upstream, as that is part of the responsibility, keeping them going.
On Fri, 03 Aug 2007 21:49:46 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
So it looks like Dave is absolutely willing to let out of tree kernel modules in, so long as they have a hope of going upstream, or a really really really good reason why we should continue carrying it forward.
Which leaves a lot of modules out. zaptel, spca5xx or gspca anyone?
There are two goals here that are conflicting in this specific instance. The first is that Fedora wants stuff from upstream. The second is that it wants to be bleeding edge. Finding the balance here, if there is one, is the key.
He even spoke of perhaps a timeout, [...]
We talked about that before and people said "to dangerous, as people will yell at us when module foo suddenly vanishes in Fedora (x+2) again.
I'm not particularly in favor of a timeout either.
josh
On Fri, 3 Aug 2007 15:09:13 -0500 Josh Boyer jwboyer@jdub.homelinux.org wrote:
I'm not particularly in favor of a timeout either.
Well, what about a timeout once it starts failing to compile? Or a timeout once the maintainer is no longer interested in maintaining it (orphan a part of the kernel...)
On Fri, 3 Aug 2007 16:23:36 -0400 Jesse Keating jkeating@redhat.com wrote:
On Fri, 3 Aug 2007 15:09:13 -0500 Josh Boyer jwboyer@jdub.homelinux.org wrote:
I'm not particularly in favor of a timeout either.
Well, what about a timeout once it starts failing to compile? Or a timeout once the maintainer is no longer interested in maintaining it (orphan a part of the kernel...)
There is a difference in having an arbitrary timeout because something didn't get upstreamed and having a module be orphaned. If the maintainer is still fighting to get it upstream and it hasn't happened yet, I see no reason to arbitrarily tell them "too bad, you didn't meet the timeout."
However, the more I think about this the more I'm of the opinion that they have no place in kmods or in the kernel proper. Maybe pointing people to DKMS is a sufficient solution. If users want these modules that bad, they'll be willing to install the toolchain to build them. Dunno, haven't really decided yet.
josh
On Fri, 3 Aug 2007 15:36:30 -0500 Josh Boyer jwboyer@jdub.homelinux.org wrote:
There is a difference in having an arbitrary timeout because something didn't get upstreamed and having a module be orphaned. If the maintainer is still fighting to get it upstream and it hasn't happened yet, I see no reason to arbitrarily tell them "too bad, you didn't meet the timeout."
Well, I didn't want the timeout to be a flat "sod off", I wanted it to be another review point. If they're still fighting and there is progress, no reason not to extend it for another release. IF they've sat on their duff and done nothing, well...
On Fri, 3 Aug 2007 16:48:57 -0400 Jesse Keating jkeating@redhat.com wrote:
On Fri, 3 Aug 2007 15:36:30 -0500 Josh Boyer jwboyer@jdub.homelinux.org wrote:
There is a difference in having an arbitrary timeout because something didn't get upstreamed and having a module be orphaned. If the maintainer is still fighting to get it upstream and it hasn't happened yet, I see no reason to arbitrarily tell them "too bad, you didn't meet the timeout."
Well, I didn't want the timeout to be a flat "sod off", I wanted it to be another review point. If they're still fighting and there is progress, no reason not to extend it for another release. IF they've sat on their duff and done nothing, well...
Yeah. See, this is where we have to trust davej and cebbert to correctly evaluate whether the maintainer is going to stick it out or not. If I were them, I wouldn't be overly trusting.
It's a lot to ask of the kernel guys. But maybe they don't mind.
josh
On Friday, August 03, 2007 3:49 pm Thorsten Leemhuis wrote:
Well, there is a need for those packages, if you like it or not, so we should fine ways to properly support them in rpm and yum. Wich isn#t the biggest problem. The big problem is to ship new modules when new kernels get shipped. We discussed this and gregdek and some others supported the idea to send out a "we are likely pushing kernel-update foo from updates-testing to updates proper in 24 hours" *if such a warning period is possible (e.g. not in the case of security updates). But that idea got lost.
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.
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
On Fri, 3 Aug 2007 13:25:38 -0800 "Jeff Spaleta" jspaleta@gmail.com wrote:
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?
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
On 8/3/07, Josh Boyer jwboyer@jdub.homelinux.org wrote:
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?
I wouldn't necessarily package them as source rpms. I'd want them to be noarch packages that people can install and get updates for, as bug fixes come down the pipe. But to make use of them they'd have to install dkms and the necessary build tools themselves which dkms makes use of.
-jef
On Fri, 3 Aug 2007 17:23:33 -0800 "Jeff Spaleta" jspaleta@gmail.com wrote:
On 8/3/07, Josh Boyer jwboyer@jdub.homelinux.org wrote:
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?
I wouldn't necessarily package them as source rpms. I'd want them to be noarch packages that people can install and get updates for, as bug fixes come down the pipe. But to make use of them they'd have to install dkms and the necessary build tools themselves which dkms makes use of.
By source RPMs I didn't mean .src.rpm. I meant the payload that is installed from dkms-foo-mod is the source of the module that you want DKMS to build. I think we're saying the same thing.
And I am more and more starting to think this might be a _good_ idea. Users that want modules we aren't willing to carry upstream can install the dkms "payload" (as you described it) for the module, build and install.
Some might think this is too technical a hurdle for users to clear, but I think it might be worth examining. Care to draft a proposal for FESCo? We could evaluate it at the same time we do dwmw2/f13's.
josh
On Fri, 3 Aug 2007 20:55:48 -0500 Josh Boyer jwboyer@jdub.homelinux.org wrote:
And I am more and more starting to think this might be a _good_ idea. Users that want modules we aren't willing to carry upstream can install the dkms "payload" (as you described it) for the module, build and install.
Some might think this is too technical a hurdle for users to clear, but I think it might be worth examining. Care to draft a proposal for FESCo? We could evaluate it at the same time we do dwmw2/f13's.
I'm not totally opposed to the idea, if the dkms system takes care of the logic of building the module when new kernels land and such.
On Friday, August 03, 2007 10:46 pm Jesse Keating wrote:
On Fri, 3 Aug 2007 20:55:48 -0500
Josh Boyer jwboyer@jdub.homelinux.org wrote:
And I am more and more starting to think this might be a _good_ idea. Users that want modules we aren't willing to carry upstream can install the dkms "payload" (as you described it) for the module, build and install.
Some might think this is too technical a hurdle for users to clear, but I think it might be worth examining. Care to draft a proposal for FESCo? We could evaluate it at the same time we do dwmw2/f13's.
I'm not totally opposed to the idea, if the dkms system takes care of the logic of building the module when new kernels land and such.
That was what Dell developed DKMS to handle; situations where people are installing outside modules while updating the kernel frequently. Every time a new kernel is booted, the autoinstalled automatically builds all installed DKMS modules for the new kernel before it starts. It takes care of the problem of having to create new packages for all the modules when the kernel is updated.
On Sat, Aug 04, 2007 at 12:12:39PM -0400, Kelly wrote:
On Friday, August 03, 2007 10:46 pm Jesse Keating wrote:
On Fri, 3 Aug 2007 20:55:48 -0500
Josh Boyer jwboyer@jdub.homelinux.org wrote:
And I am more and more starting to think this might be a _good_ idea. Users that want modules we aren't willing to carry upstream can install the dkms "payload" (as you described it) for the module, build and install.
Some might think this is too technical a hurdle for users to clear, but I think it might be worth examining. Care to draft a proposal for FESCo? We could evaluate it at the same time we do dwmw2/f13's.
I'm not totally opposed to the idea, if the dkms system takes care of the logic of building the module when new kernels land and such.
That was what Dell developed DKMS to handle; situations where people are installing outside modules while updating the kernel frequently. Every time a new kernel is booted, the autoinstalled automatically builds all installed DKMS modules for the new kernel before it starts. It takes care of the problem of having to create new packages for all the modules when the kernel is updated.
I've got a bugzilla request in (#250337) to add hooks to the kernel packages, which dkms can hook into. In this way, on kernel package upgrade/remove but before reboot, DKMS can do its thing. I'm doing this with hooks on Ubuntu/Debian kernel packages now, and it works great. That would make this even more seamless.
On Sat, 11 Aug 2007 16:21:47 -0500 Matt Domsch Matt_Domsch@dell.com wrote:
On Sat, Aug 04, 2007 at 12:12:39PM -0400, Kelly wrote:
On Friday, August 03, 2007 10:46 pm Jesse Keating wrote:
On Fri, 3 Aug 2007 20:55:48 -0500
Josh Boyer jwboyer@jdub.homelinux.org wrote:
And I am more and more starting to think this might be a _good_ idea. Users that want modules we aren't willing to carry upstream can install the dkms "payload" (as you described it) for the module, build and install.
Some might think this is too technical a hurdle for users to clear, but I think it might be worth examining. Care to draft a proposal for FESCo? We could evaluate it at the same time we do dwmw2/f13's.
I'm not totally opposed to the idea, if the dkms system takes care of the logic of building the module when new kernels land and such.
That was what Dell developed DKMS to handle; situations where people are installing outside modules while updating the kernel frequently. Every time a new kernel is booted, the autoinstalled automatically builds all installed DKMS modules for the new kernel before it starts. It takes care of the problem of having to create new packages for all the modules when the kernel is updated.
I've got a bugzilla request in (#250337) to add hooks to the kernel
Typo in the bug number? That one is for some SELinux denial.
josh
On Sat, Aug 11, 2007 at 04:29:43PM -0500, Josh Boyer wrote:
On Sat, 11 Aug 2007 16:21:47 -0500 Matt Domsch Matt_Domsch@dell.com wrote:
That was what Dell developed DKMS to handle; situations where people are installing outside modules while updating the kernel frequently. Every time a new kernel is booted, the autoinstalled automatically builds all installed DKMS modules for the new kernel before it starts. It takes care of the problem of having to create new packages for all the modules when the kernel is updated.
I've got a bugzilla request in (#250337) to add hooks to the kernel
Typo in the bug number? That one is for some SELinux denial.
Yep. #250377. Thanks.
-Matt
[11.Ağu.07 16:21 -0500] Matt Domsch:
I've got a bugzilla request in (#250377) to add hooks to the kernel packages, which dkms can hook into. In this way, on kernel package upgrade/remove but before reboot, DKMS can do its thing. I'm doing this with hooks on Ubuntu/Debian kernel packages now, and it works great. That would make this even more seamless.
That would be nice to have.
I have a module loading from /etc/sysconfig/modules/ (to be picked by hal), for which dkms_autoinstaller on next boot is too late.
On 04.08.2007 03:55, Josh Boyer wrote:
On Fri, 3 Aug 2007 17:23:33 -0800 "Jeff Spaleta" jspaleta@gmail.com wrote:
Some might think this is too technical a hurdle for users to clear, but I think it might be worth examining. Care to draft a proposal for FESCo? We could evaluate it at the same time we do dwmw2/f13's.
Just FYI, some of the concerns Jeremy raised last time dkms came up can be found in this thread:
https://www.redhat.com/archives/fedora-devel-list/2007-January/msg01211.html
For example: https://www.redhat.com/archives/fedora-devel-list/2007-January/msg01294.html
I doubt things changed much.
CU thl
BTW, for Matt or other dkms lovers: can somebody please show a rough spec file example how to use dkms in a SRPM (that can be compiled with mock) that pre-compiles modules (that could get shipped in kmod packages) and produces a dkms file for dynamic kernel-module generation, that users could install? Both should use the same codepath for compilation, to avoid that we have to maintain two?
I'd be really interested in that, because that is IMHO what we should aim for: Pre-compiled modules in packages for the masses, dynamic for the rest and the rare cases where users might run into problem, and maintain just one spec file/codepath.
On Sa August 4 2007, Thorsten Leemhuis wrote:
BTW, for Matt or other dkms lovers: can somebody please show a rough spec file example how to use dkms in a SRPM (that can be compiled with mock) that pre-compiles modules (that could get shipped in kmod packages) and produces a dkms file for dynamic kernel-module generation, that users could install? Both should use the same codepath for compilation, to avoid that we have to maintain two?
Here you can find such an srpm for kqemu: http://till.fedorapeople.org/dkms-kmod/
I don't know, what the current way to build xen kernel modules is, because they have a different version than the other kernels and therefore the kmodtool does not work.
I'd be really interested in that, because that is IMHO what we should aim for: Pre-compiled modules in packages for the masses, dynamic for the rest and the rare cases where users might run into problem, and maintain just one spec file/codepath.
This sounds good,
regards, Till
On 8/3/07, Josh Boyer jwboyer@jdub.homelinux.org wrote:
By source RPMs I didn't mean .src.rpm. I meant the payload that is installed from dkms-foo-mod is the source of the module that you want DKMS to build. I think we're saying the same thing.
And I am more and more starting to think this might be a _good_ idea. Users that want modules we aren't willing to carry upstream can install the dkms "payload" (as you described it) for the module, build and install.
We might also want to think about enabling optional magic in something like /sbin/new-kernel-pkg for systems with dkms configured to attempt dkms payload rebuilds on new kernel installs.
If we do not even attempt to provide the binary module against a kernel, we avoid the never-ending game of catch-up that we have to play in the build system with traditional kmod packages when a new kernel is pushed. And I think it sends a clear message that these things are more experimental in nature.
Some might think this is too technical a hurdle for users to clear, but I think it might be worth examining. Care to draft a proposal for FESCo? We could evaluate it at the same time we do dwmw2/f13's.
I should be able to draft a proposal. When's the next meeting?
-jef
On Tue, 7 Aug 2007 13:53:22 -0800 "Jeff Spaleta" jspaleta@gmail.com wrote:
On 8/3/07, Josh Boyer jwboyer@jdub.homelinux.org wrote:
By source RPMs I didn't mean .src.rpm. I meant the payload that is installed from dkms-foo-mod is the source of the module that you want DKMS to build. I think we're saying the same thing.
And I am more and more starting to think this might be a _good_ idea. Users that want modules we aren't willing to carry upstream can install the dkms "payload" (as you described it) for the module, build and install.
We might also want to think about enabling optional magic in something like /sbin/new-kernel-pkg for systems with dkms configured to attempt dkms payload rebuilds on new kernel installs.
If we do not even attempt to provide the binary module against a kernel, we avoid the never-ending game of catch-up that we have to play in the build system with traditional kmod packages when a new kernel is pushed. And I think it sends a clear message that these things are more experimental in nature.
Some might think this is too technical a hurdle for users to clear, but I think it might be worth examining. Care to draft a proposal for FESCo? We could evaluate it at the same time we do dwmw2/f13's.
I should be able to draft a proposal. When's the next meeting?
Thursday.
josh
On Fri, 2007-08-03 at 21:49 +0200, Thorsten Leemhuis wrote:
But you seem to be really interested in this topic and you are in the committee that is planing to kick kmod's, so it's IMHO your job to ask the Board for its opinion as it allowed kmod#s again not that long ago.
I thought the Board said FESCo would have the right to approve or deny kmod packages. So all FESCo needs to do is say 'no' to them all :)
[...]
I'm just wondering in general about the current happenings -- some months ago the Board issued a statement to allow kmods but now a new FESCo shoots it down again. Well, not my business as well.
We're not saying no to non-upstream kernel modules, which is at the heart of what the board wants (at least from my understanding of the topic). All we're doing is trying to redefine the delivery mechanism so that it is easier for all parties involved.
And davej indicated that he does not want more out-of-kernel modules. That fact and the "at least from my understanding of the topic" IMHO makes it worth to ask the Board for its opinion.
Having just had a conversation with Davej on irc, I can offer these tidbits: [...] So it looks like Dave is absolutely willing to let out of tree kernel modules in, so long as they have a hope of going upstream, or a really really really good reason why we should continue carrying it forward.
Which is hardly a surprising result, since we've been doing it that way for years.
Which leaves a lot of modules out. zaptel,
$DEITY yes, we don't want to be shipping Zaptel until/unless they get off their wossname and make it mergable upstream. There's a _reason_ we're shipping Callweaver (which dropped the crappy dependency on Zaptel just for _timing_, and switched to POSIX timers instead) and not Asterisk.
spca5xx or gspca anyone?
I read lkml and I've never heard of those. I assume therefore that they _deserved_ to be mentioned in the same sentence as zaptel?
He even spoke of perhaps a timeout, [...]
We talked about that before and people said "to dangerous, as people will yell at us when module foo suddenly vanishes in Fedora (x+2) again.
True. Which is why the 'almost upstream' criterion is useful. We've rarely had to carry new drivers like that for more than one release, have we?
Hi, On 8/4/07, David Woodhouse dwmw2@infradead.org wrote:
On Fri, 2007-08-03 at 21:49 +0200, Thorsten Leemhuis wrote:
But you seem to be really interested in this topic and you are in the committee that is planing to kick kmod's, so it's IMHO your job to ask the Board for its opinion as it allowed kmod#s again not that long ago.
I thought the Board said FESCo would have the right to approve or deny kmod packages. So all FESCo needs to do is say 'no' to them all :)
[...]
I'm just wondering in general about the current happenings -- some months ago the Board issued a statement to allow kmods but now a new FESCo shoots it down again. Well, not my business as well.
We're not saying no to non-upstream kernel modules, which is at the heart of what the board wants (at least from my understanding of the topic). All we're doing is trying to redefine the delivery mechanism so that it is easier for all parties involved.
And davej indicated that he does not want more out-of-kernel modules. That fact and the "at least from my understanding of the topic" IMHO makes it worth to ask the Board for its opinion.
Having just had a conversation with Davej on irc, I can offer these tidbits: [...] So it looks like Dave is absolutely willing to let out of tree kernel modules in, so long as they have a hope of going upstream, or a really really really good reason why we should continue carrying it forward.
Which is hardly a surprising result, since we've been doing it that way for years.
Which leaves a lot of modules out. zaptel,
$DEITY yes, we don't want to be shipping Zaptel until/unless they get off their wossname and make it mergable upstream. There's a _reason_ we're shipping Callweaver (which dropped the crappy dependency on Zaptel just for _timing_, and switched to POSIX timers instead) and not Asterisk.
spca5xx or gspca anyone?
I read lkml and I've never heard of those. I assume therefore that they _deserved_ to be mentioned in the same sentence as zaptel?
Ohh. some one want to more about spca5xx and gpsca kmods? Ok. Here are some of links that you can refer. https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01444.html https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01449.html and why I tried to add those modules is because I have personally tested and used them. Also, If you are not knowing then spca5xx kmod is a part of Ubuntu distribution. Check http://packages.ubuntu.com/feisty/misc/spca5xx-source and its help page is given at https://help.ubuntu.com/community/Spca5xx
He even spoke of perhaps a timeout, [...]
We talked about that before and people said "to dangerous, as people will yell at us when module foo suddenly vanishes in Fedora (x+2) again.
True. Which is why the 'almost upstream' criterion is useful. We've rarely had to carry new drivers like that for more than one release, have we?
Regards, Parag.
On Mon, 2007-08-06 at 12:44 +0530, Parag N(पराग़) wrote:
Ohh. some one want to more about spca5xx and gpsca kmods? Ok. Here are some of links that you can refer.
That doesn't answer the most important question, which is: Why aren't they good enough to be merged upstream? What needs to be fixed before Linus will take them?
Hi, On 8/7/07, David Woodhouse dwmw2@infradead.org wrote:
On Mon, 2007-08-06 at 12:44 +0530, Parag N(पराग़) wrote:
Ohh. some one want to more about spca5xx and gpsca kmods? Ok. Here are some of links that you can refer.
That doesn't answer the most important question, which is: Why aren't they good enough to be merged upstream? What needs to be fixed before Linus will take them?
Thats because Author is not willing to make it upstream and want to maintain his own code in his own source code tree. GSPCA kernel module is already GPLv2. But If a module is well popular in its functionality and use and author is not willing to make it upstream then does that mean then Fedora will never see it as rpm package? Regards, Parag.
Le vendredi 03 août 2007 à 21:49 +0200, Thorsten Leemhuis a écrit :
Which leaves a lot of modules out. zaptel, spca5xx or gspca anyone?
The webcam drivers just need to be upstreamed ivtv was merged upstream and it is a hell more complex than webcam toys
(speaking as someone with spca5xx hardware, so it's not like I can dismiss these because I have no use for them)
On Friday 03 August 2007, Jesse Keating wrote:
He then reviewed the two current kmods:
I'm guessing davej talks about em8300 in the quoted part below:
<davej> this doesn't look like it'd need huge amounts of work to get into an upstreamable state
<davej> it'd need to lose crap like devfs support though
<davej> and all the #ifdef KERNEL_VERSION < 2.5.x junk
<davej> but the key blocker is, is someone going to do the work to get it into that state?
<jwb> davej, ok... so given that if the maintainer was willing to work on that would you let them carry it in the main kernel as a patch?
<davej> jwb: if someone was working on it, sure.
There's some related discussion going on in the em8300-devel mailing list, here's a link to a message I just posted: http://sourceforge.net/mailarchive/forum.php?thread_name=200708050125.29726....
On Fri, Aug 03, 2007 at 07:47:01PM +0200, Thorsten Leemhuis wrote:
On 03.08.2007 19:13, Jesse Keating wrote:
On Fri, 03 Aug 2007 17:57:46 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
As kmods are on the way out in general in Fedora (which is something I in parts agree with) it's even more unlikely now.
kmods as separate packages is what's hopefully on the way out.
As I said, I agree in parts with it -- I'm these days against having them in the "Fedora Everything" spin. But I still think we should have a place for kernel-module packages in the Fedora project. A kind of "alphaworks", "testing kitchen" or something like that for this and other stuff that's not in shape for Fedora proper (or rawhide) yet -- with a big fat warning sign "use on your own risk" "this *will* eat babies" on the front of course. Sure, some people won't read that, but that's not enough reasons to *not* do it IMHO.
It's *essential* that Fedora provide a mechanism for this. To not do so makes the distribution *less free* not more so. FLOSS is so great because of the person choice that it imparts to users - the freedom to do what I, you, or they, want to do with a system. It's not your place, or mine to say what a user should or should not do on their own system.
Fedora should perhaps not ship kmod packages, but there should be a process, there should be a mechanism, and in fact, it should be extended to include online automated updates and various other capabilities missing right now.
Think about why the upstream Linux kernel didn't kill off non-GPL exported symbols (though I don't want to turn this into a binary driver driver discussion per se. everything I'm talking about applies also to non-non-GPL drivers) in the end. User choice. Quite frankly (from my person viewpoint), if a user wants to install a proprietary graphics driver on their system, I think that should be their call. I don't do it myself, and that's my call to make for myself also. Let each person decide how to live their life :-)
Jon.
On Fri, Aug 03, 2007 at 01:13:26PM -0400, Jesse Keating wrote:
On Fri, 03 Aug 2007 17:57:46 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
As kmods are on the way out in general in Fedora (which is something I in parts agree with) it's even more unlikely now.
kmods as separate packages is what's hopefully on the way out. Out of tree modules can still be included in the main kernel rpm. It makes things tramendously easier to keep them in the kernel tree so that they are built right along with the kernel. It's easier on the end user's system too as they always get a kernel with the module they need.
With respect, I completely disagree with this logic. This pre-supposes that Fedora kernels will always include every third party driver that any user might want to use, and that logic is never going to hold. There simply must be a mechanism for third parties to package drivers for Fedora.
And now the kernel maintainers would be the deciders as to what goes in our out of our kernel, so the same criteria that is used for the kernel is now used for kernel modules which is completely fair (everybody plays by the same rules)
Yay! Increasing user choice, by telling them what they can and can't add to their kernels. I completely agree that Fedora doesn't need to own any kmods in the core compose, but there simply must be a packaging process - can I clarify that you want to completely do away with any third party packaged kernel modules, even out of Core? Really?
FWIW, I'm happy to own third party packaging infrastructure, and have BZs assigned to me on the Red Hat end of things for third party drivers.
Fedora -- All my bits are free, are yours?
Yup. Including the drivers I added to my system.
Jon.
On 8/3/07, Kelly lightsolphoenix@gmail.com wrote:
Following that logic, all the -devel packages should be removed as well, because they require compiler tools.
This is a bit of inflammatory logic. Let's see if I can re-orient the discussion. First of all very very few items in the repository actually have a requirement on a compiler.
repoquery --whatrequires --alldeps gcc |wc -l
17
-devel packages shouldn't be pulling in the compiler at all really. The couple that do could be errors in the specfile that need to be corrected. And the devel packages are on their face meant for..developers. They are not expected to provide functionality or just work out of the box. So its difficult to hold the -devel packages up to the same light as potential dkms packages, it's not an apples to apples comparison.
-jef
On Friday, August 03, 2007 1:33 pm Jeff Spaleta wrote:
On 8/3/07, Kelly lightsolphoenix@gmail.com wrote:
Following that logic, all the -devel packages should be removed as well, because they require compiler tools.
This is a bit of inflammatory logic. Let's see if I can re-orient the discussion.
I didn't mean it as inflammatory; I'm just trying to point out that I can go through the main repository and find packages with dependencies on the compilers, so that as a restriction seems odd to me. I can see it if we're talking about the kernel package itself (obviously compilers shouldn't be installed in the base system), but it seems wrong if we're discussing packages not in the kernel package that are technically optional.
And now the kernel maintainers would be the deciders as to what goes in our out of our kernel, so the same criteria that is used for the kernel is now used for kernel modules which is completely fair (everybody plays by the same rules)
Okay. What happens if the kernel maintainers don't want a module in the kernel for some reason (we're seeing one here with the kqemu module)? You have to compile from source? There is a plan for that, right?
On 8/3/07, Kelly lightsolphoenix@gmail.com wrote:
[...]
Okay. What happens if the kernel maintainers don't want a module in the kernel for some reason (we're seeing one here with the kqemu module)? You have to compile from source? There is a plan for that, right?
in this case the compiler is needed anyway so whats wrong with using dkms to automate things?
Kelly wrote:
Okay. What happens if the kernel maintainers don't want a module in the kernel for some reason (we're seeing one here with the kqemu module)? You have to compile from source? There is a plan for that, right?
You can't just assume the kernel developers don't want a module that the developer's have tried to submit as patches publicly in LKML. If the module has no future in the kernel, I don't see how we are going to take on the burden of maintaining it continuously forever. DKMS is a short term hack that will only work when the interface doesn't change and with the 2.6 kernel the amount of changes here are more often.
Rahul