Re: Input layer demand loading

Re: Input layer demand loading

[Andrey Borzenkov]

>> True, but then if you try to open the port, you will only get the base
>> joydev.o module loaded, not the gameport driver, which is what you
>> _really_ want to have loaded, right?
>> 
>> So there really isn't much benifit to doing this, sorry.
>
> Why? It could work the way PCMCIA SCSI works.
> Cardmgr loads the LLDD, but sd, sg, etc. are loaded
> on demand.

how? SCSI (or USB, PCI, EISA etc) have driver-independent means to identify 
device or at least device class.

But how are you going you going to know you need to load specific mouse driver 
(logitech not microsoft) or specific joystick flavour? All that you possibly 
know that you have _some_ mouse or _some_ joystick ...

-andrey

Re: Input layer demand loading

[Oliver Neukum]

Am Mittwoch, 16. Juli 2003 20:19 schrieb Andrey Borzenkov:
> >> True, but then if you try to open the port, you will only get the base
> >> joydev.o module loaded, not the gameport driver, which is what you
> >> _really_ want to have loaded, right?
> >> 
> >> So there really isn't much benifit to doing this, sorry.
> >
> > Why? It could work the way PCMCIA SCSI works.
> > Cardmgr loads the LLDD, but sd, sg, etc. are loaded
> > on demand.
> 
> how? SCSI (or USB, PCI, EISA etc) have driver-independent means to identify 
> device or at least device class.
> 
> But how are you going you going to know you need to load specific mouse driver 
> (logitech not microsoft) or specific joystick flavour? All that you possibly 
> know that you have _some_ mouse or _some_ joystick ...

Exactly, you'd only load the hardware independent part on demand.
Or, alternatively, you'd record the driver to load in the hotplug script
and load it on demand.

	Regards
		Oliver

Re: Input layer demand loading

[Mike Fedyk]

On Wed, Jul 16, 2003 at 10:19:17PM +0400, Andrey Borzenkov wrote:
> >> True, but then if you try to open the port, you will only get the base
> >> joydev.o module loaded, not the gameport driver, which is what you
> >> _really_ want to have loaded, right?
> >> 
> >> So there really isn't much benifit to doing this, sorry.
> >
> > Why? It could work the way PCMCIA SCSI works.
> > Cardmgr loads the LLDD, but sd, sg, etc. are loaded
> > on demand.
> 
> how? SCSI (or USB, PCI, EISA etc) have driver-independent means to identify 
> device or at least device class.
> 
> But how are you going you going to know you need to load specific mouse driver 
> (logitech not microsoft) or specific joystick flavour? All that you possibly 
> know that you have _some_ mouse or _some_ joystick ...

Isn't that why we have hotplug in userspace?

That way, we know we have a mouse, but it's up to userspace to find out
what kind.

Re: Re[2]: Input layer demand loading

[Mike Fedyk]

On Thu, Jul 17, 2003 at 09:14:49AM +0400, "Andrey Borzenkov"  wrote:
> 
> 
> -----Original Message-----
> 
> > 
> > On Wed, Jul 16, 2003 at 10:19:17PM +0400, Andrey Borzenkov wrote:
> > > >> True, but then if you try to open the port, you will only get the base
> > > >> joydev.o module loaded, not the gameport driver, which is what you
> > > >> _really_ want to have loaded, right?
> > > >> 
> > > >> So there really isn't much benifit to doing this, sorry.
> > > >
> > > > Why? It could work the way PCMCIA SCSI works.
> > > > Cardmgr loads the LLDD, but sd, sg, etc. are loaded
> > > > on demand.
> > > 
> > > how? SCSI (or USB, PCI, EISA etc) have driver-independent means to identify 
> > > device or at least device class.
> > > 
> > > But how are you going you going to know you need to load specific mouse driver 
> > > (logitech not microsoft) or specific joystick flavour? All that you possibly 
> > > know that you have _some_ mouse or _some_ joystick ...
> > 
> > Isn't that why we have hotplug in userspace?
> > 
> > That way, we know we have a mouse, but it's up to userspace to find out
> > what kind.
> > 
> 
> that is not what hotplug is for. What you describe is called "probing". 
> 
> Hotplug is there to load hardware driver once hardware is known, not
> to probe what hardware is there.
> 
> It can be used this way but it is rather abuse (or misuse) I'd say.

In many cases, you only know you have a class of devices, and you need more
probing after the initial hardware notification (hotplug).

There are many people that want all probing to be in user space.  Let's face
it, it's easier (no need to reboot) to upgrade a userspace probing app than
to install a new kernel.

Unfortunatly, it doesn't look like that will happen for 2.6, but I'd bet it
will in 2.7, and hotplug will probably be a considerable player in that area
(unless something better is used instead).