Re: USB Keyboard errors with 2.4.5-ac
On Friday 29 June 2001 19:27, Jordan Breeding wrote: > noticed my real problem with the keyboard. The kernel apparently > expects a PS/2 (AT) keyboard to be plugged in because if there isn't one > the kernel reports timeouts and seems slower than when there is a PS/2 > keyboard present, my guess is because it is waiting on all of those > timeouts. I use a USB keyboard (Macally iKey) and mouse (Logitech iFeel) without problems. I also get these messages, but I dont see any performance problem. It may help you to enable an option like "Legacy USB keyboard support" in your BIOS. This will emulate a PS/2 keyboard until USB is initialized. > The next major keyboard thing I noticed is that I can type on > certain keys but if I do anything like hit the caps lock key or number > lock a couple of times then the keyboard stops responding completely and > the kernel tells me that there was an error waiting on a IRQ on CPU #1. This was discussed in the USB mailing list a few weeks ago. Several people experienced this problem, including me. As a workaround, use the alternate UHCI (JE) driver. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Keyboard errors with 2.4.5-ac
On Friday 29 June 2001 19:27, Jordan Breeding wrote: noticed my real problem with the keyboard. The kernel apparently expects a PS/2 (AT) keyboard to be plugged in because if there isn't one the kernel reports timeouts and seems slower than when there is a PS/2 keyboard present, my guess is because it is waiting on all of those timeouts. I use a USB keyboard (Macally iKey) and mouse (Logitech iFeel) without problems. I also get these messages, but I dont see any performance problem. It may help you to enable an option like Legacy USB keyboard support in your BIOS. This will emulate a PS/2 keyboard until USB is initialized. The next major keyboard thing I noticed is that I can type on certain keys but if I do anything like hit the caps lock key or number lock a couple of times then the keyboard stops responding completely and the kernel tells me that there was an error waiting on a IRQ on CPU #1. This was discussed in the USB mailing list a few weeks ago. Several people experienced this problem, including me. As a workaround, use the alternate UHCI (JE) driver. bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Num
On Sunday 20 May 2001 15:40, Alexander Viro wrote: > > ctlfd = open_device_control_fd(fd); > > If fd is something that doesn't have a control interface (say, it already > > is a control filehandle), this returns an appropriate error code. > It may have several. Which one? That's why I proposed using multi-stream files. With a syscall like fd2 = open_substream(fd, "somename") you could have several control streams and also be prepared if you want to support multi-stream filesystems like NTFS in the future... BTW: how does this work in NT? Do you first open a file and then fork it like in my example, do they have a special open for substreams or is the substream always encoded in the filename? bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Num
On Sunday 20 May 2001 15:40, Alexander Viro wrote: ctlfd = open_device_control_fd(fd); If fd is something that doesn't have a control interface (say, it already is a control filehandle), this returns an appropriate error code. It may have several. Which one? That's why I proposed using multi-stream files. With a syscall like fd2 = open_substream(fd, somename) you could have several control streams and also be prepared if you want to support multi-stream filesystems like NTFS in the future... BTW: how does this work in NT? Do you first open a file and then fork it like in my example, do they have a special open for substreams or is the substream always encoded in the filename? bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]
On Saturday 19 May 2001 21:43, Pavel Machek wrote: > I think that plan9 uses something different -- they have ttyS0 and > ttyS0ctl. This would leave us with problem "how do I get handle to > ttyS0ctl when I only have handle to ttyS0"? One possibility is to add multiforked (multi-stream) file support to Linux, then you could have a control stream. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]
On Saturday 19 May 2001 21:43, Pavel Machek wrote: I think that plan9 uses something different -- they have ttyS0 and ttyS0ctl. This would leave us with problem how do I get handle to ttyS0ctl when I only have handle to ttyS0? One possibility is to add multiforked (multi-stream) file support to Linux, then you could have a control stream. bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Thursday 17 May 2001 22:00, Brian Wheeler wrote: > Consider an ID consisting of: > * vendor > * model Vendor and model ids are available for PCI and USB devices, but I think you can not assume that all busses have them and you dont gain anything if you keep them separate (unless you want to interpret the fields of the device id). In other words I would merge them into a single field. > * serial number > * content-cookie > * topology-cookie You need another field that contains a identifier for the bus or the scheme of the device id, because different busses use different formats and you cannot compare them. You could also merge content-cookie and serial number because you will always to interpret them together. > I suppose these ID fields could also be used by a userspace tool to > load/unload drivers as necessary. There is a problem with that idea: you often cannot generate the device id before the driver is available. Things like the content cookie and the serial number must be created by the driver, at least in some cases. For example a PCI ethernet card has a great serial number, its hardware address, but you can only get it after the driver has been loaded. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Thursday 17 May 2001 22:00, Brian Wheeler wrote: Consider an ID consisting of: * vendor * model Vendor and model ids are available for PCI and USB devices, but I think you can not assume that all busses have them and you dont gain anything if you keep them separate (unless you want to interpret the fields of the device id). In other words I would merge them into a single field. * serial number * content-cookie * topology-cookie You need another field that contains a identifier for the bus or the scheme of the device id, because different busses use different formats and you cannot compare them. You could also merge content-cookie and serial number because you will always to interpret them together. I suppose these ID fields could also be used by a userspace tool to load/unload drivers as necessary. There is a problem with that idea: you often cannot generate the device id before the driver is available. Things like the content cookie and the serial number must be created by the driver, at least in some cases. For example a PCI ethernet card has a great serial number, its hardware address, but you can only get it after the driver has been loaded. bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Thursday 17 May 2001 19:18, you wrote: > I wouldn't make that assumpation. I have two PS/2 keybaords attached to my > system and they don't have serial ids nor do they have vendor or product > ids. Yes, PS/2 is a system where you must use the location. That's why a device id must contain the id, the serial number AND the location. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Thursday 17 May 2001 08:43, Thomas Sailer wrote: > Cheap USB devices (and sometimes even expensive ones) > do not have serial numbers or other unique identifiers. > Therefore some sort of topology based addressing scheme > has to be used in that case. No, there is another addressing scheme that can be for devices without serial number: the vendor and product ids. Most people do not have two devices of the same kind, so you often do not need the topology at all. BTW this document describes the use of device ids on windows: http://www.osr.com/ddk/idstrings_8tt3.htm bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Thursday 17 May 2001 14:07, you wrote: > For identifying this is probably the right approach. However identifying is > not enough, as the ioctl discussion has shown. Capabilities are needed. How > can the device registry provide that information ? The device registry provides you with device's capabilities and has different meachanisms for different needs: - each device node has a type that describes the API (read/write format, ioctls) of the node. The type is set when you call devfs_register2 (a new version of devfs_register, set sets the node type and a connection to the physical device). So when you want to play pcm sound and your app supports OSS you search for the type "sound/oss/dsp" - each physical device gets a type that is intended to be shown to the user and may be simplified. It can be used for things like selecting a appropriate icon for a device. It is not guaranteed to be correctly and some devices may not have a type. - each bus subsystem and driver is free to add its own information. For example the PCI subsystem adds things like the interrupt, memory space and so on. User-space apps that dont know about it are required to ignore it. > If we register it together with the device, we might spend a lot of > resources needlessly and can't deal with devices whose capabilities > change dynamically. No, the device and bus-subsystem information is generated on-demand, the type isnt guaranteed to be correct (and can be changed at any time) and the API of your device nodes hopefully doesnt change or otherwise you will really confuse the apps. > In addition how do we export the information ? Proc ? Device nodes (bad for > network devices) ? The last version used a large XML file, but the next will expose the information in a (very) large number of proc files, each containing a single value. This required some changes in the proc API, but unfortunately I did not get a single comment on my patch (http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.1/1041.html).. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Thursday 17 May 2001 14:07, you wrote: For identifying this is probably the right approach. However identifying is not enough, as the ioctl discussion has shown. Capabilities are needed. How can the device registry provide that information ? The device registry provides you with device's capabilities and has different meachanisms for different needs: - each device node has a type that describes the API (read/write format, ioctls) of the node. The type is set when you call devfs_register2 (a new version of devfs_register, set sets the node type and a connection to the physical device). So when you want to play pcm sound and your app supports OSS you search for the type sound/oss/dsp - each physical device gets a type that is intended to be shown to the user and may be simplified. It can be used for things like selecting a appropriate icon for a device. It is not guaranteed to be correctly and some devices may not have a type. - each bus subsystem and driver is free to add its own information. For example the PCI subsystem adds things like the interrupt, memory space and so on. User-space apps that dont know about it are required to ignore it. If we register it together with the device, we might spend a lot of resources needlessly and can't deal with devices whose capabilities change dynamically. No, the device and bus-subsystem information is generated on-demand, the type isnt guaranteed to be correct (and can be changed at any time) and the API of your device nodes hopefully doesnt change or otherwise you will really confuse the apps. In addition how do we export the information ? Proc ? Device nodes (bad for network devices) ? The last version used a large XML file, but the next will expose the information in a (very) large number of proc files, each containing a single value. This required some changes in the proc API, but unfortunately I did not get a single comment on my patch (http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.1/1041.html).. bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Thursday 17 May 2001 08:43, Thomas Sailer wrote: Cheap USB devices (and sometimes even expensive ones) do not have serial numbers or other unique identifiers. Therefore some sort of topology based addressing scheme has to be used in that case. No, there is another addressing scheme that can be for devices without serial number: the vendor and product ids. Most people do not have two devices of the same kind, so you often do not need the topology at all. BTW this document describes the use of device ids on windows: http://www.osr.com/ddk/idstrings_8tt3.htm bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Thursday 17 May 2001 19:18, you wrote: I wouldn't make that assumpation. I have two PS/2 keybaords attached to my system and they don't have serial ids nor do they have vendor or product ids. Yes, PS/2 is a system where you must use the location. That's why a device id must contain the id, the serial number AND the location. bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: LANANA: To Pending Device Number Registrants
Miles Lane <[EMAIL PROTECTED]> wrote on 15/5/01 17:41: >Does your approach solve >the problem of USB devices, >like mice, that >don't have device ID's of any >sort, where topology is the >only way to >distinguish them? yes, that's what the location part is for. Bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Wednesday 16 May 2001 01:16, David Brownell wrote: >Only if it's augmented by additional device IDs, such as the >"what 's the physical connection for this interface" sort of >primitive that's been mentioned. >[...] > I suppose that for network interface names, some convention for > interface ioctls would suffice to solve that "identify" step. PCI > devices would return the slot_name, USB devices need something > like a patch I posted to linux-usb-devel a few months back. At this point of the discussion I would like to point to the Device Registry patch (http://www.tjansen.de/devreg) that already solves these problems and offers stable device ids for the identification of devices and finding their /dev nodes. The devreg device id has four components: the bus identifier, the location of the device (for pci bus number and slot number, for usb the bus number and a list of port numbers), a model (product and device id) and, if available, a serial number. With the matching algorithm from the libdevreg library you can correctly identifiy after a hotplug action or reboot - each device that has a serial numberas most of the better USB devices do, even if it location has changed - a device without a serial number whose location has not changed If you have a device without serial number and you changed its location the device id can be used for a guess that is correct as long as you dont have two devices of the same kind (same product and vendor ids). bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Wednesday 16 May 2001 01:16, David Brownell wrote: Only if it's augmented by additional device IDs, such as the what 's the physical connection for this interface sort of primitive that's been mentioned. [...] I suppose that for network interface names, some convention for interface ioctls would suffice to solve that identify step. PCI devices would return the slot_name, USB devices need something like a patch I posted to linux-usb-devel a few months back. At this point of the discussion I would like to point to the Device Registry patch (http://www.tjansen.de/devreg) that already solves these problems and offers stable device ids for the identification of devices and finding their /dev nodes. The devreg device id has four components: the bus identifier, the location of the device (for pci bus number and slot number, for usb the bus number and a list of port numbers), a model (product and device id) and, if available, a serial number. With the matching algorithm from the libdevreg library you can correctly identifiy after a hotplug action or reboot - each device that has a serial numberas most of the better USB devices do, even if it location has changed - a device without a serial number whose location has not changed If you have a device without serial number and you changed its location the device id can be used for a guess that is correct as long as you dont have two devices of the same kind (same product and vendor ids). bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: LANANA: To Pending Device Number Registrants
Miles Lane [EMAIL PROTECTED] wrote on 15/5/01 17:41: Does your approach solve the problem of USB devices, like mice, that don't have device ID's of any sort, where topology is the only way to distinguish them? yes, that's what the location part is for. Bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] proc fs extension for "one-value-per-file"
The following patch extends the proc fs api as discussed in the thread "/proc format" last month (http://marc.theaimsgroup.com/?t=9882254507=2=1). It adds the following features: - dynamic directories. Enables you to use directories for enumerations, similar to the per-process directories (/proc/) or usbdevfs. - context callbacks for directories. They can do things that are common for all files in a directory, like locking, and are also used for dynamic directories. - special functions with context support for proc files that containing short strings, integers or enums These things give the proc filesystem the functionality that I need for the Device Registry patch to replace the XML output with the one-value-per-file approach. The api is documented in fs/proc/onevalue.c. You can download the patch for 2.4.4 here (40 kB): http://www.tjansen.de/devreg/proc_ov-2.4.4.diff bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] proc fs extension for one-value-per-file
The following patch extends the proc fs api as discussed in the thread /proc format last month (http://marc.theaimsgroup.com/?t=9882254507w=2r=1). It adds the following features: - dynamic directories. Enables you to use directories for enumerations, similar to the per-process directories (/proc/number) or usbdevfs. - context callbacks for directories. They can do things that are common for all files in a directory, like locking, and are also used for dynamic directories. - special functions with context support for proc files that containing short strings, integers or enums These things give the proc filesystem the functionality that I need for the Device Registry patch to replace the XML output with the one-value-per-file approach. The api is documented in fs/proc/onevalue.c. You can download the patch for 2.4.4 here (40 kB): http://www.tjansen.de/devreg/proc_ov-2.4.4.diff bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Thursday 26 April 2001 00:24, Mark Hahn wrote: > I have a sense that all of these could be collapsed into a single > api where kernel systems would register hierarchies of tuples of > , where callback would be passed the tag, You also need to know the parent of the tuple to build a hierarchy. And it should be possible to create lists. The callback prototypes for values could look like this: int proc_value_cb_string(char *buf, void *context); // writes string to buf, // returns len of string or negative value for error int proc_value_cb_int(int *value, void *context); For parent/directory tuples you would provide two additional callbacks that set the context for their children and maybe take care of other things like locking (so they dont need to be done in every single value callback): void *proc_value_cb_level_enter(void *old_context); // returns new context void proc_value_cb_level_leave(void *old_context, void *new_context); For tuples with a list there would be two callbacks to get the list elements: int proc_value_cb_list_num(void *context); // returns number of elements void *proc_value_cb_list_context(int index, void *context); // returns context // of the element at the given index or NULL To register such a tuple you would have the following functions: void proc_value_register_string(parent_handle_t parent, const char *name, proc_value_cb_string cb); void proc_value_register_int(parent_handle_t parent, const char *name, proc_value_cb_int cb); parent_handle_t proc_value_register_parent(parent_handle_t parent, const char *name, proc_value_cb_level_enter cb1, proc_value_cb_level_leave cb2); parent_handle_t proc_value_register_list(parent_handle_t h, proc_value_cb_list_num cbnum, proc_value_cb_list_context cbcon); This is the simplest API that I can imagine for this. The only problem is that you need to write a callback for each value (file). Just printing XML still looks easier to me... > and proc code would take care of "rendering" the data into > human readable text (default), binary, or even xml. the latter > would require some signalling mechanism like O_PROC_XML or the like. Then you can argue that once you have a single format implemented in the kernel you can convert it to whatever you like in user-space. And it seems like the decision for "one-value-per-file" in /proc has already been made (please correct me if not and we start all over again), so I will try to make a generic API like the one above for it. > further, programs could perform a meta-query, where they ask for > the types and tags of a datum (or hierarchy), so that on subsequent > queries, they'd now how to handle binary data. That would undermine the only advantage of binary data: it's easy (and fast) to dump or read a C struct. Not that I would really care for binary data... bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Thursday 26 April 2001 00:24, Mark Hahn wrote: I have a sense that all of these could be collapsed into a single api where kernel systems would register hierarchies of tuples of type,tag,callback, where callback would be passed the tag, You also need to know the parent of the tuple to build a hierarchy. And it should be possible to create lists. The callback prototypes for values could look like this: int proc_value_cb_string(char *buf, void *context); // writes string to buf, // returns len of string or negative value for error int proc_value_cb_int(int *value, void *context); For parent/directory tuples you would provide two additional callbacks that set the context for their children and maybe take care of other things like locking (so they dont need to be done in every single value callback): void *proc_value_cb_level_enter(void *old_context); // returns new context void proc_value_cb_level_leave(void *old_context, void *new_context); For tuples with a list there would be two callbacks to get the list elements: int proc_value_cb_list_num(void *context); // returns number of elements void *proc_value_cb_list_context(int index, void *context); // returns context // of the element at the given index or NULL To register such a tuple you would have the following functions: void proc_value_register_string(parent_handle_t parent, const char *name, proc_value_cb_string cb); void proc_value_register_int(parent_handle_t parent, const char *name, proc_value_cb_int cb); parent_handle_t proc_value_register_parent(parent_handle_t parent, const char *name, proc_value_cb_level_enter cb1, proc_value_cb_level_leave cb2); parent_handle_t proc_value_register_list(parent_handle_t h, proc_value_cb_list_num cbnum, proc_value_cb_list_context cbcon); This is the simplest API that I can imagine for this. The only problem is that you need to write a callback for each value (file). Just printing XML still looks easier to me... and proc code would take care of rendering the data into human readable text (default), binary, or even xml. the latter would require some signalling mechanism like O_PROC_XML or the like. Then you can argue that once you have a single format implemented in the kernel you can convert it to whatever you like in user-space. And it seems like the decision for one-value-per-file in /proc has already been made (please correct me if not and we start all over again), so I will try to make a generic API like the one above for it. further, programs could perform a meta-query, where they ask for the types and tags of a datum (or hierarchy), so that on subsequent queries, they'd now how to handle binary data. That would undermine the only advantage of binary data: it's easy (and fast) to dump or read a C struct. Not that I would really care for binary data... bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Wednesday 25 April 2001 21:19, you wrote: > The corresponding one-value-per-file approach can probably be made to > be a single call per value. Yes, the real problem is writing a callback-based filesystem (unless you want to hold everything in memory). After thinking about it for the last two hours I already find the one-value-per-file approach not as hard to do as I did before, but it's still a lot of work. > Have you bothered to go back and read the old discussions on this topic? Yes. But in my case is different than, for example, the files in /proc/sys: - the file names in /proc/sys are static. For devreg the filenames must be made dynamically (similar to the /proc process directories or usbdevfs) - in /proc/sys there is just one piece for code responsible for every file or directory and no cooperation between different parts. If devreg creates, for example, a directory for a USB mouse it must be prepared to share this directory with the USB subsystem, the input subsystem and the USB hid driver. All four modules are responsible for their own files. - files and their content should be created on demand, so there must be some callback to tell the USB subsystem something like "the user just opened the directory of device X, please tell me which directories or files you want to add". It is certainly possible to convert devreg to the one-value-per-file approach and if this is all that it takes to get into some future (2.5) kernel I will do it. I just doubt that this is the easiest way to implement the functionality, because that's what I really want. > Are you trying to avoid writing a DTD? Yes, at least a have a complete DTD, because it would be a nightmare to maintain it. Each time somebody adds a new capability to a driver the DTD would have to be updated. And what about drivers that are not part of the official kernel? I thought about using a separate XML Schema definition for each namespace though. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Wednesday 25 April 2001 23:16, you wrote: > Not necessarily. If the "extended data" is put following the current data > (since the data is currently record oriented) just making the output > format longer will not/should not casue problems in reading the data. > Alternatively, you can always put one value per record: > tag:value > tag2:value2... Both solutions only work for simple data, they dont help for more complex things like adding a variable-sized list of structures. Actually the first devreg version used something like your second proposal and I gave it up because it wasnt flexible enough to add USB configuration data. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Wednesday 25 April 2001 21:37, you wrote: > Personally, I think >> proc_printf(fragment, "%d %d",get_portnum(usbdev), usbdev->maxchild); > is shorter (and faster) to parse with > fscanf(input,"%d %d",,); Right, but what happens if you need to extend the format? For example somebody adds support for USB 2.0 to the kernel and you need to some new values. Then you would have the choice between changing the format and breaking applications or keeping the format and dont provide the additional information. With XML (or single-value-per-file) it is easy to tell application to ignore unknown tags (or files). When you just list values you will be damned sooner or later, unless you make up additional rules that say how apps should handle these cases. And then your approach is no longer simple, but possibly even more complicated bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/proc format (was Device Registry (DevReg) Patch 0.2.0)
On Wednesday 25 April 2001 19:10, you wrote: > The command > more foo/* foo/*/* > will display the values in the foo subtree nicely, I think. Unfortunately it displays only the values. Dumping numbers and strings without knowing their meaning (and probably not even the order) is not very useful. > Better to factor the XML part out to a userspace library... But the one-value per file approach is MORE work. It would be less work to create XML and factor out the directory structure in user-space :) Devreg collects its data from the drivers, each driver should contribute the information that it can provide about the device. Printing a few values in XML format using the functions from xmlprocfs is as easy as writing proc_printf(fragment, "\n", get_portnum(usbdev), usbdev->maxchild); Extending the devreg output with driver-specific data means registering a callback function that prints the driver's data. The driver should use its own XML namespace, so whatever the driver adds will not break any (well-written) user-space applications. The data is created on-demand, so the values can be dynamic and do not waste any space when devreg is not used. The code is easy to read and not larger than a solution that creates static /proc entries, and holding the data completely static would take much more memory. And it takes less code than a solution that would create the values in /proc dynamically because this would mean one callback per file or a complicated way to specify several values with a single callback. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/proc format (was Device Registry (DevReg) Patch 0.2.0)
On Wednesday 25 April 2001 19:10, you wrote: The command more foo/* foo/*/* will display the values in the foo subtree nicely, I think. Unfortunately it displays only the values. Dumping numbers and strings without knowing their meaning (and probably not even the order) is not very useful. Better to factor the XML part out to a userspace library... But the one-value per file approach is MORE work. It would be less work to create XML and factor out the directory structure in user-space :) Devreg collects its data from the drivers, each driver should contribute the information that it can provide about the device. Printing a few values in XML format using the functions from xmlprocfs is as easy as writing proc_printf(fragment, usb:topology port=\%d\ portnum=\%d\/\n, get_portnum(usbdev), usbdev-maxchild); Extending the devreg output with driver-specific data means registering a callback function that prints the driver's data. The driver should use its own XML namespace, so whatever the driver adds will not break any (well-written) user-space applications. The data is created on-demand, so the values can be dynamic and do not waste any space when devreg is not used. The code is easy to read and not larger than a solution that creates static /proc entries, and holding the data completely static would take much more memory. And it takes less code than a solution that would create the values in /proc dynamically because this would mean one callback per file or a complicated way to specify several values with a single callback. bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Wednesday 25 April 2001 21:37, you wrote: Personally, I think proc_printf(fragment, %d %d,get_portnum(usbdev), usbdev-maxchild); is shorter (and faster) to parse with fscanf(input,%d %d,usbdev,maxchild); Right, but what happens if you need to extend the format? For example somebody adds support for USB 2.0 to the kernel and you need to some new values. Then you would have the choice between changing the format and breaking applications or keeping the format and dont provide the additional information. With XML (or single-value-per-file) it is easy to tell application to ignore unknown tags (or files). When you just list values you will be damned sooner or later, unless you make up additional rules that say how apps should handle these cases. And then your approach is no longer simple, but possibly even more complicated bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Wednesday 25 April 2001 23:16, you wrote: Not necessarily. If the extended data is put following the current data (since the data is currently record oriented) just making the output format longer will not/should not casue problems in reading the data. Alternatively, you can always put one value per record: tag:value tag2:value2... Both solutions only work for simple data, they dont help for more complex things like adding a variable-sized list of structures. Actually the first devreg version used something like your second proposal and I gave it up because it wasnt flexible enough to add USB configuration data. bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Wednesday 25 April 2001 21:19, you wrote: The corresponding one-value-per-file approach can probably be made to be a single call per value. Yes, the real problem is writing a callback-based filesystem (unless you want to hold everything in memory). After thinking about it for the last two hours I already find the one-value-per-file approach not as hard to do as I did before, but it's still a lot of work. Have you bothered to go back and read the old discussions on this topic? Yes. But in my case is different than, for example, the files in /proc/sys: - the file names in /proc/sys are static. For devreg the filenames must be made dynamically (similar to the /proc process directories or usbdevfs) - in /proc/sys there is just one piece for code responsible for every file or directory and no cooperation between different parts. If devreg creates, for example, a directory for a USB mouse it must be prepared to share this directory with the USB subsystem, the input subsystem and the USB hid driver. All four modules are responsible for their own files. - files and their content should be created on demand, so there must be some callback to tell the USB subsystem something like the user just opened the directory of device X, please tell me which directories or files you want to add. It is certainly possible to convert devreg to the one-value-per-file approach and if this is all that it takes to get into some future (2.5) kernel I will do it. I just doubt that this is the easiest way to implement the functionality, because that's what I really want. Are you trying to avoid writing a DTD? Yes, at least a have a complete DTD, because it would be a nightmare to maintain it. Each time somebody adds a new capability to a driver the DTD would have to be updated. And what about drivers that are not part of the official kernel? I thought about using a separate XML Schema definition for each namespace though. bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Registry (DevReg) Patch 0.2.0
On Tuesday 24 April 2001 18:43, mirabilos wrote: > What about indenting? I think of 0 spaces before the device name, > 1 space before properties which belong to the device. > Structure per entry: >[Space] Name colon property But what is the advantage? Its not less work in the kernel, and in user-space you need to write a parser for this. You would have made a new format for hierarchical data that no one else uses only to avoid using XML in the kernel. > Is one level enough? I'm currently offline so didn't check the sample No, for example for USB you have the levels devices/configurations/interfaces/endpoints. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Registry (DevReg) Patch 0.2.0
On Tuesday 24 April 2001 18:39, Martin Dalecki wrote: > Are there alternatives to get complex and extendable information out to > user space? > Yes filesystem structures. How exactly can this work? A single value per file is not very helpful if you have a thousand values. You could cluster them (for example one level in the XML hierarchy == one file), but this will soon get very complicated. Its much more work to implement in the kernel, its painful in user-space and you cant just use a text editor to look at it (because you always have to look at 10 files per device). IMHO only a single XML file per physical device is an option, but I do not know how to name the files... > Or just simple parsing in the user space plain binary data. This would be a compatibility nightmare and hard to maintain. Once you decided for a binary format you cannot change or extend it without breaking user-space apps. This may save a few lines code, but not many. All you need to add a line to XML output is a sprintf and a call to devreg_write_line(). One of the ideas of devreg is that while it has a common format for generic information, like the name and topology of physical devices, every driver can add additional data (this is why XML namespaces are used). Currently only the USB and PCI subsystems add data to devreg, but in future versions the device driver itself or other subsystems should do this, too. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Registry (DevReg) Patch 0.2.0
On Tuesday 24 April 2001 11:40, Martin Dalecki wrote: > Tim Jansen wrote: > > The Linux Device Registry (devreg) is a kernel patch that adds a device > > database in XML format to the /proc filesystem. It collects all > OH SHIT!! ^^^ > Why don't you just add postscript output to /proc? XML wasn't my first choice. The 0.1.x versions used simple name/value pairs, I gave this up after trying to fit the complex USB configuration/interface/endpoint data into name/value pairs. Thinking about text file formats that allow me to display hierarchical information, XML was the obvious choice for me. Are there alternatives to get complex and extendable information out to user space? (see http://www.tjansen.de/devreg/devreg.output.txt for a example /proc/devreg output) My other ideas were: - using a simple binary format, just dump structs. This would break all applications every time somebody changes the format, and this should happen very often because of the nature of the format - using a complicated, extendable binary format, for example chunk-based like (a|r)iff file formats. This would add more code in the kernel than XML output, is difficult to understand and requires more work in user space (because XML parsers are already available) - making up a new text-based format with properties similar to XML because I knew that many people dont like the idea of XML output in the kernel.. I really thought about it, but it does not make much sense. The actual code overhead of XML output compared to a format like /proc/bus/usb/devices is almost zero, XML is only a little bit more verbose. I agree that XML is not perfect for this kind of data, but it is simple to generate, well known and I dont see a better alternative. bye.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Registry (DevReg) Patch 0.2.0
On Tuesday 24 April 2001 11:40, Martin Dalecki wrote: Tim Jansen wrote: The Linux Device Registry (devreg) is a kernel patch that adds a device database in XML format to the /proc filesystem. It collects all OH SHIT!! ^^^ Why don't you just add postscript output to /proc? XML wasn't my first choice. The 0.1.x versions used simple name/value pairs, I gave this up after trying to fit the complex USB configuration/interface/endpoint data into name/value pairs. Thinking about text file formats that allow me to display hierarchical information, XML was the obvious choice for me. Are there alternatives to get complex and extendable information out to user space? (see http://www.tjansen.de/devreg/devreg.output.txt for a example /proc/devreg output) My other ideas were: - using a simple binary format, just dump structs. This would break all applications every time somebody changes the format, and this should happen very often because of the nature of the format - using a complicated, extendable binary format, for example chunk-based like (a|r)iff file formats. This would add more code in the kernel than XML output, is difficult to understand and requires more work in user space (because XML parsers are already available) - making up a new text-based format with properties similar to XML because I knew that many people dont like the idea of XML output in the kernel.. I really thought about it, but it does not make much sense. The actual code overhead of XML output compared to a format like /proc/bus/usb/devices is almost zero, XML is only a little bit more verbose. I agree that XML is not perfect for this kind of data, but it is simple to generate, well known and I dont see a better alternative. bye.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Registry (DevReg) Patch 0.2.0
On Tuesday 24 April 2001 18:43, mirabilos wrote: What about indenting? I think of 0 spaces before the device name, 1 space before properties which belong to the device. Structure per entry: [Space] Name colon property But what is the advantage? Its not less work in the kernel, and in user-space you need to write a parser for this. You would have made a new format for hierarchical data that no one else uses only to avoid using XML in the kernel. Is one level enough? I'm currently offline so didn't check the sample No, for example for USB you have the levels devices/configurations/interfaces/endpoints. bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Device Registry (DevReg) Patch 0.2.0
The Linux Device Registry (devreg) is a kernel patch that adds a device database in XML format to the /proc filesystem. It collects all information about the system's physical devices, creates persistent device ids and provides them in the file /proc/devreg. Devreg has three purposes: - collect all configuration data from drivers so the user can browse his hardware configuration. -allow an application to display all devices that provide a certain interface (for example all mice) so the user can chose one. -allow an application to find the device that the user has selected after a reboot or a hotplug action: the device files in /dev do not offer stable names, they depend on the order in that the devices have been plugged in or powered on. Changes since last release (0.1.1): - converted file format to XML - bus-specific information from pci and usb added - fixed locking The patch (for 2.4.3) can be found at http://www.tjansen.de/devreg/devreg-2.4.3-0.2.0.diff.gz To test it, apply the patch, select CONFIG_DEVFS_FS and CONFIG_DEVREG and compile. Note that the patch will break binary drivers. Supported hardware in version 0.2.0: PCI subsystem, USB subsystem, most PCI sound cards, USB HID devices, USB hubs, USB printers Other information and a user-space library can be found at http://www.tjansen.de/devreg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Device Registry (DevReg) Patch 0.2.0
The Linux Device Registry (devreg) is a kernel patch that adds a device database in XML format to the /proc filesystem. It collects all information about the system's physical devices, creates persistent device ids and provides them in the file /proc/devreg. Devreg has three purposes: - collect all configuration data from drivers so the user can browse his hardware configuration. -allow an application to display all devices that provide a certain interface (for example all mice) so the user can chose one. -allow an application to find the device that the user has selected after a reboot or a hotplug action: the device files in /dev do not offer stable names, they depend on the order in that the devices have been plugged in or powered on. Changes since last release (0.1.1): - converted file format to XML - bus-specific information from pci and usb added - fixed locking The patch (for 2.4.3) can be found at http://www.tjansen.de/devreg/devreg-2.4.3-0.2.0.diff.gz To test it, apply the patch, select CONFIG_DEVFS_FS and CONFIG_DEVREG and compile. Note that the patch will break binary drivers. Supported hardware in version 0.2.0: PCI subsystem, USB subsystem, most PCI sound cards, USB HID devices, USB hubs, USB printers Other information and a user-space library can be found at http://www.tjansen.de/devreg - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[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
