definition of terms (was: Re: Adding PCMCIA support to the kernel tree -- developers needed.)

definition of terms (was: Re: Adding PCMCIA support to the kernel tree -- developers needed.)

[Oliver Neukum]

> > I fear we are being sucked down by semantics.
>
> You can't get away from that in design discussions.  Gotta
> eliminate confusions up front.
>
> And this application structure is very important.  You can't
> design a "system" without knowing the ways people interact
> with it ... /dev/NNN is no more than one part of a 1970s
> solution to a simpler system problem than we have today.
> We can still use it, but it's not a straightjacket to live in.

OK. Let me list all terms used up to now and give a preliminary definition.


'physical device' - hardware, in this context usually hotpluggable

'hotplug event' - any event relating to a hotpluggable device which the 
kernel may report to user space

'user space agent' - task the kernel spawns in reaction to a hotplug event

'interface driver' - a kernel space driver that user space can use to talk to 
a physical devices. There may be more than one interface driver per physical 
device, or in rare cases, none.

'logical driver' - interface the user space agent may set up, which allows 
the rest of user space to use the services a physical device offers, optional

'device name'  - a name userspace uses to identify the interface driver

'stable name' - a device name that depends on a unique characteristic of a 
device or on the way a device is connected to a bus

'physical location' - a description of how a device is connected to a bus.
at one time a connected physical device has one physical location and there 
is a maximum of one device to a physical location

Now to an example:

physical device: a USB scanner

hotplug event: scanner is plugged in + possibly others (to be decided)

user space agent: /sbin/hotplug + scripts called by it

interface driver: usbscanner.o

logical driver: epson backend of SANE

I introduced the term 'interface driver' because it is needed.

	HTH
		Oliver

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: definition of terms (was: Re: Adding PCMCIA support to the kernel tree -- developers needed.)

[David Hinds]

I think this discussion is trying to create a very difficult problem
out of something that really is not that hard to handle in practice.

Say you insert one hot plug device then in the next microsecond swap
it out and swap in another device of the same type but that you want
to configure differently.  Is this really a scenario that deserves
serious discussion?  I would simply require serialization of hot plug
agent actions and then it seems to me that 90% of the theoretical
problem (and 99.999% of the real problem) goes away.  If you try to
redesign the entire Linux device model to handle a hot plug corner
case, you're wasting your time because your changes will never be
accepted; DevFS is a minor change in comparison.

PCMCIA does handle these issues and the solution (serializing device
configuration actions, and configuring devices based on physical
location and/or device properties rather than device names) works.

-- Dave


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: definition of terms (was: Re: Adding PCMCIA support to the kernel tree -- developers needed.)

[Vojtech Pavlik]

On Fri, Feb 09, 2001 at 06:03:30PM +0100, Oliver Neukum wrote:

> > > I fear we are being sucked down by semantics.
> >
> > You can't get away from that in design discussions.  Gotta
> > eliminate confusions up front.
> >
> > And this application structure is very important.  You can't
> > design a "system" without knowing the ways people interact
> > with it ... /dev/NNN is no more than one part of a 1970s
> > solution to a simpler system problem than we have today.
> > We can still use it, but it's not a straightjacket to live in.

> 'interface driver' - a kernel space driver that user space can use to talk to 
> a physical devices. There may be more than one interface driver per physical 
> device, or in rare cases, none.
> 
> 'logical driver' - interface the user space agent may set up, which allows 
> the rest of user space to use the services a physical device offers, optional

> logical driver: epson backend of SANE
> interface driver: usbscanner.o

> I introduced the term 'interface driver' because it is needed.

But it's a very problematic one - there is nothing like a driver that
connects directly hardware and userspace. There is always several
drivers inbetween.

In the case of USB scanner:

[hw]--(pci)-->usb-ohci.c--(usb)-->scanner.c--(chardevice)-->[userland]

In many cases there is much more. If there were only direct

[hw]-->xxx.c-->[userland]

drivers, we wouldn't need any hotplug support - kmod and friends would
be enough, because we would then be able to load the modules based on
userland requests. And that is not the case. For USB scanner working, we
need both usb-ohci.c and scanner.c loaded.

So, if you define 'interface driver' as the last driver instance before
a layer (chardevice, netdevice, blockdevice) that interfaces to
userland, then OK. But we need to take the other drivers into our view
as well.

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: definition of terms (was: Re: Adding PCMCIA support to the kernel tree -- developers needed.)

[Oliver Neukum]

On Freitag,  9. Februar 2001 18:30, David Hinds wrote:
> I think this discussion is trying to create a very difficult problem
> out of something that really is not that hard to handle in practice.

Certainly if there is a need for locking, a simple common lock would solve it.
But it seems that we cannot agree whether locking is needed at all.

> Say you insert one hot plug device then in the next microsecond swap
> it out and swap in another device of the same type but that you want
> to configure differently.  Is this really a scenario that deserves
> serious discussion?  I would simply require serialization of hot plug

If you use physical removal as an example probably not.
If you take into account that there are hotpluggable busses with
many hosts any of which can reset the bus, it deserves consideration.

Think of joining two segments of such a bus resulting in some error
causing some host to reset the bus.

> agent actions and then it seems to me that 90% of the theoretical
> problem (and 99.999% of the real problem) goes away.  If you try to

This I would consider a simple and robust solution.

	Regards
		Oliver

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel