On 8 Jul 2003 at 23:30, Oliver Neukum wrote: > > > > Don't drag USB into this. There's no reason to specify how the bus > > > is connected to the host. The cleanest way to do this is to get a > > > GPIB major number. > > > > > > > That seems like a cleaner way to do it. Hide the USB connectivity > > from the user. But there's still the problem of hotplugging. > > That's not confined to USB. These days PCI is hotpluggable as well. > > > > > 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 ??? > > > > > > If you wish to export all a bus's devices to user space, you might > > > just as well register 2**5 devices per GPIB bus. Could you state > > > your problem more clearly? > > > > > > > Clarity is actually the essence of the problem. Each system will be > > different, and each user will likely have many different system > > configurations, which could change many times per day. I have no > > control over the configuration. I have to support whatever the > > client chooses to define. > > What do you need? > A full support of all features and devices of GPIB is about as complex > as the whole SCSI layer.
I know. That's what I'm worried about. The only existing product (from a competitor) has full device support. For example, if you connect a printer to the GPIB, it shows up as /dev/prn3 or whatever/ You can do 'cat textfile >/dev/prn3' and it works. That's the level of support that I'm trying to provide. I'm really trying to hide both the USB layer and the GPIB layer from the user, and make the devices appear native. > > The simplest option is representing the whole bus as one device. > That's the conventional and easy solution. > It has some obvious drawbacks: > 1. Essentially single user operation > 2. Some devices need kernel drivers (disks, keyboards, ...) > > If you can live with representing any device on the bus as a device > you can register a device for each address possible on GPIB and get > away with a thin generic layer doing TALK/LISTEN and handle SRQ > > If you need to represent several kinds of devices as several kinds of > device nodes, you have a problem. You basically need to write a GPIB > subsystem, in which the driver for your physical device would be in > the same role as for example the OHCI driver is to USB in general. Unfortunately, I'm afraid that's what I'm faced with. > > > > > 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. > > > > > > Almost impossible unless you can tell GPIB adapters apart. > > > > > > > I can identify them by serial number. > > Export it and leave the rest to hotplug scripts. > A few symlinks can fix the problem. > I hadn't considered links, but that sounds reasonable. The scripts set up the links as part of the initialization procedure. > Regards > Oliver > > Thanks very much. I certainly appreciate your advice. 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
