Thread: Re: [Ndiswrapper-general] thoughts on issues with fedora kernels
Status: Beta
Brought to you by:
pgiri
From: David K. <dmk...@uc...> - 2005-01-05 22:35:51
|
Well, On Wed, 2005-01-05 at 13:17 -0800, William Chow wrote: > Why can't you just simply replace the patched kernel > with the stock kernel in Fedora? Why do you have to > specifically run the patched kernel in fedora? Are I can replace the fedora kernel with the generic kernel, but I also have to get work done and recompiling the kernel or finding a generic kernel rpm is a time sync that I just can't afford personally. Furthermore, many of redhat's patches are security related or enhancements. If I use the generic kernel I gain ndiswrapper, but lose the other perks. Finally, a lot of people who just want to get their wireless working don't have the savvy or time to build another kernel. By limiting ndiswrapper to just those that do, you loose a lot of your potential audience. > The stock kernel is the reference kernel that people > need to develop on. If a distro decides to patch the > kernel in a incompatible way, well... > Absolutely, but I never suggested we develop for a distribution specific kernel. All I suggested was a conversation with important distributions to (1) make them aware of how their kernels can cause problems for ndiswrapper and (2) see if there are easy ways to fix conflicts. Cheers, David |
From: Michael R. <mic...@ci...> - 2005-01-06 00:19:44
|
David Kaplan wrote: > Well, > > On Wed, 2005-01-05 at 13:17 -0800, William Chow wrote: > >>Why can't you just simply replace the patched kernel >>with the stock kernel in Fedora? Why do you have to >>specifically run the patched kernel in fedora? Are > > > I can replace the fedora kernel with the generic kernel, but I also have > to get work done and recompiling the kernel or finding a generic kernel > rpm is a time sync that I just can't afford personally. Furthermore, > many of redhat's patches are security related or enhancements. If I use > the generic kernel I gain ndiswrapper, but lose the other perks. > > Finally, a lot of people who just want to get their wireless working > don't have the savvy or time to build another kernel. By limiting > ndiswrapper to just those that do, you loose a lot of your potential > audience. > > >>The stock kernel is the reference kernel that people >>need to develop on. If a distro decides to patch the >>kernel in a incompatible way, well... >> > > > Absolutely, but I never suggested we develop for a distribution specific > kernel. All I suggested was a conversation with important distributions > to (1) make them aware of how their kernels can cause problems for > ndiswrapper and (2) see if there are easy ways to fix conflicts. I think the work needs to be done to make it compile with the generic kernel. Red Hat has always been known for changing things just to change them. I agree that this happens less with Fedora but except in extreme cases incompatible changes are bad engineering. So I would think discussions with the people making incompatible changes are appropriate but no additional effort should be expended. michael > > Cheers, > David > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Ndiswrapper-general mailing list > Ndi...@li... > https://lists.sourceforge.net/lists/listinfo/ndiswrapper-general -- ---- ---- ---- Michael Reilly mic...@ci... Cisco Systems, California |
From: David K. <dmk...@uc...> - 2005-01-06 01:22:58
|
> I think the work needs to be done to make it compile with the generic > kernel. Red Hat has always been known for changing things just to change > them. I agree that this happens less with Fedora but except in extreme > cases incompatible changes are bad engineering. So I would think > discussions with the people making incompatible changes are appropriate but > no additional effort should be expended. > Well, this would be true except that, as Gerald Henriksen mentioned, for better or worse Fedora kernels have become a test ground for new stuff in the generic kernels. As a result, ndiswrapper problems with fedora at times suggest future problems for the generic kernel. In particular, Gerald's comments appear to indicate that the missing "task_nice" will soon be coming to the generic kernel and therefore needs to be dealt with. Given this, whether people love or hate fedora, some attention needs to be paid (by the way, I am not sure which fedora camp I am in). |
From: William C. <wil...@ya...> - 2005-01-06 01:35:41
|
> Well, this would be true except that, as Gerald > Henriksen mentioned, for > better or worse Fedora kernels have become a test > ground for new stuff > in the generic kernels. As a result, ndiswrapper > problems with fedora > at times suggest future problems for the generic > kernel. In particular, > Gerald's comments appear to indicate that the > missing "task_nice" will > soon be coming to the generic kernel and therefore > needs to be dealt > with. > > Given this, whether people love or hate fedora, some > attention needs to > be paid (by the way, I am not sure which fedora camp > I am in). With all due respect, I would think things like making the kernel memory stack static at 4k wouldn't make it into the standard kernel. It would appear to break too many things. I don't think you can assume that all of Cox's bleeding edge patches make it into the final standard kernel, and ndiswrapper being quite popular, I don't think that standard will introduce changes that would break ndiswrapper. As mentioned before, it's one of the prime motivating factors to move AWAY from RH/FC. Also, changes to ndiswrapper to specifically facilitate Cox's requirements could lead to backwards incompatiblity, so therefore another branch would have to be created specifically for FC. My point is that if ndiswrapper already runs on 90% of the distros without problems, then it's not really ndiswrapper's priority to accomodate FC. I realize recompiling the kernel to standard isn't everyone's cup of tea, but if you're going to be recompiling ndiswrapper anyway, you might as well just recompile the kernel while you're at it. It's not that much more of a burden to place on the user. AFAIK Cox's patches are a constant moving target, so it would be difficult for maintainers to pinpoint which versions they would support since the Cox patch list never guarentees backwards compatibility. Sincerely, Will __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com |
From: David K. <dmk...@uc...> - 2005-01-06 01:59:49
|
> With all due respect, I would think things like making > the kernel memory stack static at 4k wouldn't make it > into the standard kernel. It would appear to break too > many things. I don't think you can assume that all of > Cox's bleeding edge patches make it into the final > standard kernel, and ndiswrapper being quite popular, Read my original email. I was very careful to state that sometimes his patches make it into the standard kernel, which is one of the reasons to talk to him - it would be nice to know which ones are permanent. Furthermore, I was talking about the "task_nice" undefined problem in my last email. From the fedora-devel list comments that gerald sent it looks like this problem is here to stay. The 4k issue is not as big a deal as linuxant has their kernels. Above and beyond all of this, if no one makes the problems aware to people like Alan Cox, they will become part of the standard kernel, regardless of what it does to ndiswrapper. Cheers, David |
From: William C. <wil...@ya...> - 2005-01-06 03:25:31
|
Yes, I read your original email. The issue isn't whether Cox's specific changes will or won't make it to the final kernel. The issue is whether or not it's worth tracking Cox's changes BEFORE they make it into the final kernel. If these changes do make it into the final kernel and do break ndiswrapper then ndiswrapper just needs to get around it. Before it makes it into the final kernel, the point is rather moot. Also, Cox has made it a point that his patchset is by no means sanctioned as canon kernel source. If it does become canon then it ndiswrapper needs to change, not the kernel. Making Cox aware of the fact that these changes break ndiswrapper is, of course, useful. However, it's not something that should be priority one because it's not really mission critical at this point. Will --- David Kaplan <dmk...@uc...> wrote: > > With all due respect, I would think things like > making > > the kernel memory stack static at 4k wouldn't make > it > > into the standard kernel. It would appear to break > too > > many things. I don't think you can assume that all > of > > Cox's bleeding edge patches make it into the final > > standard kernel, and ndiswrapper being quite > popular, > > Read my original email. I was very careful to state > that sometimes his > patches make it into the standard kernel, which is > one of the reasons to > talk to him - it would be nice to know which ones > are permanent. > > Furthermore, I was talking about the "task_nice" > undefined problem in my > last email. From the fedora-devel list comments > that gerald sent it > looks like this problem is here to stay. The 4k > issue is not as big a > deal as linuxant has their kernels. > > Above and beyond all of this, if no one makes the > problems aware to > people like Alan Cox, they will become part of the > standard kernel, > regardless of what it does to ndiswrapper. > > Cheers, > David > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the > post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt > from ThinkGeek. > It's fun and FREE -- well, > almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Ndiswrapper-general mailing list > Ndi...@li... > https://lists.sourceforge.net/lists/listinfo/ndiswrapper-general > __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 |
From: Gerald H. <ghe...@ro...> - 2005-01-06 04:52:51
|
On Wed, 5 Jan 2005 17:35:34 -0800 (PST), you wrote: >With all due respect, I would think things like making >the kernel memory stack static at 4k wouldn't make it >into the standard kernel. It would appear to break too >many things. I don't think you can assume that all of >Cox's bleeding edge patches make it into the final >standard kernel, and ndiswrapper being quite popular, >I don't think that standard will introduce changes >that would break ndiswrapper. As mentioned before, Sorry, but 4k stacks is part of the official kernel, witness the discussions about it in the linux kernel mailing list archives (it was introduced with 2.6.6). In fact according the kernel mailing list they did extensive testing to ensure that everything in the kernel worked with 4k stacks, and the fact that there have now been 2 releases of Fedora Core using 4k stacks with little to no problems except for the Windows binary driver issue indicates that they don't break things. >it's one of the prime motivating factors to move AWAY >from RH/FC. Also, changes to ndiswrapper to >specifically facilitate Cox's requirements could lead Note that while Alan Cox is a Red Hat employee and is involved with =46edora he is not packaging the Fedora kernels. The people responsible for the Fedora kernels are Dave Jones and Arjan van de Ven I believe. >to backwards incompatiblity, so therefore another >branch would have to be created specifically for FC. >My point is that if ndiswrapper already runs on 90% of >the distros without problems, then it's not really >ndiswrapper's priority to accomodate FC. I realize The point is that the features that cause problems in the Fedora kernels are in the process of going mainstream. It just happens that =46edora is among the first to implement the new kernel features. >recompiling the kernel to standard isn't everyone's >cup of tea, but if you're going to be recompiling >ndiswrapper anyway, you might as well just recompile >the kernel while you're at it. It's not that much more >of a burden to place on the user. It is a significant burden. Recompiling ndiswrapper takes less than 30 seconds, a kernel compile takes significantly longer and a lot more expertise/experience. |
From: William C. <wil...@ya...> - 2005-01-06 05:31:01
|
--- Gerald Henriksen <ghe...@ro...> wrote: > Sorry, but 4k stacks is part of the official kernel, Well, that's very different from being simply one of "Cox's patches" vs. being in official canon source. Also, since 4k stacks were introduced recently, then I'm sure you can back out that particular patch. > witness the > discussions about it in the linux kernel mailing > list archives (it was > introduced with 2.6.6). In fact according the Unfortunately the 2.6.x kernels break a lot of things, which will have to be dealt with as ndiswrapper moves forward. > kernel mailing list > they did extensive testing to ensure that everything > in the kernel > worked with 4k stacks, and the fact that there have > now been 2 > releases of Fedora Core using 4k stacks with little > to no problems > except for the Windows binary driver issue indicates > that they don't > break things. Well, by definition then it does break something and it will greatly affect adoptation of linux on the laptop, at least utilizing 2.6 kernel distros. > > Note that while Alan Cox is a Red Hat employee and > is involved with > Fedora he is not packaging the Fedora kernels. > Don't see what that really has to do with anything. Fact is that RH has had a history of breaking things with each release, as witnessed by past stunts like RH8->RH9 libc problems that broke almost every precompiled binaries up to that point. This wouldn't be an issue if you work only on source-code-available programs, but unfortunately that just doesn't cut it in production machines that need to run commercial software. > The point is that the features that cause problems > in the Fedora > kernels are in the process of going mainstream. It If they are then ndiswrapper will have to deal with them once they do. The problem here is that some people are positing that these changes are Cox patches and you are stating that they are in canon code. If it's the latter then ndiswrapper obviously needs to deal with them. > just happens that > Fedora is among the first to implement the new > kernel features. > Yes, and RH really shouldn't, being one of the older and more popular distros. It's a big problem. > It is a significant burden. Recompiling ndiswrapper > takes less than > 30 seconds, a kernel compile takes significantly > longer and a lot more > expertise/experience. Well, I don't know what kind of computer you run, but recompiling the kernel is pretty much a requisite if you're going to be running Linux on a laptop. There are enough weird drivers that need to be patched into the typical laptop setup that you essentially need to compile a custom kernel anyway for things like ACPI to work properly, so I don't buy the "oh, it'll save me a two-three hours of compile time" mantra. And let's face it, 90% of the people who utilize ndiswrapper do so on laptops. Having said that I'll stop commenting on this issue since the signal/noise ratio is degrading. However, I agree with you that if there are problems with the 2.6 tree then ndiswrapper needs to talk to the kernel-dev list. Sincerely, Will __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail |
From: Jonathan B. <be...@gm...> - 2005-01-06 06:11:05
|
On Wed, 5 Jan 2005 21:30:57 -0800 (PST), William Chow <wil...@ya...> wrote: > --- Gerald Henriksen <ghe...@ro...> wrote: [snip] > > just happens that > > Fedora is among the first to implement the new > > kernel features. > > > Yes, and RH really shouldn't, being one of the older > and more popular distros. It's a big problem. Why? RedHat states very clearly that Fedora is a sort of testing/proving grounds for features that will eventually make their way into their "comercial" (ie RHEL et al) line of distrobutions. It's bleeding edge in some cases, but in some cases I think that makes it better. Especially since I have an AMD64 machine. > > It is a significant burden. Recompiling ndiswrapper > > takes less than > > 30 seconds, a kernel compile takes significantly > > longer and a lot more > > expertise/experience. > > Well, I don't know what kind of computer you run, but > recompiling the kernel is pretty much a requisite if > you're going to be running Linux on a laptop. There > are enough weird drivers that need to be patched into > the typical laptop setup that you essentially need to > compile a custom kernel anyway for things like ACPI > to work properly, so I don't buy the "oh, it'll save > me a two-three hours of compile time" mantra. And > let's face it, 90% of the people who utilize > ndiswrapper do so on laptops. Actually, stock Fedora Core has run quite well on my AMD64 laptop The only issue I have is that the touchpad doesn't work with psmouse not being a module, and that is a BIOS issue. Of course, ndiswrapper has issues, but it also has issues with my 64-bit architecture at the moment. > Having said that I'll stop commenting on this issue > since the signal/noise ratio is degrading. > > However, I agree with you that if there are problems > with the 2.6 tree then ndiswrapper needs to talk to > the kernel-dev list. Being a Fedora user, I would definitely appreciate the developers taking into consideration problems with ndiswrapper on Fedora. It seems that the general trend is that features in the Fedora kernels are likely to migrate down to the vanila kernels at some point. So my question is, why not go ahead and deal with it? If you have to choose between supporting the vanila kernels and the Fedora kernels, then go ahead and choose the vanila, since that is the policy. I don't see the benefit to ignoring the problems with the Fedora kernels when it seems likely that these problems will need to be dealt with eventually. Just some thoughts. By the way, it seems like there are some work-arounds for at least some of the problems: http://fedoraforum.org/forum/showthread.php?t=30416 Acually, I could not find any hint of "task_nice" in the latest cvs code. > Sincerely, > > Will Jonathan |
From: William C. <wil...@ya...> - 2005-01-05 23:18:22
|
Yes, I completely understand where you're coming from and I empathize. Is ndiswrapper only generally broken with the bleeding edge fedora Core kernels, or is it broken with other popular distros? I find it somewhat disturbing that Cox and Co. have decided to make Fedore Core a test station for patched bleeding edge untried kernels. I suppose since it's in RC format that they have a right to do this to one of the more popular distros around. I'm guessing that kernel changes like the ones that break ndiswrapper in FC would break many other type of drivers. Has anyone else reported on this? Will --- David Kaplan <dmk...@uc...> wrote: > Well, > > On Wed, 2005-01-05 at 13:17 -0800, William Chow > wrote: > > Why can't you just simply replace the patched > kernel > > with the stock kernel in Fedora? Why do you have > to > > specifically run the patched kernel in fedora? Are > > I can replace the fedora kernel with the generic > kernel, but I also have > to get work done and recompiling the kernel or > finding a generic kernel > rpm is a time sync that I just can't afford > personally. Furthermore, > many of redhat's patches are security related or > enhancements. If I use > the generic kernel I gain ndiswrapper, but lose the > other perks. > > Finally, a lot of people who just want to get their > wireless working > don't have the savvy or time to build another > kernel. By limiting > ndiswrapper to just those that do, you loose a lot > of your potential > audience. > > > The stock kernel is the reference kernel that > people > > need to develop on. If a distro decides to patch > the > > kernel in a incompatible way, well... > > > > Absolutely, but I never suggested we develop for a > distribution specific > kernel. All I suggested was a conversation with > important distributions > to (1) make them aware of how their kernels can > cause problems for > ndiswrapper and (2) see if there are easy ways to > fix conflicts. > > Cheers, > David > > > __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail |