Messages in this thread | | | Date | Fri, 5 Jul 2002 11:10:21 -0700 (PDT) | From | Patrick Mochel <> | Subject | Re: Device Model Docs |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |