Parallel port emulator/Virtual parallel port

You've answered most of it, let me clarify a bit:  There are a few computers, networked together and to the serial port switch, i.e. a box with 32 serial ports and an ethernet port.  We *can* connect the parallel devices directly to the computers, but that would make a computer failure potentially catastrophic, so we want the parallel ports to be accessed over the serial ports on the serial port switch, which requires a parallel-serial converter microprocessor.  What is needed is a virtual linux driver that looks like a parallel port, which you said would be easy.  I assume that with that written, the driver for the controller can be told to access the virtual parallel port.

With that said, what is required in writing this driver?  I don't need elaborate details, as I probably will not be doing it myself.  Could you give me an outline of what is required?

Thanks.

Maybe I'm being dense but I still don't see the path the data is actually going.  Is it

Linux computer - Ethernet - ethernet port on serial switch - serial switch serial port - your microprocessor - parallel port?

or is it

Linux computer - serial port - serial port on serial switch - another serial port on serial port switch - your microprocessor - parallel port?

or something else?

And why do you want the driver to be a 'virtual' parallel port?  By that do you mean the driver should appear to user software to be a parallel port device, but it's really connecting to something else?  What's that something else it's really connecting to?  The serial port? The ethernet port? Or what? Is there a reason the data can't simply go out the real serial/ethernet port and the hardware handles all the conversions?

At any rate, Linux device drivers are really easy to write.  /usr/src/linux/drivers/char/lp.c  and drivers/parport* should give you a start, as well as Alessandro Rubini's 'Linux Device Drivers' book.  The chapter on char drivers is online at http://www.xml.com/ldd/chapter/book/ch03.html.  If  you  are targeting the 2.6 kernel series, there are some changes; I don't know if they are covered in the second edition of his book, but the first edition was good and covered all the bases.

The former.  All the computers are networked together on ethernet, along with the switch.  The serial ports are exclusively for controllers and data devices.

I figured that "virtual" was the right word to use.  The driver I would write would talk to the serial port switch, and specifically the serial port the microprocessor is running on.  The driver for any specific actuator would only see the two endpoints of the chain you described.

It doesn't seem to me that you need any driver other than the existing serial port driver, if the data is going in/out of the Linux box through the serial port to the serial port switch.  I'm assuming the information needed to talk to the switch is going to be going through the serial port data stream anyway, and the serial port switch looks for special escape codes to direct the data. Unless you are using the modem control pins (DTR, DTS, etc) in a non-standard way?

It might be possible to write one driver that installed several fake actuator devices (/dev/actuator1, /dev/actuator2) and when it got the data from any device file, looked up what needed to be done to get the data to the actuator, perhaps by reading an initialization file on startup - there are examples of setting up a driver module that creates several device files in the Rubini book.

I left out of the last comment that this driver, once it got data for /dev/actuator0, would then resend the data through the regular serial port driver along with any other control info needed to get the data to the right actuator.  

You misread my last comment -- the computers are networked together and to the switch with ETHERNET.  When I said "the former," I was referring to:

Linux computer - Ethernet - ethernet port on serial switch - serial switch serial port - your microprocessor - parallel port?

Thanks.

The reason for a driver is that there already *is* a driver for the actuator, which needs to talk to a parallel port.  So either that driver is to be re-written, which could be tricky, or we just have it connect to the to-be-written virtual parallel port.

You might want to take your points back, as you just mentioned a critical piece of information - that you already had a driver writing to i/o ports that you hoped to reuse.

I didn't know you already had a driver that expects to talk to an i/o port. Is it actually making inb and outb calls to a specific io port?. If you hope to intercept those bytes as they are written to the port, that's probably not going to happen (at least, I can't think of how you could do that in a driver).  You are going to have to rewrite the driver.  If by chance the driver makes calls to /dev/port (which I doubt; in that case you would not even need a driver) you could possibly write a /dev/port substitute that intercepted the calls.  

If the driver is doing inb, outb calls, to make the rewriting of the driver as painless as possible, what you could do is write a substitute  function with similar parameters to inb, outb and such calls that sent the data over Ethernet via socket calls as described above.  This function could live in a separate driver that exposed these functions to your existing driver, and took care of the Ethernet stuff, the serial port switch management, etc.  But this will require some rewriting of your existing driver.

I should note that, within a device driver, you don't actually make calls to the socket interface, as is in the C library, but the kernel has similar routines some of which are defined in linux/net/socket.c; take a look  there for details of making ethernet connections in a driver.

When I program for the parallel port in windows, there are several possible addresses for the parallel port.  I would hope the driver for the actuator lets the programmer choose the port it connects to.  Thus, would it not be simple to have an address that points to a virtual port, and tell the driver for the actuator to use that address?  I am only arguing logically -- I do not know if either Linux or Windows supports this.

Yes, there are several different devices representing parallel ports that you write to - LPT1, LPT2, etc.  As long as your software writes to this device, the device driver is able to intercept them and redirect to various physical IO ports available to the processor.  But your situation is (I think) different.  Your /dev/actuator0 writes to an actual physical IO port, so in order to send the data out over a socket, you're going to have to rewrite the driver to not do inb(), outb() calls, but instead to call other functions that open a socket, add whatever addressing data the serial port box needs, and send the data out the Ethernet port.  There's no way I know of to intercept writes to an actual IO port in Linux unless you are working within a virtual machine (like dosemu, wine, or vmware).  So the existing device driver will have to be rewritten.  If you want to keep the rewriting to the minimum, you can write another module that exports the functions that replace inb, outb, so the existing driver is minimally modified and the other module/driver does the actual ethernet/serial stuff.  You also should know that you can't use the socket functions directly as they are in the C library, but the kernel exports other functions that do the same thing  - look in linux/socket.h for the actual calls, and the source of khttpd in the kernel files will tell you a lot about how to do sockets within the kernel.