definition of terms (was: Re: Adding PCMCIA support to the kernel tree -- developers needed.)
Quoted 10 lines
Quoted 1 line
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/NNNis 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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 15 lines · Oliver Neukum
Quoted 10 lines
Quoted 1 line
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/NNNis 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.
Quoted 7 lines
'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.oI 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.
Signature · 7 lines
Vojtech Pavlik SuSE Labs _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · 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.
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.
Quoted 4 lines
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.
Quoted 2 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel