I have had a chance to make a pass over the device model documentation.
I've removed most gross inaccuracies, though there may still be a few
glowing warts. You can get at them at
http://kernel.org/pub/linux/kernel/people/mochel/doc/
The OLS paper and presentation (in Open Office format) are also there.
Everyone is encouraged to have a look. Feel free to send me comments,
corrections, or patches.
Additionally, I've also exported my BK tree, which can be found at
bk://ldm.bkbits.net/linux-2.5/
Currently, the only thing committed so far is the above mentioned
documentation and the fixing of the existing documentation.
-pat
Patrick Mochel wrote:
> Everyone is encouraged to have a look. Feel free to send me comments,
> corrections, or patches.
In binding.txt, you write:
> Upon the successful completion of probe, the device is registered with
> the class to which it belongs. Device drivers belong to one and only
> class, and that is set in the driver's devclass field.
I have two drivers (drivers/s390/char/tape.c and drivers/s390/net/ctcmain.c)
that might have problems with this. S390 tapes are available through two
interfaces, a character device implementing the standard tape interface
and a block device that allows you to mount a filesystem written to a tape
(unlike most tape drives, they allow random access reads).
CTC (channel to channel) is a point-to-point connection between two machines
and can be used either as a tty device or as a network device.
Do you have any idea how I can map this to correct driver classes?
Arnd <><
On Wed, 3 Jul 2002, Arnd Bergmann wrote:
> Patrick Mochel wrote:
>
> > Everyone is encouraged to have a look. Feel free to send me comments,
> > corrections, or patches.
>
> In binding.txt, you write:
> > Upon the successful completion of probe, the device is registered with
> > the class to which it belongs. Device drivers belong to one and only
> > class, and that is set in the driver's devclass field.
>
> I have two drivers (drivers/s390/char/tape.c and drivers/s390/net/ctcmain.c)
> that might have problems with this. S390 tapes are available through two
> interfaces, a character device implementing the standard tape interface
> and a block device that allows you to mount a filesystem written to a tape
> (unlike most tape drives, they allow random access reads).
There are actually several types of devices that have several interfaces.
In fact, I wouldn't be suprised if the majority of devices were like this.
Like a SCSI disk - you have a SCSI generic interface, a disk interface,
and possibly a raw interface.
All input devices have at least two interfaces: the general event
interface and the device specific interface (e.g. keyboard, mouse, etc).
A device is really of only one type, though. A disk is a disk, regardless
of how you access it. It's the device type that device classes are
representative of, so I maintain the assertion in the document holds true.
However, in any class, there may be multiple interfaces available for a
particular device. It's these interfaces that userspace sees. A driver may
implement some or all of those interfaces, and they may or may not be
present based on the configuration of the kernel.
I never considered distinguishing between classes and interfaces until
just before OLS, and there I realized it was absolutely necessary. The
interfaces userspace sees are device nodes, and it's the interfaces in the
kernel that are tied to major number allocation, rather than the class
itself (which I had thought).
The device model doesn't provide for multiple interfaces...yet. It's
really not that difficult of a problem; it's more a matter of taste in how
to declare and reference them (which has a lot of bearing on the success
of the solution).
-pat
On Wednesday 03 July 2002 18:46, Patrick Mochel wrote:
> However, in any class, there may be multiple interfaces available for a
> particular device. It's these interfaces that userspace sees. A driver may
> implement some or all of those interfaces, and they may or may not be
> present based on the configuration of the kernel.
Ah, that's the missing bit, at least the tape driver is no problem then. There
is still a slightly different case that I'm not sure about. In the case of
CTC, the type of a device is determined during probe (depending on what's on
the other side, but the driver handles both tty and network ctc devices. It
seems logical if this type maps to a device class, not an interface, as there
is no network device that ever implements a tty interface or vice versa (in
ppp, you have a parent-child relationship between these, not identity).
I suppose then, the ctc module should actually implement two drivers, one
for each class and handle detection in the two probe methods, right?
A similar example is the 'lcs' network driver, whose devices can be either
ethernet, token ring or fddi NICs. You said that these would be subclasses
of the network class, but could lcs also be simply belong to a non-specific
network driver class and not put each device in the respective sub class?
Or would it make more sense to have special subclass just for network
drivers with more than one layer-2 protocol?
Arnd <><
On Thu, 4 Jul 2002, Arnd Bergmann wrote:
> On Wednesday 03 July 2002 18:46, Patrick Mochel wrote:
>
> > However, in any class, there may be multiple interfaces available for a
> > particular device. It's these interfaces that userspace sees. A driver may
> > implement some or all of those interfaces, and they may or may not be
> > present based on the configuration of the kernel.
>
> Ah, that's the missing bit, at least the tape driver is no problem then. There
> is still a slightly different case that I'm not sure about. In the case of
> CTC, the type of a device is determined during probe (depending on what's on
> the other side, but the driver handles both tty and network ctc devices. It
> seems logical if this type maps to a device class, not an interface, as there
> is no network device that ever implements a tty interface or vice versa (in
> ppp, you have a parent-child relationship between these, not identity).
> I suppose then, the ctc module should actually implement two drivers, one
> for each class and handle detection in the two probe methods, right?
Yes, exactly.
> A similar example is the 'lcs' network driver, whose devices can be either
> ethernet, token ring or fddi NICs. You said that these would be subclasses
> of the network class, but could lcs also be simply belong to a non-specific
> network driver class and not put each device in the respective sub class?
> Or would it make more sense to have special subclass just for network
> drivers with more than one layer-2 protocol?
Thinking about it some more, I'm wondering if we treat them only as
belonging to the top-level networking class and have the layer-2 protocols
be interfaces to those devices. For most devices, there would be only one
interface, but it would also cover the case in which a device supports
multiple prototcols.
This is similar to the input layer. Initially, I had grouped specific
devices into subclasses. But, I learned that a device really belongs to
multiple subclasses (e.g. evdev and mouse). Hence the concept of one class
with multiple interfaces...
-pat
On Friday 05 July 2002 20:10, Patrick Mochel wrote:
> This is similar to the input layer. Initially, I had grouped specific
> devices into subclasses. But, I learned that a device really belongs to
> multiple subclasses (e.g. evdev and mouse). Hence the concept of one class
> with multiple interfaces...
I think this network device is a bit different. While AFAICS the mouse has
both interfaces at the same time, an lcs adapter always has exactly one
interface, but depending on some device properties, the interface can be
called _either_ 'eth0' or 'tr0' (or probably something else for fddi).
A possible class model to represent this might be:
- each device_driver belongs to one device_class
- a device_class has one or more subclasses
- a device belongs to one subclass of its drivers class
- a subclass has one or more interfaces that are implemented for
every device of this subclass
This is of course more complicated than your single class - multiple
interfaces solution but could be closer to what the drivers do today.
The tradeoff probably depends on how many drivers are as broken
as lcs and on how fine-grained you want your classes to be.
Arnd <><