On 8 Jul 2003 at 13:22, Alan Stern wrote: > On Tue, 8 Jul 2003 [EMAIL PROTECTED] wrote: > > > Hello all, > > > > I'm setting up a device driver for a GPIB (IEEE-488) interface. > > GPIB is a General-Purpose Interface Bus (hence the name) which > > enables connection of arbitrary peripherals to a PC. It's used > > primarily to support automated test facilities in manufacturing > > environments. > > > > Each interface can support up to 30 peripheral devices (hard limit > > per the GPIB spec), which can include hard drives, keyboards, > > printers, etc. My design will support up to eight interfaces > > (arbitrary limit). > > > > I need to map peripherals to user-visible nodes like /dev/prn0 or > > /dev/usb/prn0. I don't know how to register the driver for these > > nodes since the configuration is defined by user software. The only > > access to the driver from user space appears to be through the > > open() or ioctl() functions, but the driver must already be > > registered for a node before being called. Seems to be a > > chicken-and-egg problem ??? > > > > Also, these mappings must persist through unplugging and replugging > > of interfaces, regardless of the order in which this is done, since > > the external bus is hard-wired. > > > > Any help would be much appreciated. > > > > Leigh Bassett > > While it's true that the driver has to be registered for _something_ > before it can be called from userspace, that something needn't be one > of the devices it controls. For example, you could create an entry > under /proc or /sys (for Linux 2.5) and use that to manage the driver. > You could even get a miscellaneous char device number assigned to > your driver and devote that to its management. That would take care > of the chicken-and-egg problem. > > For the mappings to persist through plugging and unplugging of > interfaces, you must have some way for the driver to distinguish one > interface from another. Otherwise how could you tell which mapping to > install when an interface is plugged in? Under the assumption that > this isn't a problem, the mapping information has to be available to a > user process which can inform your driver at the appropriate times. > For example, you could have a peripheral device management program > which would store the configurations in a file, and a hotplug script > could read and transmit the file to the driver each time an interface > is attached. > > I hope this is the sort of thing you're looking for... > > Alan Stern >
Hi Alan, Thanks for the quick response. Right now I'm setting up one device per interface (using my company name ATS) at /dev/usb/ats[0-7]. This gives me access to the base device in the interface. I'm currently using the USB major (180) and minors 128-135. How would I get a miscellaneous character device major assigned? That seems the appropriate method, since the entire GPIB system could support 256 peripherals. (Actually many more since there is a sub- addressing mechanism that supports 256 logical devices at each physical GPIB address, so 64K devices is the theoretical maximum). I hadn't considered using the hotplug script mechanism for configuring the system, but it might be appropriate. The system configuration actually changes depending on what user program is running at the time, with some devices being ignored and other bus addresses being reused by different devices. For example you could disconnect a DVM (/dev/usb/dvm0) at GPIB address 17 and connect a printer (/dev/usb/prn0) at GPIB address 17, then run the program that understands that topology. This particular program would never access /dev/usb/dvm0 even though that device was defined in the overall system. I'm working with the 2.4 kernel as a development platform. Since this product will go into existing installations, I expect most of the customers will have that version. I'm hoping I don't have to support 2.2. Support for the 2.6 kernel will be added when it becomes commercially available. Thanks very much for your help. Greatly appreciated. Leigh Bassett ------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
