Re: [RFC/Patch] Device Registry
Tim, what is it that this is designed to do that devfs doesn't (or can't) do? David Lang On Sat, 17 Mar 2001, Tim Jansen wrote: > Date: Sat, 17 Mar 2001 03:10:33 +0100 > From: Tim Jansen <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [RFC/Patch] Device Registry > > RFC: Linux Device Registry > == > > Summary > --- > The device registry provides a /proc file in text format that contains > a list of all connected physical devices. Each list entry > includes (as far as available) the name and vendor of the device, its > location/topological information, the device files (/dev) that the > driver(s) have registered and a unique DeviceID that makes it possible to > find the device after a reboot. > An experimental patch for 2.4.2 can be found at http://www.tjansen.de/devreg > > > Reasons for the Device Registry > --- > Finding the available devices with the current Linux kernel is difficult > and not always possible. For example the only way to get all printers on > Linux is to open all devices in /dev that could represent one, but > this has some limitations. The first problem is that the user-space app must > know which files should be probed. The /dev/lpX files are candidates > and for USB printers also /dev/usb/lpX. Everytime a new bus for printers > is added there is a new range of device files that must be probed, for > example for IEEE1394/FireWire printers user-space apps would have to probe > the /dev/ieee1394/lpX (or whatever their names will be). This makes it > impossible to write forward-compatible user-space applications. > > Even if the application knows which devices are actual printers they > must be presented to the user so that he can select one of them, > and for this things like the printers name and vendor are neccessary. > Unfortunately every bus has a different facility to provide these > information. Parallel ports expose them in /proc/sys/dev/parport; USB > shows them in usbdevfs, but it is not possible to figure out which > /dev/usb/lpX file belongs to which physical printer. And as IEEE1394 will > have to implement another method to get information about the printer > device, user-apps today have no chance to get show them when kernel support is > ready. > > The next problem is associated with hotplugging. If you have two printers > attached to the USB bus, say an Epson and a HP printer, you dont know > their device files. If you turn on the Epson printer and then the HP printer, > the Epson will be /dev/usb/lp0 and the HP /dev/usb/lp1. When you first > power on the HP on the next reboot (or turn off the Epson before you turn the > HP on) it will be on /dev/usb/lp0. > > Sometimes devices have several independent interfaces that belong together. > For example there are USB scanners with buttons that are intended to trigger > actions by user-space applications like starting a scan. The USB driver uses > two separate drivers for them, in the case of a scanner it would use a HID > driver (there is a patch available for non-keyboards/mice/joystick input > devices) and a regular scanner driver. A similar setup is also common for USB > audio devices. > With the current implementation it is not possible to find out which device > files represent which physical device. > > > Solutions provided by the Device Registry > - > The Device Registry (DevReg) puts a text list of all physical devices > into /proc/devreg. Each entry consists of: > > - the model and vendor name of the device (if available) > - the type of the device (for example hub/usb) > - the bus/location of the device (for example COM2 or USB) > - topology information (to build a tree of all devices) > - the unique DeviceID to find the device after a reboot > - the device files (if devfs is used) and the major/minor number of > the device files and the interface it implements (for example OSS or V4L) > > This should be sufficient for the following use cases: > - find all devices that implement a interface (for example > all OSS devices) and present them to the user he can chose one > - get the DeviceID of a device so its device file can be found after a > reboot > - find a device file for a DeviceID > - show all devices in the computer > > Finding a device with a DeviceID instead of a device file name is neither > supported by current applications nor by other Unix-like operating > systems. Therefore, to stay compatible with existing software, a user-space > daemon could take care of creating stable names for devices. > For example, if you have the Epson and HP printer from the example above, > the daemon could create two symlinks called /dev/lpEpso
[RFC/Patch] Device Registry
RFC: Linux Device Registry == Summary --- The device registry provides a /proc file in text format that contains a list of all connected physical devices. Each list entry includes (as far as available) the name and vendor of the device, its location/topological information, the device files (/dev) that the driver(s) have registered and a unique DeviceID that makes it possible to find the device after a reboot. An experimental patch for 2.4.2 can be found at http://www.tjansen.de/devreg Reasons for the Device Registry --- Finding the available devices with the current Linux kernel is difficult and not always possible. For example the only way to get all printers on Linux is to open all devices in /dev that could represent one, but this has some limitations. The first problem is that the user-space app must know which files should be probed. The /dev/lpX files are candidates and for USB printers also /dev/usb/lpX. Everytime a new bus for printers is added there is a new range of device files that must be probed, for example for IEEE1394/FireWire printers user-space apps would have to probe the /dev/ieee1394/lpX (or whatever their names will be). This makes it impossible to write forward-compatible user-space applications. Even if the application knows which devices are actual printers they must be presented to the user so that he can select one of them, and for this things like the printers name and vendor are neccessary. Unfortunately every bus has a different facility to provide these information. Parallel ports expose them in /proc/sys/dev/parport; USB shows them in usbdevfs, but it is not possible to figure out which /dev/usb/lpX file belongs to which physical printer. And as IEEE1394 will have to implement another method to get information about the printer device, user-apps today have no chance to get show them when kernel support is ready. The next problem is associated with hotplugging. If you have two printers attached to the USB bus, say an Epson and a HP printer, you dont know their device files. If you turn on the Epson printer and then the HP printer, the Epson will be /dev/usb/lp0 and the HP /dev/usb/lp1. When you first power on the HP on the next reboot (or turn off the Epson before you turn the HP on) it will be on /dev/usb/lp0. Sometimes devices have several independent interfaces that belong together. For example there are USB scanners with buttons that are intended to trigger actions by user-space applications like starting a scan. The USB driver uses two separate drivers for them, in the case of a scanner it would use a HID driver (there is a patch available for non-keyboards/mice/joystick input devices) and a regular scanner driver. A similar setup is also common for USB audio devices. With the current implementation it is not possible to find out which device files represent which physical device. Solutions provided by the Device Registry - The Device Registry (DevReg) puts a text list of all physical devices into /proc/devreg. Each entry consists of: - the model and vendor name of the device (if available) - the type of the device (for example hub/usb) - the bus/location of the device (for example COM2 or USB) - topology information (to build a tree of all devices) - the unique DeviceID to find the device after a reboot - the device files (if devfs is used) and the major/minor number of the device files and the interface it implements (for example OSS or V4L) This should be sufficient for the following use cases: - find all devices that implement a interface (for example all OSS devices) and present them to the user he can chose one - get the DeviceID of a device so its device file can be found after a reboot - find a device file for a DeviceID - show all devices in the computer Finding a device with a DeviceID instead of a device file name is neither supported by current applications nor by other Unix-like operating systems. Therefore, to stay compatible with existing software, a user-space daemon could take care of creating stable names for devices. For example, if you have the Epson and HP printer from the example above, the daemon could create two symlinks called /dev/lpEpson and /dev/lpHP that always point to the correct device file as long as the physical device is connected. As the format of the /proc/devreg file is relatively complex a user-space library that implements the use cases given above will be provided. DeviceID Each device get a unique device id. The id is a string in the format "bus-type/location/model/serialnum". bus-type is "usb" or "pci" for the currently supported busses. location is "busnumber:slotnumber" for PCI devices and "busnumber[:1st-hub-model:1st-hub-vendor[:2nd-hub-model:2nd-hub-vendor..]]" for USB devices. The format of the model is "vendorID:deviceID" for both USB and PCI. The serial number is
[RFC/Patch] Device Registry
RFC: Linux Device Registry == Summary --- The device registry provides a /proc file in text format that contains a list of all connected physical devices. Each list entry includes (as far as available) the name and vendor of the device, its location/topological information, the device files (/dev) that the driver(s) have registered and a unique DeviceID that makes it possible to find the device after a reboot. An experimental patch for 2.4.2 can be found at http://www.tjansen.de/devreg Reasons for the Device Registry --- Finding the available devices with the current Linux kernel is difficult and not always possible. For example the only way to get all printers on Linux is to open all devices in /dev that could represent one, but this has some limitations. The first problem is that the user-space app must know which files should be probed. The /dev/lpX files are candidates and for USB printers also /dev/usb/lpX. Everytime a new bus for printers is added there is a new range of device files that must be probed, for example for IEEE1394/FireWire printers user-space apps would have to probe the /dev/ieee1394/lpX (or whatever their names will be). This makes it impossible to write forward-compatible user-space applications. Even if the application knows which devices are actual printers they must be presented to the user so that he can select one of them, and for this things like the printers name and vendor are neccessary. Unfortunately every bus has a different facility to provide these information. Parallel ports expose them in /proc/sys/dev/parport; USB shows them in usbdevfs, but it is not possible to figure out which /dev/usb/lpX file belongs to which physical printer. And as IEEE1394 will have to implement another method to get information about the printer device, user-apps today have no chance to get show them when kernel support is ready. The next problem is associated with hotplugging. If you have two printers attached to the USB bus, say an Epson and a HP printer, you dont know their device files. If you turn on the Epson printer and then the HP printer, the Epson will be /dev/usb/lp0 and the HP /dev/usb/lp1. When you first power on the HP on the next reboot (or turn off the Epson before you turn the HP on) it will be on /dev/usb/lp0. Sometimes devices have several independent interfaces that belong together. For example there are USB scanners with buttons that are intended to trigger actions by user-space applications like starting a scan. The USB driver uses two separate drivers for them, in the case of a scanner it would use a HID driver (there is a patch available for non-keyboards/mice/joystick input devices) and a regular scanner driver. A similar setup is also common for USB audio devices. With the current implementation it is not possible to find out which device files represent which physical device. Solutions provided by the Device Registry - The Device Registry (DevReg) puts a text list of all physical devices into /proc/devreg. Each entry consists of: - the model and vendor name of the device (if available) - the type of the device (for example hub/usb) - the bus/location of the device (for example COM2 or USB) - topology information (to build a tree of all devices) - the unique DeviceID to find the device after a reboot - the device files (if devfs is used) and the major/minor number of the device files and the interface it implements (for example OSS or V4L) This should be sufficient for the following use cases: - find all devices that implement a interface (for example all OSS devices) and present them to the user he can chose one - get the DeviceID of a device so its device file can be found after a reboot - find a device file for a DeviceID - show all devices in the computer Finding a device with a DeviceID instead of a device file name is neither supported by current applications nor by other Unix-like operating systems. Therefore, to stay compatible with existing software, a user-space daemon could take care of creating stable names for devices. For example, if you have the Epson and HP printer from the example above, the daemon could create two symlinks called /dev/lpEpson and /dev/lpHP that always point to the correct device file as long as the physical device is connected. As the format of the /proc/devreg file is relatively complex a user-space library that implements the use cases given above will be provided. DeviceID Each device get a unique device id. The id is a string in the format "bus-type/location/model/serialnum". bus-type is "usb" or "pci" for the currently supported busses. location is "busnumber:slotnumber" for PCI devices and "busnumber[:1st-hub-model:1st-hub-vendor[:2nd-hub-model:2nd-hub-vendor..]]" for USB devices. The format of the model is "vendorID:deviceID" for both USB and PCI. The serial number is
Re: [RFC/Patch] Device Registry
Tim, what is it that this is designed to do that devfs doesn't (or can't) do? David Lang On Sat, 17 Mar 2001, Tim Jansen wrote: Date: Sat, 17 Mar 2001 03:10:33 +0100 From: Tim Jansen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [RFC/Patch] Device Registry RFC: Linux Device Registry == Summary --- The device registry provides a /proc file in text format that contains a list of all connected physical devices. Each list entry includes (as far as available) the name and vendor of the device, its location/topological information, the device files (/dev) that the driver(s) have registered and a unique DeviceID that makes it possible to find the device after a reboot. An experimental patch for 2.4.2 can be found at http://www.tjansen.de/devreg Reasons for the Device Registry --- Finding the available devices with the current Linux kernel is difficult and not always possible. For example the only way to get all printers on Linux is to open all devices in /dev that could represent one, but this has some limitations. The first problem is that the user-space app must know which files should be probed. The /dev/lpX files are candidates and for USB printers also /dev/usb/lpX. Everytime a new bus for printers is added there is a new range of device files that must be probed, for example for IEEE1394/FireWire printers user-space apps would have to probe the /dev/ieee1394/lpX (or whatever their names will be). This makes it impossible to write forward-compatible user-space applications. Even if the application knows which devices are actual printers they must be presented to the user so that he can select one of them, and for this things like the printers name and vendor are neccessary. Unfortunately every bus has a different facility to provide these information. Parallel ports expose them in /proc/sys/dev/parport; USB shows them in usbdevfs, but it is not possible to figure out which /dev/usb/lpX file belongs to which physical printer. And as IEEE1394 will have to implement another method to get information about the printer device, user-apps today have no chance to get show them when kernel support is ready. The next problem is associated with hotplugging. If you have two printers attached to the USB bus, say an Epson and a HP printer, you dont know their device files. If you turn on the Epson printer and then the HP printer, the Epson will be /dev/usb/lp0 and the HP /dev/usb/lp1. When you first power on the HP on the next reboot (or turn off the Epson before you turn the HP on) it will be on /dev/usb/lp0. Sometimes devices have several independent interfaces that belong together. For example there are USB scanners with buttons that are intended to trigger actions by user-space applications like starting a scan. The USB driver uses two separate drivers for them, in the case of a scanner it would use a HID driver (there is a patch available for non-keyboards/mice/joystick input devices) and a regular scanner driver. A similar setup is also common for USB audio devices. With the current implementation it is not possible to find out which device files represent which physical device. Solutions provided by the Device Registry - The Device Registry (DevReg) puts a text list of all physical devices into /proc/devreg. Each entry consists of: - the model and vendor name of the device (if available) - the type of the device (for example hub/usb) - the bus/location of the device (for example COM2 or USB) - topology information (to build a tree of all devices) - the unique DeviceID to find the device after a reboot - the device files (if devfs is used) and the major/minor number of the device files and the interface it implements (for example OSS or V4L) This should be sufficient for the following use cases: - find all devices that implement a interface (for example all OSS devices) and present them to the user he can chose one - get the DeviceID of a device so its device file can be found after a reboot - find a device file for a DeviceID - show all devices in the computer Finding a device with a DeviceID instead of a device file name is neither supported by current applications nor by other Unix-like operating systems. Therefore, to stay compatible with existing software, a user-space daemon could take care of creating stable names for devices. For example, if you have the Epson and HP printer from the example above, the daemon could create two symlinks called /dev/lpEpson and /dev/lpHP that always point to the correct device file as long as the physical device is connected. As the format of the /proc/devreg file is relatively complex a user-space library that implements the use cases given above will be provided. DeviceID Each device get a unique device id. The id is a string in the format "bus-type/loc
