Re: Trying to convert old modules to newer kernels
On Thu, 2007-12-20 at 11:27 -0500, Lennart Sorensen wrote: > On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote: > > It never gets to the printk(). You were right about the > > compilation. Somebody changed the kernel to compile with > > parameter passing in REGISTERS! This means that EVERYTHING > > needs to be compiled the same way, 'C' calling conventions > > were not good enough! > > > > FYI, it has been previously shown that passing parameters > > in registers on register-starved ix86 machines is always > > a loss, because the registers need to be freed up, either > > by saving them on the stack or as dummy memory variables. > > > > Now, they've done it to the entire kernel! > > It's a config option. I think redhat was the first to actually start > using it on their distributions. Many distributions don't use it. > Debian does not use it on their kernels. And anyway, what's wrong with having the kernel build scripts build the module for you? ;-) Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 2007-12-20 at 11:27 -0500, Lennart Sorensen wrote: On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! FYI, it has been previously shown that passing parameters in registers on register-starved ix86 machines is always a loss, because the registers need to be freed up, either by saving them on the stack or as dummy memory variables. Now, they've done it to the entire kernel! It's a config option. I think redhat was the first to actually start using it on their distributions. Many distributions don't use it. Debian does not use it on their kernels. And anyway, what's wrong with having the kernel build scripts build the module for you? ;-) Jon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
Lennart Sorensen wrote: On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Well I guess you can either fix the assembly once and for all to handle the current linux way of doing things, or you can patch to kernel back to the old ways of doing things when using your driver. I suppose you could just add some wrapper functions to your assembly that uses the new regparm calling method and then calls your methods the old way and selectively enable those when regparm is used by the kernel if you want to support all kernel versions. Or you could use inline assembly in C functions to handle the calling convention for you. If I were to guess, based on nothing but what's in this thread, people who write modules in assembler would want to avoid the the wrapper overhead. Of course putting image processing in the kernel at all instead of user programs is not something I ever do... -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
James Courtier-Dutton wrote: J.A. Magallón wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Just for curiosity... yep, I understand now you have everything written in assembler, but why not consider start writing it in C and stop doing the compiler work (such as pipelining, out of order reordering, loop unrolling for specific processor, and so on...) That's what everyone taught me, nowadays you won't be better than the compiler in anything longer than three lines... Not true for image processing. compilers are not too good with optimizing mmx and sse algorithms. This is why user space libraries like ffmpeg still use assembly code. If half of what I read about the Intel compiler is true, that may no longer be true. That being said, I don't think sse and mmx are available in kernel space, so I would have suggested doing all the grunt work in userspace would be better for this persons application so that he could use sse and mmx etc. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
James Courtier-Dutton wrote: J.A. Magallón wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Just for curiosity... yep, I understand now you have everything written in assembler, but why not consider start writing it in C and stop doing the compiler work (such as pipelining, out of order reordering, loop unrolling for specific processor, and so on...) That's what everyone taught me, nowadays you won't be better than the compiler in anything longer than three lines... Not true for image processing. compilers are not too good with optimizing mmx and sse algorithms. This is why user space libraries like ffmpeg still use assembly code. If half of what I read about the Intel compiler is true, that may no longer be true. That being said, I don't think sse and mmx are available in kernel space, so I would have suggested doing all the grunt work in userspace would be better for this persons application so that he could use sse and mmx etc. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
Lennart Sorensen wrote: On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Well I guess you can either fix the assembly once and for all to handle the current linux way of doing things, or you can patch to kernel back to the old ways of doing things when using your driver. I suppose you could just add some wrapper functions to your assembly that uses the new regparm calling method and then calls your methods the old way and selectively enable those when regparm is used by the kernel if you want to support all kernel versions. Or you could use inline assembly in C functions to handle the calling convention for you. If I were to guess, based on nothing but what's in this thread, people who write modules in assembler would want to avoid the the wrapper overhead. Of course putting image processing in the kernel at all instead of user programs is not something I ever do... -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Fri, 21 Dec 2007, Lennart Sorensen wrote: > On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: >> I need to get rid of -mregparm=3 on gcc's command line. It >> is completely incompatible with the standard calling conventions >> used in all our assembly-language files in our drivers. We make >> very high-speed number-crunching drivers that munge high-speed >> data into images. We need to do that in assembly as we have >> always done. > > Well I guess you can either fix the assembly once and for all to handle > the current linux way of doing things, or you can patch to kernel back > to the old ways of doing things when using your driver. > > I suppose you could just add some wrapper functions to your assembly > that uses the new regparm calling method and then calls your methods the > old way and selectively enable those when regparm is used by the kernel > if you want to support all kernel versions. Or you could use inline > assembly in C functions to handle the calling convention for you. > > -- > Len Sorensen > It's easier that that, just declare the assembly-language functions to be of type __attribute((regparm=0))__ or however you spell it (I'm not at my usual machine)! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Fri, 21 Dec 2007, Lennart Sorensen wrote: > On Thu, Dec 20, 2007 at 05:56:19PM -0500, linux-os (Dick Johnson) wrote: >> Okay. Thanks! I need to do that. > > On the (now somewhat old) 2.6.18 kernel I use it is an option under > "Processor type and features" called "Use register arguments", but yeah > it isn't an option anymore in new kernels. > > As for your argument that it isn't a good idea, well most of the time > the arguments you want to pass to a function are already values you were > just working with to get them ready for the function, so quite likely > they are already in the registers you are worried about having to clear > first. Add to that the ability of modern x86 CPUs to use rename > registers to fake stack accesses in some cases and the clearing of the > registers become pretty much a non issue, at least that's my > understanding of how things work. > > -- > Len Sorensen > If the procedures in different files or are in libraries, there is no way for the compiler to "know." Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: > I need to get rid of -mregparm=3 on gcc's command line. It > is completely incompatible with the standard calling conventions > used in all our assembly-language files in our drivers. We make > very high-speed number-crunching drivers that munge high-speed > data into images. We need to do that in assembly as we have > always done. Well I guess you can either fix the assembly once and for all to handle the current linux way of doing things, or you can patch to kernel back to the old ways of doing things when using your driver. I suppose you could just add some wrapper functions to your assembly that uses the new regparm calling method and then calls your methods the old way and selectively enable those when regparm is used by the kernel if you want to support all kernel versions. Or you could use inline assembly in C functions to handle the calling convention for you. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, Dec 20, 2007 at 05:56:19PM -0500, linux-os (Dick Johnson) wrote: > Okay. Thanks! I need to do that. On the (now somewhat old) 2.6.18 kernel I use it is an option under "Processor type and features" called "Use register arguments", but yeah it isn't an option anymore in new kernels. As for your argument that it isn't a good idea, well most of the time the arguments you want to pass to a function are already values you were just working with to get them ready for the function, so quite likely they are already in the registers you are worried about having to clear first. Add to that the ability of modern x86 CPUs to use rename registers to fake stack accesses in some cases and the clearing of the registers become pretty much a non issue, at least that's my understanding of how things work. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Bodo Eggert wrote: > linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote: >> On Thu, 20 Dec 2007, Sam Ravnborg wrote: > It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! >>> >>> How did you build the module. It reads like you failed to use >>> kbuild to build your module which is why you did not pass >>> correct options to gcc - correct? >>> >>> If you did not use kbuild - why not? >>> Is there anything missing you need? > >> I need to get rid of -mregparm=3 on gcc's command line. It >> is completely incompatible with the standard calling conventions >> used in all our assembly-language files in our drivers. We make >> very high-speed number-crunching drivers that munge high-speed >> data into images. We need to do that in assembly as we have >> always done. > > According to my quick googling, "__attribute__((regparm,0))" is what you need. > Yes, thanks! I don't need to change anything except the declarations of the assembly-language stuff. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Dec 21 2007 12:08, James Courtier-Dutton wrote: > That being said, I don't think sse and mmx are available in kernel > space, so I would have suggested doing all the grunt work in > userspace would be better for this persons application so that he > could use sse and mmx etc. > They are available, you just need to pay attention not to trash a process's context. IIRC this has been done for 387 FPUting. (The 'trigger' thing in save_i387() in arch/x86/i387_32.c probably.) Probably not for SSE. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
J.A. Magallón wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Just for curiosity... yep, I understand now you have everything written in assembler, but why not consider start writing it in C and stop doing the compiler work (such as pipelining, out of order reordering, loop unrolling for specific processor, and so on...) That's what everyone taught me, nowadays you won't be better than the compiler in anything longer than three lines... Not true for image processing. compilers are not too good with optimizing mmx and sse algorithms. This is why user space libraries like ffmpeg still use assembly code. That being said, I don't think sse and mmx are available in kernel space, so I would have suggested doing all the grunt work in userspace would be better for this persons application so that he could use sse and mmx etc. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Bodo Eggert wrote: linux-os (Dick Johnson) [EMAIL PROTECTED] wrote: On Thu, 20 Dec 2007, Sam Ravnborg wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! How did you build the module. It reads like you failed to use kbuild to build your module which is why you did not pass correct options to gcc - correct? If you did not use kbuild - why not? Is there anything missing you need? I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. According to my quick googling, __attribute__((regparm,0)) is what you need. Yes, thanks! I don't need to change anything except the declarations of the assembly-language stuff. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
J.A. Magallón wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Just for curiosity... yep, I understand now you have everything written in assembler, but why not consider start writing it in C and stop doing the compiler work (such as pipelining, out of order reordering, loop unrolling for specific processor, and so on...) That's what everyone taught me, nowadays you won't be better than the compiler in anything longer than three lines... Not true for image processing. compilers are not too good with optimizing mmx and sse algorithms. This is why user space libraries like ffmpeg still use assembly code. That being said, I don't think sse and mmx are available in kernel space, so I would have suggested doing all the grunt work in userspace would be better for this persons application so that he could use sse and mmx etc. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, Dec 20, 2007 at 05:56:19PM -0500, linux-os (Dick Johnson) wrote: Okay. Thanks! I need to do that. On the (now somewhat old) 2.6.18 kernel I use it is an option under Processor type and features called Use register arguments, but yeah it isn't an option anymore in new kernels. As for your argument that it isn't a good idea, well most of the time the arguments you want to pass to a function are already values you were just working with to get them ready for the function, so quite likely they are already in the registers you are worried about having to clear first. Add to that the ability of modern x86 CPUs to use rename registers to fake stack accesses in some cases and the clearing of the registers become pretty much a non issue, at least that's my understanding of how things work. -- Len Sorensen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Dec 21 2007 12:08, James Courtier-Dutton wrote: That being said, I don't think sse and mmx are available in kernel space, so I would have suggested doing all the grunt work in userspace would be better for this persons application so that he could use sse and mmx etc. They are available, you just need to pay attention not to trash a process's context. IIRC this has been done for 387 FPUting. (The 'trigger' thing in save_i387() in arch/x86/i387_32.c probably.) Probably not for SSE. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Well I guess you can either fix the assembly once and for all to handle the current linux way of doing things, or you can patch to kernel back to the old ways of doing things when using your driver. I suppose you could just add some wrapper functions to your assembly that uses the new regparm calling method and then calls your methods the old way and selectively enable those when regparm is used by the kernel if you want to support all kernel versions. Or you could use inline assembly in C functions to handle the calling convention for you. -- Len Sorensen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Fri, 21 Dec 2007, Lennart Sorensen wrote: On Thu, Dec 20, 2007 at 05:56:19PM -0500, linux-os (Dick Johnson) wrote: Okay. Thanks! I need to do that. On the (now somewhat old) 2.6.18 kernel I use it is an option under Processor type and features called Use register arguments, but yeah it isn't an option anymore in new kernels. As for your argument that it isn't a good idea, well most of the time the arguments you want to pass to a function are already values you were just working with to get them ready for the function, so quite likely they are already in the registers you are worried about having to clear first. Add to that the ability of modern x86 CPUs to use rename registers to fake stack accesses in some cases and the clearing of the registers become pretty much a non issue, at least that's my understanding of how things work. -- Len Sorensen If the procedures in different files or are in libraries, there is no way for the compiler to know. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Fri, 21 Dec 2007, Lennart Sorensen wrote: On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Well I guess you can either fix the assembly once and for all to handle the current linux way of doing things, or you can patch to kernel back to the old ways of doing things when using your driver. I suppose you could just add some wrapper functions to your assembly that uses the new regparm calling method and then calls your methods the old way and selectively enable those when regparm is used by the kernel if you want to support all kernel versions. Or you could use inline assembly in C functions to handle the calling convention for you. -- Len Sorensen It's easier that that, just declare the assembly-language functions to be of type __attribute((regparm=0))__ or however you spell it (I'm not at my usual machine)! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote: > On Thu, 20 Dec 2007, Sam Ravnborg wrote: >>> It never gets to the printk(). You were right about the >>> compilation. Somebody changed the kernel to compile with >>> parameter passing in REGISTERS! This means that EVERYTHING >>> needs to be compiled the same way, 'C' calling conventions >>> were not good enough! >> >> How did you build the module. It reads like you failed to use >> kbuild to build your module which is why you did not pass >> correct options to gcc - correct? >> >> If you did not use kbuild - why not? >> Is there anything missing you need? > I need to get rid of -mregparm=3 on gcc's command line. It > is completely incompatible with the standard calling conventions > used in all our assembly-language files in our drivers. We make > very high-speed number-crunching drivers that munge high-speed > data into images. We need to do that in assembly as we have > always done. According to my quick googling, "__attribute__((regparm,0))" is what you need. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007 18:05:48 -0500, "linux-os (Dick Johnson)" <[EMAIL PROTECTED]> wrote: > > On Thu, 20 Dec 2007, Sam Ravnborg wrote: > > > On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: > >> > >> On Thu, 20 Dec 2007, Sam Ravnborg wrote: > >> > > It never gets to the printk(). You were right about the > compilation. Somebody changed the kernel to compile with > parameter passing in REGISTERS! This means that EVERYTHING > needs to be compiled the same way, 'C' calling conventions > were not good enough! > >>> > >>> How did you build the module. It reads like you failed to use > >>> kbuild to build your module which is why you did not pass > >>> correct options to gcc - correct? > >>> > >>> If you did not use kbuild - why not? > >>> Is there anything missing you need? > >>> > >> > >> I need to get rid of -mregparm=3 on gcc's command line. It > >> is completely incompatible with the standard calling conventions > >> used in all our assembly-language files in our drivers. We make > >> very high-speed number-crunching drivers that munge high-speed > >> data into images. We need to do that in assembly as we have > >> always done. > Just for curiosity... yep, I understand now you have everything written in assembler, but why not consider start writing it in C and stop doing the compiler work (such as pipelining, out of order reordering, loop unrolling for specific processor, and so on...) That's what everyone taught me, nowadays you won't be better than the compiler in anything longer than three lines... -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Sam Ravnborg wrote: > On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: >> >> On Thu, 20 Dec 2007, Sam Ravnborg wrote: >> It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! >>> >>> How did you build the module. It reads like you failed to use >>> kbuild to build your module which is why you did not pass >>> correct options to gcc - correct? >>> >>> If you did not use kbuild - why not? >>> Is there anything missing you need? >>> >>> Sam >>> >> >> I need to get rid of -mregparm=3 on gcc's command line. It >> is completely incompatible with the standard calling conventions >> used in all our assembly-language files in our drivers. We make >> very high-speed number-crunching drivers that munge high-speed >> data into images. We need to do that in assembly as we have >> always done. > That I understand. So you need a CONFIG_ option to switch off > -regparm=3 and pray that the kernel assembly supports it. > > And then I assume you avoided kbuild because it added -regparm=3 > which is why your simple module broke. > > As you are well aware there is not any testing of a kernel without > -regparm=3 these days so you should strongly consider making your > assembly module comply with -regparm=3. > > And no - I dunno how much work that is and what impact it has > on your number chrunching stuff. > But it looks like the only sane long-term solution to me. > > Sam > I may be able to make a file full of "adapters" if I can figure out how to have a procedure that gets called with parameters in registers, with it calling conventional stuff. There used to be a macro, "asmlinkage" that corrected the calling conventions for assembly-language procedures. I will try to see what it did in some older kernels. It got taken out of newer ones. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Roland Dreier wrote:
> > It doesn't seem to be something in .config. Do you know how to
> > reconfigure to get parameter passing put back like it was? Our
> > production applications have lots of assembly-language files
> > and I'm sure we are not going to be able to change all those!
>
> 32-bit x86 uses regparm=3 by default now since commit a1a70c25 ("i386:
> always enable regparm"), which went in about a year ago. To go back
> to the old way, you'll just have to edit arch/x86/Makefile_32 (and
> rebuild your whole kernel from a clean tree, obviously).
Okay. Thanks! I need to do that.
>
> - R.
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: > > On Thu, 20 Dec 2007, Sam Ravnborg wrote: > > >> > >> It never gets to the printk(). You were right about the > >> compilation. Somebody changed the kernel to compile with > >> parameter passing in REGISTERS! This means that EVERYTHING > >> needs to be compiled the same way, 'C' calling conventions > >> were not good enough! > > > > How did you build the module. It reads like you failed to use > > kbuild to build your module which is why you did not pass > > correct options to gcc - correct? > > > > If you did not use kbuild - why not? > > Is there anything missing you need? > > > > Sam > > > > I need to get rid of -mregparm=3 on gcc's command line. It > is completely incompatible with the standard calling conventions > used in all our assembly-language files in our drivers. We make > very high-speed number-crunching drivers that munge high-speed > data into images. We need to do that in assembly as we have > always done. That I understand. So you need a CONFIG_ option to switch off -regparm=3 and pray that the kernel assembly supports it. And then I assume you avoided kbuild because it added -regparm=3 which is why your simple module broke. As you are well aware there is not any testing of a kernel without -regparm=3 these days so you should strongly consider making your assembly module comply with -regparm=3. And no - I dunno how much work that is and what impact it has on your number chrunching stuff. But it looks like the only sane long-term solution to me. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
> It doesn't seem to be something in .config. Do you know how to
> reconfigure to get parameter passing put back like it was? Our
> production applications have lots of assembly-language files
> and I'm sure we are not going to be able to change all those!
32-bit x86 uses regparm=3 by default now since commit a1a70c25 ("i386:
always enable regparm"), which went in about a year ago. To go back
to the old way, you'll just have to edit arch/x86/Makefile_32 (and
rebuild your whole kernel from a clean tree, obviously).
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Lennart Sorensen wrote: > On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote: >> It never gets to the printk(). You were right about the >> compilation. Somebody changed the kernel to compile with >> parameter passing in REGISTERS! This means that EVERYTHING >> needs to be compiled the same way, 'C' calling conventions >> were not good enough! >> >> FYI, it has been previously shown that passing parameters >> in registers on register-starved ix86 machines is always >> a loss, because the registers need to be freed up, either >> by saving them on the stack or as dummy memory variables. >> >> Now, they've done it to the entire kernel! > > It's a config option. I think redhat was the first to actually start > using it on their distributions. Many distributions don't use it. > Debian does not use it on their kernels. > > -- > Len Sorensen > -- It doesn't seem to be something in .config. Do you know how to reconfigure to get parameter passing put back like it was? Our production applications have lots of assembly-language files and I'm sure we are not going to be able to change all those! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Sam Ravnborg wrote: >> >> It never gets to the printk(). You were right about the >> compilation. Somebody changed the kernel to compile with >> parameter passing in REGISTERS! This means that EVERYTHING >> needs to be compiled the same way, 'C' calling conventions >> were not good enough! > > How did you build the module. It reads like you failed to use > kbuild to build your module which is why you did not pass > correct options to gcc - correct? > > If you did not use kbuild - why not? > Is there anything missing you need? > > Sam > I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
> > It never gets to the printk(). You were right about the > compilation. Somebody changed the kernel to compile with > parameter passing in REGISTERS! This means that EVERYTHING > needs to be compiled the same way, 'C' calling conventions > were not good enough! How did you build the module. It reads like you failed to use kbuild to build your module which is why you did not pass correct options to gcc - correct? If you did not use kbuild - why not? Is there anything missing you need? Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote: > It never gets to the printk(). You were right about the > compilation. Somebody changed the kernel to compile with > parameter passing in REGISTERS! This means that EVERYTHING > needs to be compiled the same way, 'C' calling conventions > were not good enough! > > FYI, it has been previously shown that passing parameters > in registers on register-starved ix86 machines is always > a loss, because the registers need to be freed up, either > by saving them on the stack or as dummy memory variables. > > Now, they've done it to the entire kernel! It's a config option. I think redhat was the first to actually start using it on their distributions. Many distributions don't use it. Debian does not use it on their kernels. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Lennart Sorensen wrote:
> On Wed, Dec 19, 2007 at 03:56:45PM -0500, linux-os (Dick Johnson) wrote:
>>
>> On Wed, 19 Dec 2007, Lennart Sorensen wrote:
>>
>>> On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
Here is a so-called BUG when trying to insert the following
module into the kernel (2.6.22.1).
BUG: unable to handle kernel paging request at virtual address 6814ec83
printing eip:
c016d013
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat
dm_mod usbhid ff_memless uhci_hcd ehci_hcd video container button battery
ac rtc ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod
scsi_mod
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010046 (2.6.22.1 #2)
EIP is at kmem_cache_alloc+0x23/0x80
eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
Stack: f8913300 f8913013 f7fff880 00d0
ef27e000
c012b907 c0140279 bffedc07 bffedc08 0807a018
c0102b82 0807a018 18c9 0807a008 bffeabc8
0080
Call Trace:
[] init_module+0x13/0x48 [MemDev]
[] blocking_notifier_call_chain+0x17/0x20
[] sys_init_module+0xd9/0x140
[] sysenter_past_esp+0x5f/0x85
===
Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24
08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 <8b> 02 85 c0
74 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
EIP: [] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
Here is the code that causes the crash.
#include
#include
#include
#include
#include
#include
static const char devname[]="Device";
#define NR_PAGES 0x10
struct DMA {
void *ptr;
unsigned long addr;
size_t len;
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// The top-level object that gets allocated once, when the module is
// installed.
//
struct INFO {
struct file_operations fa; // Kernel connection
struct semaphore dev_sem;
struct DMA dma[NR_PAGES]; // Can map one megabyte
uint32_t vm_start; // Where mmap() starts
uint32_t pages; // Number of pages mapped
atomic_t open; // Number of opens
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
static struct INFO *info;
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Initialize the module and return 0 if everything is okay.
// Return a negative error-code if not.
//
static int32_t startup()
{
if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
printk(KERN_ALERT"%s : Can't allocate memory\n", devname);
>>>
>>> Missing space after KERN_ALERT?
>>
>> I certainly hope that it's not the problem! That would
>> invalidate both the kernel and the compiler!
>
> It was the only thing that looked a bit odd. Although white space
> generally shouldn't matter in C.
>
> Well maybe the module was just compiled against a different source tree
> than the running kernel it was loaded into.
>
> I suppose comment out the printk and see if it's breaking on that line
> or somewhere else. Or just make it a printk with no variables.
>
> --
> Len Sorensen
>
It never gets to the printk(). You were right about the
compilation. Somebody changed the kernel to compile with
parameter passing in REGISTERS! This means that EVERYTHING
needs to be compiled the same way, 'C' calling conventions
were not good enough!
FYI, it has been previously shown that passing parameters
in registers on register-starved ix86 machines is always
a loss, because the registers need to be freed up, either
by saving them on the stack or as dummy memory variables.
Now, they've done it to the entire kernel!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If
Re: Trying to convert old modules to newer kernels
On Wed, Dec 19, 2007 at 03:56:45PM -0500, linux-os (Dick Johnson) wrote:
>
> On Wed, 19 Dec 2007, Lennart Sorensen wrote:
>
> > On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
> >>
> >>
> >> Here is a so-called BUG when trying to insert the following
> >> module into the kernel (2.6.22.1).
> >>
> >>
> >> BUG: unable to handle kernel paging request at virtual address 6814ec83
> >> printing eip:
> >> c016d013
> >> *pde =
> >> Oops: [#1]
> >> PREEMPT SMP
> >> Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
> >> iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat
> >> dm_mod usbhid ff_memless uhci_hcd ehci_hcd video container button battery
> >> ac rtc ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod
> >> scsi_mod
> >> CPU:0
> >> EIP:0060:[]Not tainted VLI
> >> EFLAGS: 00010046 (2.6.22.1 #2)
> >> EIP is at kmem_cache_alloc+0x23/0x80
> >> eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
> >> esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
> >> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
> >> Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
> >> Stack: f8913300 f8913013 f7fff880 00d0
> >> ef27e000
> >> c012b907 c0140279 bffedc07 bffedc08 0807a018
> >>
> >> c0102b82 0807a018 18c9 0807a008 bffeabc8
> >> 0080
> >> Call Trace:
> >> [] init_module+0x13/0x48 [MemDev]
> >> [] blocking_notifier_call_chain+0x17/0x20
> >> [] sys_init_module+0xd9/0x140
> >> [] sysenter_past_esp+0x5f/0x85
> >> ===
> >> Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24
> >> 08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 <8b> 02 85 c0
> >> 74 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
> >> EIP: [] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
> >>
> >>
> >>
> >> Here is the code that causes the crash.
> >>
> >>
> >> #include
> >> #include
> >> #include
> >> #include
> >> #include
> >> #include
> >> static const char devname[]="Device";
> >> #define NR_PAGES 0x10
> >>
> >> struct DMA {
> >> void *ptr;
> >> unsigned long addr;
> >> size_t len;
> >> };
> >> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >> //
> >> // The top-level object that gets allocated once, when the module is
> >> // installed.
> >> //
> >> struct INFO {
> >> struct file_operations fa; // Kernel connection
> >> struct semaphore dev_sem;
> >> struct DMA dma[NR_PAGES]; // Can map one megabyte
> >> uint32_t vm_start; // Where mmap() starts
> >> uint32_t pages; // Number of pages mapped
> >> atomic_t open; // Number of opens
> >> };
> >> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >> static struct INFO *info;
> >> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >> //
> >> // Initialize the module and return 0 if everything is okay.
> >> // Return a negative error-code if not.
> >> //
> >> static int32_t startup()
> >> {
> >> if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
> >> printk(KERN_ALERT"%s : Can't allocate memory\n", devname);
> >
> > Missing space after KERN_ALERT?
>
> I certainly hope that it's not the problem! That would
> invalidate both the kernel and the compiler!
It was the only thing that looked a bit odd. Although white space
generally shouldn't matter in C.
Well maybe the module was just compiled against a different source tree
than the running kernel it was loaded into.
I suppose comment out the printk and see if it's breaking on that line
or somewhere else. Or just make it a printk with no variables.
--
Len Sorensen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Wed, Dec 19, 2007 at 03:56:45PM -0500, linux-os (Dick Johnson) wrote:
On Wed, 19 Dec 2007, Lennart Sorensen wrote:
On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
Here is a so-called BUG when trying to insert the following
module into the kernel (2.6.22.1).
BUG: unable to handle kernel paging request at virtual address 6814ec83
printing eip:
c016d013
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat
dm_mod usbhid ff_memless uhci_hcd ehci_hcd video container button battery
ac rtc ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod
scsi_mod
CPU:0
EIP:0060:[c016d013]Not tainted VLI
EFLAGS: 00010046 (2.6.22.1 #2)
EIP is at kmem_cache_alloc+0x23/0x80
eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
Stack: f8913300 f8913013 f7fff880 00d0
ef27e000
c012b907 c0140279 bffedc07 bffedc08 0807a018
c0102b82 0807a018 18c9 0807a008 bffeabc8
0080
Call Trace:
[f8913013] init_module+0x13/0x48 [MemDev]
[c012b907] blocking_notifier_call_chain+0x17/0x20
[c0140279] sys_init_module+0xd9/0x140
[c0102b82] sysenter_past_esp+0x5f/0x85
===
Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24
08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 8b 02 85 c0
74 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
EIP: [c016d013] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
Here is the code that causes the crash.
#include linux/autoconf.h
#include linux/module.h
#include linux/kernel.h
#include linux/init.h
#include linux/poll.h
#include linux/mm.h
static const char devname[]=Device;
#define NR_PAGES 0x10
struct DMA {
void *ptr;
unsigned long addr;
size_t len;
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// The top-level object that gets allocated once, when the module is
// installed.
//
struct INFO {
struct file_operations fa; // Kernel connection
struct semaphore dev_sem;
struct DMA dma[NR_PAGES]; // Can map one megabyte
uint32_t vm_start; // Where mmap() starts
uint32_t pages; // Number of pages mapped
atomic_t open; // Number of opens
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
static struct INFO *info;
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Initialize the module and return 0 if everything is okay.
// Return a negative error-code if not.
//
static int32_t startup()
{
if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
printk(KERN_ALERT%s : Can't allocate memory\n, devname);
Missing space after KERN_ALERT?
I certainly hope that it's not the problem! That would
invalidate both the kernel and the compiler!
It was the only thing that looked a bit odd. Although white space
generally shouldn't matter in C.
Well maybe the module was just compiled against a different source tree
than the running kernel it was loaded into.
I suppose comment out the printk and see if it's breaking on that line
or somewhere else. Or just make it a printk with no variables.
--
Len Sorensen
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Lennart Sorensen wrote:
On Wed, Dec 19, 2007 at 03:56:45PM -0500, linux-os (Dick Johnson) wrote:
On Wed, 19 Dec 2007, Lennart Sorensen wrote:
On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
Here is a so-called BUG when trying to insert the following
module into the kernel (2.6.22.1).
BUG: unable to handle kernel paging request at virtual address 6814ec83
printing eip:
c016d013
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat
dm_mod usbhid ff_memless uhci_hcd ehci_hcd video container button battery
ac rtc ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod
scsi_mod
CPU:0
EIP:0060:[c016d013]Not tainted VLI
EFLAGS: 00010046 (2.6.22.1 #2)
EIP is at kmem_cache_alloc+0x23/0x80
eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
Stack: f8913300 f8913013 f7fff880 00d0
ef27e000
c012b907 c0140279 bffedc07 bffedc08 0807a018
c0102b82 0807a018 18c9 0807a008 bffeabc8
0080
Call Trace:
[f8913013] init_module+0x13/0x48 [MemDev]
[c012b907] blocking_notifier_call_chain+0x17/0x20
[c0140279] sys_init_module+0xd9/0x140
[c0102b82] sysenter_past_esp+0x5f/0x85
===
Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24
08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 8b 02 85 c0
74 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
EIP: [c016d013] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
Here is the code that causes the crash.
#include linux/autoconf.h
#include linux/module.h
#include linux/kernel.h
#include linux/init.h
#include linux/poll.h
#include linux/mm.h
static const char devname[]=Device;
#define NR_PAGES 0x10
struct DMA {
void *ptr;
unsigned long addr;
size_t len;
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// The top-level object that gets allocated once, when the module is
// installed.
//
struct INFO {
struct file_operations fa; // Kernel connection
struct semaphore dev_sem;
struct DMA dma[NR_PAGES]; // Can map one megabyte
uint32_t vm_start; // Where mmap() starts
uint32_t pages; // Number of pages mapped
atomic_t open; // Number of opens
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
static struct INFO *info;
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Initialize the module and return 0 if everything is okay.
// Return a negative error-code if not.
//
static int32_t startup()
{
if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
printk(KERN_ALERT%s : Can't allocate memory\n, devname);
Missing space after KERN_ALERT?
I certainly hope that it's not the problem! That would
invalidate both the kernel and the compiler!
It was the only thing that looked a bit odd. Although white space
generally shouldn't matter in C.
Well maybe the module was just compiled against a different source tree
than the running kernel it was loaded into.
I suppose comment out the printk and see if it's breaking on that line
or somewhere else. Or just make it a printk with no variables.
--
Len Sorensen
It never gets to the printk(). You were right about the
compilation. Somebody changed the kernel to compile with
parameter passing in REGISTERS! This means that EVERYTHING
needs to be compiled the same way, 'C' calling conventions
were not good enough!
FYI, it has been previously shown that passing parameters
in registers on register-starved ix86 machines is always
a loss, because the registers need to be freed up, either
by saving them on the stack or as dummy memory variables.
Now, they've done it to the entire kernel!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or
Re: Trying to convert old modules to newer kernels
On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! FYI, it has been previously shown that passing parameters in registers on register-starved ix86 machines is always a loss, because the registers need to be freed up, either by saving them on the stack or as dummy memory variables. Now, they've done it to the entire kernel! It's a config option. I think redhat was the first to actually start using it on their distributions. Many distributions don't use it. Debian does not use it on their kernels. -- Len Sorensen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! How did you build the module. It reads like you failed to use kbuild to build your module which is why you did not pass correct options to gcc - correct? If you did not use kbuild - why not? Is there anything missing you need? Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Lennart Sorensen wrote: On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! FYI, it has been previously shown that passing parameters in registers on register-starved ix86 machines is always a loss, because the registers need to be freed up, either by saving them on the stack or as dummy memory variables. Now, they've done it to the entire kernel! It's a config option. I think redhat was the first to actually start using it on their distributions. Many distributions don't use it. Debian does not use it on their kernels. -- Len Sorensen -- It doesn't seem to be something in .config. Do you know how to reconfigure to get parameter passing put back like it was? Our production applications have lots of assembly-language files and I'm sure we are not going to be able to change all those! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Sam Ravnborg wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! How did you build the module. It reads like you failed to use kbuild to build your module which is why you did not pass correct options to gcc - correct? If you did not use kbuild - why not? Is there anything missing you need? Sam I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
It doesn't seem to be something in .config. Do you know how to reconfigure to get parameter passing put back like it was? Our production applications have lots of assembly-language files and I'm sure we are not going to be able to change all those! 32-bit x86 uses regparm=3 by default now since commit a1a70c25 (i386: always enable regparm), which went in about a year ago. To go back to the old way, you'll just have to edit arch/x86/Makefile_32 (and rebuild your whole kernel from a clean tree, obviously). - R. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: On Thu, 20 Dec 2007, Sam Ravnborg wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! How did you build the module. It reads like you failed to use kbuild to build your module which is why you did not pass correct options to gcc - correct? If you did not use kbuild - why not? Is there anything missing you need? Sam I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. That I understand. So you need a CONFIG_ option to switch off -regparm=3 and pray that the kernel assembly supports it. And then I assume you avoided kbuild because it added -regparm=3 which is why your simple module broke. As you are well aware there is not any testing of a kernel without -regparm=3 these days so you should strongly consider making your assembly module comply with -regparm=3. And no - I dunno how much work that is and what impact it has on your number chrunching stuff. But it looks like the only sane long-term solution to me. Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Roland Dreier wrote: It doesn't seem to be something in .config. Do you know how to reconfigure to get parameter passing put back like it was? Our production applications have lots of assembly-language files and I'm sure we are not going to be able to change all those! 32-bit x86 uses regparm=3 by default now since commit a1a70c25 (i386: always enable regparm), which went in about a year ago. To go back to the old way, you'll just have to edit arch/x86/Makefile_32 (and rebuild your whole kernel from a clean tree, obviously). Okay. Thanks! I need to do that. - R. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Sam Ravnborg wrote: On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: On Thu, 20 Dec 2007, Sam Ravnborg wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! How did you build the module. It reads like you failed to use kbuild to build your module which is why you did not pass correct options to gcc - correct? If you did not use kbuild - why not? Is there anything missing you need? Sam I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. That I understand. So you need a CONFIG_ option to switch off -regparm=3 and pray that the kernel assembly supports it. And then I assume you avoided kbuild because it added -regparm=3 which is why your simple module broke. As you are well aware there is not any testing of a kernel without -regparm=3 these days so you should strongly consider making your assembly module comply with -regparm=3. And no - I dunno how much work that is and what impact it has on your number chrunching stuff. But it looks like the only sane long-term solution to me. Sam I may be able to make a file full of adapters if I can figure out how to have a procedure that gets called with parameters in registers, with it calling conventional stuff. There used to be a macro, asmlinkage that corrected the calling conventions for assembly-language procedures. I will try to see what it did in some older kernels. It got taken out of newer ones. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007 18:05:48 -0500, linux-os (Dick Johnson) [EMAIL PROTECTED] wrote: On Thu, 20 Dec 2007, Sam Ravnborg wrote: On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: On Thu, 20 Dec 2007, Sam Ravnborg wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! How did you build the module. It reads like you failed to use kbuild to build your module which is why you did not pass correct options to gcc - correct? If you did not use kbuild - why not? Is there anything missing you need? I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Just for curiosity... yep, I understand now you have everything written in assembler, but why not consider start writing it in C and stop doing the compiler work (such as pipelining, out of order reordering, loop unrolling for specific processor, and so on...) That's what everyone taught me, nowadays you won't be better than the compiler in anything longer than three lines... -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
linux-os (Dick Johnson) [EMAIL PROTECTED] wrote: On Thu, 20 Dec 2007, Sam Ravnborg wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! How did you build the module. It reads like you failed to use kbuild to build your module which is why you did not pass correct options to gcc - correct? If you did not use kbuild - why not? Is there anything missing you need? I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. According to my quick googling, __attribute__((regparm,0)) is what you need. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Dec 19 2007 16:10, linux-os (Dick Johnson) wrote:
>> I anticipate the day removing __init causes a breakage, heh.
>> I mean, if all in-tree modules and LDD3 use it, it can't be wrong, can it?
>>
>>> plus got rid of all the code!
>>> static int32_t startup()
>>
>> I noticed that. Where's your "void" gone? :-)
>
>What void???
>
static __init int startup(void)
{
...
}
Just a stylistic thing, but it has got a clear semantic difference to ().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Wed, 19 Dec 2007, Jan Engelhardt wrote: > > On Dec 19 2007 15:10, linux-os (Dick Johnson) wrote: > > >> I got rid of __init and anything else that I thought could cause the fault, > > I anticipate the day removing __init causes a breakage, heh. > I mean, if all in-tree modules and LDD3 use it, it can't be wrong, can it? > >> plus got rid of all the code! >> static int32_t startup() > > I noticed that. Where's your "void" gone? :-) What void??? Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Wed, 19 Dec 2007, Lennart Sorensen wrote:
> On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
>>
>>
>> Here is a so-called BUG when trying to insert the following
>> module into the kernel (2.6.22.1).
>>
>>
>> BUG: unable to handle kernel paging request at virtual address 6814ec83
>> printing eip:
>> c016d013
>> *pde =
>> Oops: [#1]
>> PREEMPT SMP
>> Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
>> iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod
>> usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc
>> ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
>> CPU:0
>> EIP:0060:[]Not tainted VLI
>> EFLAGS: 00010046 (2.6.22.1 #2)
>> EIP is at kmem_cache_alloc+0x23/0x80
>> eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
>> esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
>> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
>> Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
>> Stack: f8913300 f8913013 f7fff880 00d0
>> ef27e000
>> c012b907 c0140279 bffedc07 bffedc08 0807a018
>>
>> c0102b82 0807a018 18c9 0807a008 bffeabc8
>> 0080
>> Call Trace:
>> [] init_module+0x13/0x48 [MemDev]
>> [] blocking_notifier_call_chain+0x17/0x20
>> [] sys_init_module+0xd9/0x140
>> [] sysenter_past_esp+0x5f/0x85
>> ===
>> Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24
>> 08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 <8b> 02 85 c0 74
>> 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
>> EIP: [] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
>>
>>
>>
>> Here is the code that causes the crash.
>>
>>
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> static const char devname[]="Device";
>> #define NR_PAGES 0x10
>>
>> struct DMA {
>> void *ptr;
>> unsigned long addr;
>> size_t len;
>> };
>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> //
>> // The top-level object that gets allocated once, when the module is
>> // installed.
>> //
>> struct INFO {
>> struct file_operations fa; // Kernel connection
>> struct semaphore dev_sem;
>> struct DMA dma[NR_PAGES]; // Can map one megabyte
>> uint32_t vm_start; // Where mmap() starts
>> uint32_t pages; // Number of pages mapped
>> atomic_t open; // Number of opens
>> };
>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> static struct INFO *info;
>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> //
>> // Initialize the module and return 0 if everything is okay.
>> // Return a negative error-code if not.
>> //
>> static int32_t startup()
>> {
>> if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
>> printk(KERN_ALERT"%s : Can't allocate memory\n", devname);
>
> Missing space after KERN_ALERT?
I certainly hope that it's not the problem! That would
invalidate both the kernel and the compiler!
>
> --
> Len Sorensen
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
>
>
> Here is a so-called BUG when trying to insert the following
> module into the kernel (2.6.22.1).
>
>
> MODULE_ALIAS("MemDev");
> module_init(startup);
> module_exit(quit);
Just a wild guess. Your init and exit functions uses some generic names.
Have you tried renaming them to usual style like:
memdev_init
memdev_exit
So you have no clashes with existing global symbols.
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Dec 19 2007 15:10, linux-os (Dick Johnson) wrote: >I got rid of __init and anything else that I thought could cause the fault, I anticipate the day removing __init causes a breakage, heh. I mean, if all in-tree modules and LDD3 use it, it can't be wrong, can it? >plus got rid of all the code! >static int32_t startup() I noticed that. Where's your "void" gone? :-) And usually, the init routine returns int, not int32_t, even if it's the same in current development models. (I don't think you run an ILP64-compiled kernel.) #include is also not advised. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
>
>
> Here is a so-called BUG when trying to insert the following
> module into the kernel (2.6.22.1).
>
>
> BUG: unable to handle kernel paging request at virtual address 6814ec83
> printing eip:
> c016d013
> *pde =
> Oops: [#1]
> PREEMPT SMP
> Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
> iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod
> usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc
> ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010046 (2.6.22.1 #2)
> EIP is at kmem_cache_alloc+0x23/0x80
> eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
> esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
> Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
> Stack: f8913300 f8913013 f7fff880 00d0 ef27e000
> c012b907 c0140279 bffedc07 bffedc08 0807a018
>
> c0102b82 0807a018 18c9 0807a008 bffeabc8
> 0080
> Call Trace:
> [] init_module+0x13/0x48 [MemDev]
> [] blocking_notifier_call_chain+0x17/0x20
> [] sys_init_module+0xd9/0x140
> [] sysenter_past_esp+0x5f/0x85
> ===
> Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24 08
> 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 <8b> 02 85 c0 74 25
> c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
> EIP: [] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
>
>
>
> Here is the code that causes the crash.
>
>
> #include
> #include
> #include
> #include
> #include
> #include
> static const char devname[]="Device";
> #define NR_PAGES 0x10
>
> struct DMA {
> void *ptr;
> unsigned long addr;
> size_t len;
> };
> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> //
> // The top-level object that gets allocated once, when the module is
> // installed.
> //
> struct INFO {
> struct file_operations fa; // Kernel connection
> struct semaphore dev_sem;
> struct DMA dma[NR_PAGES]; // Can map one megabyte
> uint32_t vm_start; // Where mmap() starts
> uint32_t pages; // Number of pages mapped
> atomic_t open; // Number of opens
> };
> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> static struct INFO *info;
> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> //
> // Initialize the module and return 0 if everything is okay.
> // Return a negative error-code if not.
> //
> static int32_t startup()
> {
> if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
> printk(KERN_ALERT"%s : Can't allocate memory\n", devname);
Missing space after KERN_ALERT?
> return -ENOMEM;
> }
> return 0;
> }
> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> //
> // Cleanup the module in preparation for removal.
> //
> static void quit() {
> kfree(info);
> printk(KERN_INFO"%s : Module removed\n", devname);
> }
> MODULE_LICENSE("GPL");
> MODULE_ALIAS("MemDev");
> module_init(startup);
> module_exit(quit);
> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> Anybody have a clue why this should error out? Am I using
> some reserved names??? I got rid of __init and anything
> else that I thought could cause the fault, plus got rid
> of all the code!
--
Len Sorensen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
Here is a so-called BUG when trying to insert the following
module into the kernel (2.6.22.1).
BUG: unable to handle kernel paging request at virtual address 6814ec83
printing eip:
c016d013
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod
usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc
ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
CPU:0
EIP:0060:[c016d013]Not tainted VLI
EFLAGS: 00010046 (2.6.22.1 #2)
EIP is at kmem_cache_alloc+0x23/0x80
eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
Stack: f8913300 f8913013 f7fff880 00d0 ef27e000
c012b907 c0140279 bffedc07 bffedc08 0807a018
c0102b82 0807a018 18c9 0807a008 bffeabc8
0080
Call Trace:
[f8913013] init_module+0x13/0x48 [MemDev]
[c012b907] blocking_notifier_call_chain+0x17/0x20
[c0140279] sys_init_module+0xd9/0x140
[c0102b82] sysenter_past_esp+0x5f/0x85
===
Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24 08
89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 8b 02 85 c0 74 25
c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
EIP: [c016d013] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
Here is the code that causes the crash.
#include linux/autoconf.h
#include linux/module.h
#include linux/kernel.h
#include linux/init.h
#include linux/poll.h
#include linux/mm.h
static const char devname[]=Device;
#define NR_PAGES 0x10
struct DMA {
void *ptr;
unsigned long addr;
size_t len;
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// The top-level object that gets allocated once, when the module is
// installed.
//
struct INFO {
struct file_operations fa; // Kernel connection
struct semaphore dev_sem;
struct DMA dma[NR_PAGES]; // Can map one megabyte
uint32_t vm_start; // Where mmap() starts
uint32_t pages; // Number of pages mapped
atomic_t open; // Number of opens
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
static struct INFO *info;
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Initialize the module and return 0 if everything is okay.
// Return a negative error-code if not.
//
static int32_t startup()
{
if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
printk(KERN_ALERT%s : Can't allocate memory\n, devname);
Missing space after KERN_ALERT?
return -ENOMEM;
}
return 0;
}
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Cleanup the module in preparation for removal.
//
static void quit() {
kfree(info);
printk(KERN_INFO%s : Module removed\n, devname);
}
MODULE_LICENSE(GPL);
MODULE_ALIAS(MemDev);
module_init(startup);
module_exit(quit);
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Anybody have a clue why this should error out? Am I using
some reserved names??? I got rid of __init and anything
else that I thought could cause the fault, plus got rid
of all the code!
--
Len Sorensen
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Dec 19 2007 15:10, linux-os (Dick Johnson) wrote: I got rid of __init and anything else that I thought could cause the fault, I anticipate the day removing __init causes a breakage, heh. I mean, if all in-tree modules and LDD3 use it, it can't be wrong, can it? plus got rid of all the code! static int32_t startup() I noticed that. Where's your void gone? :-) And usually, the init routine returns int, not int32_t, even if it's the same in current development models. (I don't think you run an ILP64-compiled kernel.) #include linux/autoconf.h is also not advised. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote: Here is a so-called BUG when trying to insert the following module into the kernel (2.6.22.1). MODULE_ALIAS(MemDev); module_init(startup); module_exit(quit); Just a wild guess. Your init and exit functions uses some generic names. Have you tried renaming them to usual style like: memdev_init memdev_exit So you have no clashes with existing global symbols. Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Wed, 19 Dec 2007, Lennart Sorensen wrote:
On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
Here is a so-called BUG when trying to insert the following
module into the kernel (2.6.22.1).
BUG: unable to handle kernel paging request at virtual address 6814ec83
printing eip:
c016d013
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod
usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc
ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
CPU:0
EIP:0060:[c016d013]Not tainted VLI
EFLAGS: 00010046 (2.6.22.1 #2)
EIP is at kmem_cache_alloc+0x23/0x80
eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
Stack: f8913300 f8913013 f7fff880 00d0
ef27e000
c012b907 c0140279 bffedc07 bffedc08 0807a018
c0102b82 0807a018 18c9 0807a008 bffeabc8
0080
Call Trace:
[f8913013] init_module+0x13/0x48 [MemDev]
[c012b907] blocking_notifier_call_chain+0x17/0x20
[c0140279] sys_init_module+0xd9/0x140
[c0102b82] sysenter_past_esp+0x5f/0x85
===
Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24
08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 8b 02 85 c0 74
25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
EIP: [c016d013] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
Here is the code that causes the crash.
#include linux/autoconf.h
#include linux/module.h
#include linux/kernel.h
#include linux/init.h
#include linux/poll.h
#include linux/mm.h
static const char devname[]=Device;
#define NR_PAGES 0x10
struct DMA {
void *ptr;
unsigned long addr;
size_t len;
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// The top-level object that gets allocated once, when the module is
// installed.
//
struct INFO {
struct file_operations fa; // Kernel connection
struct semaphore dev_sem;
struct DMA dma[NR_PAGES]; // Can map one megabyte
uint32_t vm_start; // Where mmap() starts
uint32_t pages; // Number of pages mapped
atomic_t open; // Number of opens
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
static struct INFO *info;
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Initialize the module and return 0 if everything is okay.
// Return a negative error-code if not.
//
static int32_t startup()
{
if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
printk(KERN_ALERT%s : Can't allocate memory\n, devname);
Missing space after KERN_ALERT?
I certainly hope that it's not the problem! That would
invalidate both the kernel and the compiler!
--
Len Sorensen
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Wed, 19 Dec 2007, Jan Engelhardt wrote: On Dec 19 2007 15:10, linux-os (Dick Johnson) wrote: I got rid of __init and anything else that I thought could cause the fault, I anticipate the day removing __init causes a breakage, heh. I mean, if all in-tree modules and LDD3 use it, it can't be wrong, can it? plus got rid of all the code! static int32_t startup() I noticed that. Where's your void gone? :-) What void??? Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Dec 19 2007 16:10, linux-os (Dick Johnson) wrote:
I anticipate the day removing __init causes a breakage, heh.
I mean, if all in-tree modules and LDD3 use it, it can't be wrong, can it?
plus got rid of all the code!
static int32_t startup()
I noticed that. Where's your void gone? :-)
What void???
static __init int startup(void)
{
...
}
Just a stylistic thing, but it has got a clear semantic difference to ().
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
