Re: warnings from drivers/tty/ehv_bytechan.c
Stephen Rothwell wrote: > console_initcall() is not defined for modules. Hmmm... the patch you posted is a good short-term fix, but I wonder if makes sense for the driver to support modules at all. I have this in the driver: #include ... module_init(ehv_bc_init); module_exit(ehv_bc_exit); although to be honest, I can't remember the last time I tried to compile it as a module. The problem stems from the fact that it's a console driver *and* a tty driver. It makes sense that a tty driver can be compiled as a module, but not a console driver. So Greg, can I do something like this: #ifdef MODULE module_initcall(ehv_bc_console_init) #else console_initcall(ehv_bc_console_init); #endif -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: warnings from drivers/tty/ehv_bytechan.c
On Mon, Feb 20, 2012 at 01:24:22PM +, Tabi Timur-B04825 wrote: > Stephen Rothwell wrote: > > console_initcall() is not defined for modules. > > Hmmm... the patch you posted is a good short-term fix, but I wonder if > makes sense for the driver to support modules at all. I have this in the > driver: > > #include > ... > module_init(ehv_bc_init); > module_exit(ehv_bc_exit); > > although to be honest, I can't remember the last time I tried to compile > it as a module. > > The problem stems from the fact that it's a console driver *and* a tty > driver. It makes sense that a tty driver can be compiled as a module, but > not a console driver. > > So Greg, can I do something like this: > > #ifdef MODULE > module_initcall(ehv_bc_console_init) > #else > console_initcall(ehv_bc_console_init); > #endif Sure, something like that is fine, but if the code really can't be a module, why not just fix the Kconfig file to enforce this properly instead? thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: warnings from drivers/tty/ehv_bytechan.c
gre...@linuxfoundation.org wrote: > Sure, something like that is fine, but if the code really can't be a > module, why not just fix the Kconfig file to enforce this properly > instead? That's the simplest approach, for use. The TTY portion of the driver can be used as a module. Is there any real value in loading a TTY driver as a module? In this case, the console support for byte channels would not be available. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: warnings from drivers/tty/ehv_bytechan.c
On Fri, Feb 24, 2012 at 04:00:12PM -0600, Timur Tabi wrote: > gre...@linuxfoundation.org wrote: > > Sure, something like that is fine, but if the code really can't be a > > module, why not just fix the Kconfig file to enforce this properly > > instead? > > That's the simplest approach, for use. The TTY portion of the driver can > be used as a module. Is there any real value in loading a TTY driver as a > module? Depends on the hardware it supports :) > In this case, the console support for byte channels would not be > available. Then it doesn't make sense, right? thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: warnings from drivers/tty/ehv_bytechan.c
gre...@linuxfoundation.org wrote: >> > That's the simplest approach, for use. The TTY portion of the driver can >> > be used as a module. Is there any real value in loading a TTY driver as a >> > module? > Depends on the hardware it supports :) > >> > In this case, the console support for byte channels would not be >> > available. > Then it doesn't make sense, right? I guess that's my question. Is there a real use case for having console output go to the serial port, and TTY go to a byte channel? Even if you wanted to do that, I supposed you don't need to load the byte channel driver as a module to get that behavior. Anyway, that's all academic. A more important question is: now that the driver can't be compiled as a module, should I change module_init() to something else (like device_initcall)? Should I remove this line? #include -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: warnings from drivers/tty/ehv_bytechan.c
On Fri, Feb 24, 2012 at 04:15:04PM -0600, Timur Tabi wrote: > gre...@linuxfoundation.org wrote: > >> > That's the simplest approach, for use. The TTY portion of the driver can > >> > be used as a module. Is there any real value in loading a TTY driver as > >> > a > >> > module? > > > Depends on the hardware it supports :) > > > >> > In this case, the console support for byte channels would not be > >> > available. > > > Then it doesn't make sense, right? > > I guess that's my question. Is there a real use case for having console > output go to the serial port, and TTY go to a byte channel? Even if you > wanted to do that, I supposed you don't need to load the byte channel > driver as a module to get that behavior. > > Anyway, that's all academic. A more important question is: now that the > driver can't be compiled as a module, should I change module_init() to > something else (like device_initcall)? > > Should I remove this line? > > #include No, no need to, leave it as-is if it builds properly. greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: warnings from drivers/tty/ehv_bytechan.c
On 02/24/2012 04:15 PM, Timur Tabi wrote: > gre...@linuxfoundation.org wrote: That's the simplest approach, for use. The TTY portion of the driver can be used as a module. Is there any real value in loading a TTY driver as a module? > >> Depends on the hardware it supports :) >> In this case, the console support for byte channels would not be available. > >> Then it doesn't make sense, right? > > I guess that's my question. Is there a real use case for having console > output go to the serial port, and TTY go to a byte channel? Sure -- you could be using the byte channel for inter-partition communication, or just not have enough serial ports for all of this partition's needs. It looks like the usual pattern is to have a separate kconfig for the console part, and have that be a bool that depends on the tristate tty driver being "y". > Even if you > wanted to do that, I supposed you don't need to load the byte channel > driver as a module to get that behavior. Right, though that could be said about all (most?) modules. Probably not that important in this particular case, though. I can see people wanting to use byte channel but not caring about console, and I can see people wanting to build a generic kernel that supports byte channels, but I don't think there's much overlap between the two. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
