warnings from drivers/tty/ehv_bytechan.c

[Resent with Greg's correct new address]

Hi Timur,

If you build drivers/tty/ehv_bytechan.c as a module, it produces these warmings:

drivers/tty/ehv_bytechan.c:362:1: warning: data definition has no type or storage class
drivers/tty/ehv_bytechan.c:362:1: warning: type defaults to 'int' in declaration of 'console_initcall'
drivers/tty/ehv_bytechan.c:362:1: warning: parameter names (without types) in function declaration
drivers/tty/ehv_bytechan.c:334:19: warning: 'ehv_bc_console_init' defined but not used

console_initcall() is not defined for modules.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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=20
makes sense for the driver to support modules at all.  I have this in the=20
driver:

#include <linux/module.h>
...
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=20
it as a module.

The problem stems from the fact that it's a console driver *and* a tty=20
driver.  It makes sense that a tty driver can be compiled as a module, but=
=20
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

--=20
Timur Tabi
Linux kernel developer at Freescale=

On Mon, Feb 20, 2012 at 01:24:22PM +0000, Tabi Timur-B04825 wrote:

Stephen Rothwell wrote:

quoted

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 <linux/module.h>
...
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

gregkh@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

On Fri, Feb 24, 2012 at 04:00:12PM -0600, Timur Tabi wrote:

gregkh@linuxfoundation.org wrote:

quoted

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

gregkh@linuxfoundation.org wrote:

quoted

quoted

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 :)

quoted

quoted

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 <linux/module.h>
	
-- 
Timur Tabi
Linux kernel developer at Freescale

On Fri, Feb 24, 2012 at 04:15:04PM -0600, Timur Tabi wrote:

gregkh@linuxfoundation.org wrote:

quoted

quoted

quoted

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?

quoted

Depends on the hardware it supports :)

quoted

quoted

In this case, the console support for byte channels would not be
available.

quoted

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 <linux/module.h>

No, no need to, leave it as-is if it builds properly.

greg k-h

On 02/24/2012 04:15 PM, Timur Tabi wrote:

gregkh@linuxfoundation.org wrote:

quoted

quoted

quoted

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?

quoted

Depends on the hardware it supports :)

quoted

quoted

In this case, the console support for byte channels would not be
available.

quoted

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