Hi All,

I have done a small amount of searching for the answer to this question, but being a Linux noob, I still haven't learned all the places to look for answers, so sorry if this sounds like a stoopid question.

I have a program that runs on Linux. It communicates with a modem via USB. The modem has a limited number of endpoints, so we've implemented a mux protocol over one of the endpoints that allows us to do a bunch of extra stuff that would normally require its own /dev/tty. On Windows, our driver is pretty good and can demux this traffic and present it to the rest of Windows as virtual COM ports.

We'd like to accomplish the same kind of thing with our Linux code; accept this mux protocol data into a user-mode application, have that application demux each of the virtual COM ports and expose them to the rest of the Linux system as /dev/ttyXXXs.

Seems to me it would be relatively straightforward if we did the whole thing in the USB driver, but we'd prefer to do it in user space. Can anyone point me in the right direction for where to learn how to do this, assuming its even possible?

Regards

peatmoss

Sounds like you want libusb.

Before udev, which creates nodes in /dev on the fly, it used to be the case the these special files would be created by the utility mknod. However, just making a device node is one thing - having a working driver is another.

I'm not a kernel hacker, and I've never written a device driver. However, I did find this book which looks like it has some useful information about USB in chapter 13. I hope that helps.

Is it the character device or the terminal emulation you require? If you create a pseudo-terminal from user-space then your program will still need to be able to interface with the device on its own.
ta0kira

Hi Everyone,

Thanks for your replies they have been helpful. Going the device driver route is tempting, but also likely to consume a lot of time. At this point we're looking for a user-mode solution that could be robust but easier to code. So the mknod suggestion seems to come the closest to meeting our requirements. I've done a small amount of reading about it and it looks promising for our needs.

In fact, it reminds of me good old Beej's IPC page, something I read about several months ago, but didn't make the connection until now.

It remains to research exactly what kinds of things can be done via the system calls to a node we've created with mknod(), but at the very least as long as we can send/receive binary data between two processes, it should solve the problem quite nicely.

Regards!!

/Peatmoss

Or look at openpty and forkpty.
ta0kira

Another easy solution to consider might be "mkfifo" (nee "mknod -p"). It creates a named pipe for two or more processes to communicate with each other). I'm sure you already noticed this on Beej's page; here's another link:

http://www.linuxjournal.com/article/2156

A few days ago I would have said "no", but while checking to make sure I was right I ran across this:

http://kerneltrap.org/mailarchive/li...ad#mid-3116524

So the answer is now "yes" - if you have that patch.

UNIX sockets would have worked well for what you describe; unfortunately you need socket code rather than plain "fopen" to deal with UNIX sockets. Character devices are best; they can support read, write, asynchronous/non-blocking r/w, multiple opens, ioctls, and so on.

FIFOs would be useful as already suggested, BUT each time you attempt to write to the FIFO and no process has opened it for reading, you will get SIGPIPE (not to mention the numerous other return values indicating that things are not ready yet). So that gets kind of messy. With a character device on the other hand, you know how many processes have it open and you don't really write unless a read was requested. The only problem with the character device solution: it takes some work.