Hi All

I'm new to Linux/Unix programming, but have a background in embedded programming. Most recently we've been using Mentor's Nucleus as the kernel. As some of you may know, embedded devices with Nucleus-like kernels (by which I mean non-Linux kernels) and no "users" per se, are different beasts compared to a Linux-like system where applications are usually in User mode. In systems like this, Interrupt Service Routines (ISRs) trigger off a task (i.e a process or thread) when something noteworthy occurs, saving the task and the CPU the bother of polling the device. Polling is a valid method too under certain circumstances, but in our next application, interrupts will be fine.

My question is, what mechanism exists in Linux so that my process (or thread) doesn't have to poll a serial file handle to see when data arrives? We'd prefer to have a blocking system call which will unblock the proc/thread when data arrives - specifically on a serial port.

I'm aware of the "select()" system call, but if there are other options I don't know what they are. If anyone knows of such a beast(s), I'd appreciate a pointer to somewhere I could read about it.

Regards

Peatmoss/Alleria

Not sure if this helps, but a Serial port raises an Interrupt to inform the CPU that it has something to do, maybe you can plug into this mechanism.

If you do find a answer please post - I had the same question a while back and didn't really get a difinative response.

Hi Harry,

Thanks for the reply. I should have been a little clearer in my original post. I think what you say is true, provided that I'm willing to modify the kernel by adding my own driver code. But there is no need for me to do this since the standard USB driver will do just fine. And as far as I understand it, the kernel is the only part of a Linux system that can receive and process interrupts. Since our "application" will be running in User Mode, then we must rely on a mechanism similar to the Select() call. To the User Mode application, a piece of hardware will have a Linux file handle in /dev and we will need to block our process/thread waiting for traffic to appear on that device. As I said above, polling is overkill and would not an efficient use of the CPU.

Regards

Peatmoss/Alleria

Perhaps I'm missing something obvious here, but wouldn't a normal read give you what you're looking for as long as you opened the tty without the non-blocking flag.

Judy

Hi Judy,

What I was looking for in my original question was a list of alternatives to the "select()" call. I wasn't aware that "read()" would block the caller. I've just taken a look at the man pages for it and the ones I've seen don't come right out and mention blocking. So far, "select()" is the call of choice.

The reason I'm asking this question is because I've noticed in Linux there are usually several ways to accomplish a goal; look at the different methods for Inter Process Communications, for instance, there are many.

Peatmoss

I haven't tried it myself, but when I looked at all the linux examples that opened and read a tty, they all specified non-blocking in the open call. That implies to me that if non-blocking is not specified, then the read call would block. I'd give it a try in actual code. I'd wager (a small sum) that it blocks.

Not just on linux - IPC has so many different ways depending on the fine details of what you're doing. I've got a single system (cross-platform on windows and linux) that uses 3 different mechanisms.

Judy

you can have asynchronous IO with signals,
the stevens book doesn't recommend it though


man aio on solaris

I found this:
http://www.atnf.csiro.au/people/rgoo...io-events.html