driver initialisation order problem

driver initialisation order problem

[Tim Waugh]

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

drivers/char depends on drivers/parport (lp requires parport)
drivers/parport depends on drivers/char (parport_serial requires serial)

How should this dependency be expressed?  The link order of
drivers/char and drivers/parport isn't enough.

Tim.
*/

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

Re: driver initialisation order problem

[Jeff Garzik]

Tim Waugh wrote:
> 
> drivers/char depends on drivers/parport (lp requires parport)
> drivers/parport depends on drivers/char (parport_serial requires serial)
> 
> How should this dependency be expressed?  The link order of
> drivers/char and drivers/parport isn't enough.

I would move lp to parport, since IMHO it belongs there anyway.

-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno

Re: driver initialisation order problem

[Tim Waugh]

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

On Thu, Nov 01, 2001 at 09:21:57AM -0500, Jeff Garzik wrote:

> I would move lp to parport, since IMHO it belongs there anyway.

It isn't confined to just lp:

$ grep -l parport $(find drivers/char -name '*.c')
drivers/char/lp.c
drivers/char/ppdev.c
drivers/char/joystick/turbografx.c
drivers/char/joystick/db9.c
drivers/char/joystick/gamecon.c

Tim.
*/

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

Re: driver initialisation order problem

[Jeff Garzik]

Tim Waugh wrote:
> 
> On Thu, Nov 01, 2001 at 09:21:57AM -0500, Jeff Garzik wrote:
> 
> > I would move lp to parport, since IMHO it belongs there anyway.
> 
> It isn't confined to just lp:
> 
> $ grep -l parport $(find drivers/char -name '*.c')
> drivers/char/lp.c
> drivers/char/ppdev.c

I would move both of these to parport


> drivers/char/joystick/turbografx.c
> drivers/char/joystick/db9.c
> drivers/char/joystick/gamecon.c

don't have a good answer.  maybe move 'em to drivers/input :)

-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno

Re: driver initialisation order problem

[James Simmons]

> > drivers/char/joystick/turbografx.c
> > drivers/char/joystick/db9.c
> > drivers/char/joystick/gamecon.c
> 
> don't have a good answer.  maybe move 'em to drivers/input :)

I suggested that before. Linus didn't like that. Actually in time you will
see all input devices moved to drivers/input. It will become more and
more a mess if we don't. I have various devices such as touchscreens,
keyboard, joysticks etc that are serial devices. It is such a nasty hack
at present to reach into char/joytsick to get something like a touchscreen
working. IMO we should have things in the following order:

/drivers/serial 	-> Yes I plan a rewrite of the serial layer.
/drivers/parport
/drivers/usb

/driver/input		
/driver/char		-> The future console system will be inptu api
			   based so input needs to be first.		


Things like hardware protocols, USB, RS232 should come first. Then char
devices like input and things in char come next.

Re: driver initialisation order problem

[Russell King]

On Thu, Nov 01, 2001 at 10:33:22AM -0800, James Simmons wrote:
> /drivers/serial 	-> Yes I plan a rewrite of the serial layer.

Correction - I plan a major cleanup of the serial layer.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: driver initialisation order problem

[James Simmons]

> On Thu, Nov 01, 2001 at 10:33:22AM -0800, James Simmons wrote:
> > /drivers/serial 	-> Yes I plan a rewrite of the serial layer.
> 
> Correction - I plan a major cleanup of the serial layer.

Better yet we both need important changes to the serial layer. 

Re: driver initialisation order problem

[Russell King]

On Thu, Nov 01, 2001 at 01:25:06PM -0800, James Simmons wrote:
> Better yet we both need important changes to the serial layer. 

My priority as far as serial stuff goes is to keep what we now have
stable so that the people who _need_ to use it (those in the ARM world)
have a chance of stability.

This doesn mean that the input stuff as far as the serial side is
concerned, and the other changes to integrate some parts of the
serial layer into the tty layer as suggested by Ted will have to
hold off for a while as the current implementation matures and
stabilises.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html