Thread: [Ndiswrapper-general] grep failures when compiling for Fedora kernel
Status: Beta
Brought to you by:
pgiri
From: Pavel R. <pr...@gn...> - 2006-11-10 06:32:56
|
Hello! Compiling ndiswrapper for the stock Fedora Core 6 kernel doesn't look pretty: $ make make -C driver make[1]: Entering directory `/home/proski/src/ndiswrapper/driver' make -C /lib/modules/2.6.18-1.2798.fc6/build SUBDIRS=/home/proski/src/ndiswrapper/driver make[2]: Entering directory `/usr/src/kernels/2.6.18-1.2798.fc6-i686' grep: /lib/modules/2.6.18-1.2798.fc6/source/kernel/module.c: No such file or directory LD /home/proski/src/ndiswrapper/driver/built-in.o grep: /lib/modules/2.6.18-1.2798.fc6/source/kernel/module.c: No such file or directory grep: /lib/modules/2.6.18-1.2798.fc6/source/kernel/module.c: No such file or directory grep: /lib/modules/2.6.18-1.2798.fc6/source/kernel/module.c: No such file or directory grep: /lib/modules/2.6.18-1.2798.fc6/source/kernel/module.c: No such file or directory grep: /lib/modules/2.6.18-1.2798.fc6/source/kernel/module.c: No such file or directory CC [M] /home/proski/src/ndiswrapper/driver/crt.o ... I understand the makefile check for module.c to determine whether to use out own workqueue dependent on whether module.c blacklist ndiswrapper as a tainted module. I think it's a misguided approach. Possible solutions: Always use our work queue. This would be good because the same code would be used by everyone, simplifying debugging. One possible downside is that our code may not be as good. Rename ndiswrapper and use the standard workqueue. It may irritate some kernel developers, but I doubt that the kernel developers will engage in a cat-and-mouse game to lock out ndiswrapper. After all, the restricted access to the GPLed symbols for ndiswrapper is considered a bug. Use the kernel work queue. We are not supposed to work around bugs in kernel's release candidates. -- Regards, Pavel Roskin |
From: Kel M. <ke...@ka...> - 2006-11-10 06:45:23
|
On Friday 10 November 2006 16:32, Pavel Roskin wrote: > Possible solutions: > > Always use our work queue. This would be good because the same code > would be used by everyone, simplifying debugging. One possible downside > is that our code may not be as good. > > Rename ndiswrapper and use the standard workqueue. It may irritate some > kernel developers, but I doubt that the kernel developers will engage in > a cat-and-mouse game to lock out ndiswrapper. After all, the restricted > access to the GPLed symbols for ndiswrapper is considered a bug. > > Use the kernel work queue. We are not supposed to work around bugs in > kernel's release candidates. Yep. The ndiswrapper blacklist was a transient change in the early release candidate phase and, as Pavel said, also considered to be a bug. I'd probably encourage the latter approach, as it seems to have been doing the job fine up until this time. Thanks, Kel. |
From: Giridhar P. <pg...@ya...> - 2006-11-10 07:33:26
|
--- Pavel Roskin <pr...@gn...> wrote: > Always use our work queue. This would be good because the same code > would be used by everyone, simplifying debugging. One possible downside > is that our code may not be as good. I believe the workqueue in ndiswrapper is kosher. At least it survived my testing with a few drivers. However, if there is no need to use it (and use kernel's implementation), then it is better - less bloat (even if it is very small), less susceptible for changes in workqueue implementation etc. > Use the kernel work queue. We are not supposed to work around bugs in > kernel's release candidates. How about following patch? I haven't tested it, but IIUC what is causing the error messages, it should work. Thanks, Giri Index: Makefile =================================================================== --- Makefile (revision 2098) +++ Makefile (working copy) @@ -119,7 +119,7 @@ OBJS += workqueue.o endif -CFLAGS += $(shell if grep -A1 'ndiswrapper' $(KSRC)/kernel/module.c | \ +CFLAGS += $(shell if grep -q -A1 'ndiswrapper' $(KSRC)/kernel/module.c | \ grep -q 'add_taint_module' ; then \ echo -DUSE_OWN_WQ; \ ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com |
From: Pavel R. <pr...@gn...> - 2006-11-10 08:15:12
|
Quoting Giridhar Pemmasani <pg...@ya...>: > How about following patch? I haven't tested it, but IIUC what is causing the > error messages, it should work. > -CFLAGS += $(shell if grep -A1 'ndiswrapper' $(KSRC)/kernel/module.c | \ > +CFLAGS += $(shell if grep -q -A1 'ndiswrapper' $(KSRC)/kernel/module.c | \ > grep -q 'add_taint_module' ; then \ > echo -DUSE_OWN_WQ; \ Sounds reasonable, at least in the short term, i.e. until 2.6.19 is released and merged to all topic git trees on kernel.org. Kernels without sources would use the kernel workqueue. That's likely to be vendor kernels or kernels compiled from stable sources, or kernels compiled long ago. Either way it's OK. -- Regards, Pavel Roskin |
From: Giridhar P. <pg...@ya...> - 2006-11-10 12:47:24
|
--- Pavel Roskin <pr...@gn...> wrote: > Sounds reasonable, at least in the short term, i.e. until 2.6.19 is > released and > merged to all topic git trees on kernel.org. Committed patch suggested earlier. > Kernels without sources would use the kernel workqueue. That's likely to > be > vendor kernels or kernels compiled from stable sources, or kernels compiled > long ago. Either way it's OK. Forgot to mention that we may want to prefer in-kernel workqueue, as we need per-processor workqueues (which are not implemented in ndiswrapper) to support Vista drivers - I am working on adding support for Vista (NDIS 6.0) drivers. Giri ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com |
From: Pavel R. <pr...@gn...> - 2006-11-10 21:51:47
|
Hi Giri, On Thu, 2006-11-09 at 23:33 -0800, Giridhar Pemmasani wrote: > How about following patch? I haven't tested it, but IIUC what is causing the > error messages, it should work. I'm sorry, I didn't test your patch either! What we need is actually "-s", not "-q", as the later doesn't suppress error messages. Actually, "-q" is very wrong here as it would suppress standard output that goes to the next grep in pipe! [proski@dv kernel]$ grep -q -A1 'ndiswrapper' module.c [proski@dv kernel]$ grep -q -A1 'ndiswrapper' module1.c grep: module1.c: No such file or directory [proski@dv kernel]$ grep -s -A1 'ndiswrapper' module.c if (strcmp(mod->name, "ndiswrapper") == 0) add_taint(TAINT_PROPRIETARY_MODULE); [proski@dv kernel]$ grep -s -A1 'ndiswrapper' module1.c [proski@dv kernel]$ Please apply this patch (actually tested): Index: driver/Makefile =================================================================== --- driver/Makefile (revision 2101) +++ driver/Makefile (working copy) @@ -119,7 +119,7 @@ OBJS += workqueue.o endif -CFLAGS += $(shell if grep -q -A1 'ndiswrapper' $(KSRC)/kernel/module.c | \ +CFLAGS += $(shell if grep -s -A1 'ndiswrapper' $(KSRC)/kernel/module.c | \ grep -q 'add_taint_module' ; then \ echo -DUSE_OWN_WQ; \ fi) And now that the overwhelming grep warnings are gone, I see that I have missed a much more important warning. The Fedora kernel is compiled with 4k stacks, which may explain the failure of the Atmel USB driver. More about it when I have more information. -- Regards, Pavel Roskin |
From: Giridhar P. <pg...@ya...> - 2006-11-10 23:53:22
|
--- Pavel Roskin <pr...@gn...> wrote: > I'm sorry, I didn't test your patch either! What we need is actually > "-s", not "-q", as the later doesn't suppress error messages. Actually, > "-q" is very wrong here as it would suppress standard output that goes > to the next grep in pipe! Doh! Applied. Thanks, Giri ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited |