Re: devfs - why not ?

From: Marek Habersack (grendel@vip.net.pl)
Date: Thu Apr 13 2000 - 09:58:39 EST


** On Apr 13, Keith Owens scribbled:
> On Thu, 13 Apr 2000 16:19:05 +0200,
> grendel@vip.net.pl (Marek Habersack) wrote:
> >** On Apr 13, Keith Owens scribbled:
> >> that, depmod will be using MODULE_DEVICE_TABLE and creating
> >> /lib/modules/`uname -r`/modules_device_table. We need the vendor and
> >So it will actually be possible to register a class of devices to one
> >driver, right?
>
> Not sure what you mean by that. See example below.
By class I mean a range of assigned device numbers to one particular type of
devices - like serial ports - when you don't know beforehand how many of
them will there be in the future, but all of them can be driven using the
same device driver.

> >> device codes, not just the device name. Expect modutils 2.3.11 this
> >> weekend.
> >You mean like the PCI registered codes? Or Linux-specific ones?
>
> MODULE_DEVICE_TABLE points at a struct <type>_device_id, currently he
> only defined type is pci.
Is there a plan to create a registrar for other, non-pci, devices?

> struct pci_device_id {
> unsigned int vendor, device; /* Vendor and device ID or PCI_ANY_ID */
> unsigned int subvendor, subdevice; /* Subsystem ID's or PCI_ANY_ID */
> unsigned int class, class_mask; /* (class,subclass,prog-if) triplet */
> unsigned long driver_data; /* Data private to the driver */
> };
>
> depmod will extract the first 6 fields and print them together with the
> module that supports them. So plug in a device with vendor code
> 0x0105, device code 0x0103 and some (yet to be written) handler will
> scan module_device_table, find the matching line and load the module
> that supports it. In this case, it is a Xircom RBEM56G so the handler
> will load tulip_cb (or whatever Jeff is calling the module this week ;).
:)) Nice and clear. That could be extended to support tree structures for
devices:

Vendor
  |
  +--- some_chip -> registered driver for some_chip
           |
           |
       some_card_using_some_chip -> registered driver for this card

Now, the some_card* uses the chip, but is more "specific" because the chip
is installed on some_card that has some additional features and therefore is
driven by the driver that is registered below the more generic some_chip
one.

marek



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:21 EST