Hello, I am working on a driver for a USB I/O box (it is a little plastic box with a USB port on one side and screw terminals on the other that are general purpose digital input/output) and I have ran into a design philosophy problem, so I thought that I would post my thoughts for discussion, maybe start an all out war... ;)
So here comes the real question... Do I come up with a new class maybe 'iobox' and handle the device specifics within the driver(s), or do I just make some generic driver to pass everything through to user space? Some thoughts... I know that the generic Linux philosophy is to make the drivers as generic as possible and pass everything through to user space. Having said that I see many examples otherwise in USB drivers like the usb-serial stuff which cooks everything down to the ttyUSB interface (serial), usb-net (network) just to name a few, and on the other you have a few things like hiddev, which for the most part simply passes the raw data into user space. >From my viewpoint, it seems that the entire USB philosophy is based on the driver/device concept (tie a specific driver to a specific device, which implies cooking everything down at the driver level to a uniform interface according to class), which really doesn't seem to fit the general Linux driver philosophy. Is there somewhere that it is set in stone where the line is to be drawn between the kernel and user space device specific issues? If not, maybe someone should think about doing as much... I would think that due to the general stability of the Linux OS that it has a very bright future in the industrial control market. Therefor I think that maybe someone (maybe me) should come up with a generic I/O board class/API on the kernel level that applies to all types of (non protocol) I/O devices (USB, PCI, ISA, whatever else). Since most I/O boards are just that, I think it would be a simple matter to come up with something that would handle the vast majority of boards. For example, you could use the read and write interface to read and write data to the various ports on the board however wide they are.. You could use several ioctls to select which port and for port configuration such as data direction or analog gain. Then map everything down to the device specific commands within the driver(s). Ports could be setup in groups of 16, 32, or whatever and probably should look something like... IO_PORT1 < Digital I/O ports ... IO_PORT64 DIN_PORT1 < Digital in ports ... DIN_PORT64 DOUT_PORT1 < Digital out ports ... DOUT_PORT64 AIN_PORT1 < Analog inputs ... AIN_PORT64 AOUT_PORT1 < Analog outputs ... AOUT_PORT64 COUNT_PORT1 < Event counters ... COUNT_PORT64 And to take it to an extreme I think that some sort of mmap function could be added to handle boards with sample memory (boards that take samples at a high rate and store them in internal memory). Any thoughts? -Neil Whelchel- First Light Internet Services 760 366-0145 - We don't do Window$, that's what the janitor is for - ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
