warnings from drivers/tty/ehv_bytechan.c

warnings from drivers/tty/ehv_bytechan.c

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

[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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: warnings from drivers/tty/ehv_bytechan.c

[Tabi Timur-B04825]

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=

Re: warnings from drivers/tty/ehv_bytechan.c

[gregkh]

On Mon, Feb 20, 2012 at 01:24:22PM +0000, 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 <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

Re: warnings from drivers/tty/ehv_bytechan.c

[Timur Tabi]

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

Re: warnings from drivers/tty/ehv_bytechan.c

[gregkh]

On Fri, Feb 24, 2012 at 04:00:12PM -0600, Timur Tabi wrote:
> 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?

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

Re: warnings from drivers/tty/ehv_bytechan.c

[Timur Tabi]

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

Re: warnings from drivers/tty/ehv_bytechan.c

[gregkh]

On Fri, Feb 24, 2012 at 04:15:04PM -0600, Timur Tabi wrote:
> gregkh@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 <linux/module.h>

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

greg k-h

Re: warnings from drivers/tty/ehv_bytechan.c

[Scott Wood]

On 02/24/2012 04:15 PM, Timur Tabi wrote:
> gregkh@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

warnings from drivers/tty/ehv_bytechan.c

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]