Re: modem control line checking - is polling the only way?

2000-05-17 Thread Craig Schlenter
On Wed, May 17, 2000 at 02:49:09PM -0400, Theodore Y. Ts'o wrote: [SNIP] > Is the linux-serial archived anywhere? It seems just last week I > answered the question about using TIOCMIWAIT to allow you a process to > sleep until a specified set of control lines change. Unfortunately, I > can't fin

Re: modem control line checking - is polling the only way?

2000-05-17 Thread Vern Hoxie
On Wed, 17 May 2000, Theodore Y. Ts'o wrote: > Is the linux-serial archived anywhere? It seems just last week I > answered the question about using TIOCMIWAIT to allow you a process > to sleep until a specified set of control lines change. > Unfortunately, I can't find my posting on the subject,

Re: modem control line checking - is polling the only way?

2000-05-17 Thread Theodore Y. Ts'o
Date:Wed, 17 May 2000 12:13:01 +0200 From: Craig Schlenter <[EMAIL PROTECTED]> Entirely correct AFAIK. I don't have seriously hard deadlines to meet timing-wise in my software so I don't need RTLinux. My objection to polling is that it's not an elegant way to solve the pro

Re: modem control line checking - is polling the only way?

2000-05-17 Thread Craig Schlenter
On Wed, May 17, 2000 at 07:28:32AM -0700, Tom Glass wrote: > What kind of time resolution are you needing? I have an application > that monitors one serial port for incoming messages in an infinite > loop. For some of the messages I initiate a child process that > communicates with a robot, volt

Re: modem control line checking - is polling the only way?

2000-05-17 Thread Tom Glass
What kind of time resolution are you needing? I have an application that monitors one serial port for incoming messages in an infinite loop. For some of the messages I initiate a child process that communicates with a robot, voltmeter, and other hardware on two other serial ports. The parent pr

Re: modem control line checking - is polling the only way?

2000-05-17 Thread Craig Schlenter
On Wed, May 17, 2000 at 01:15:07PM -0700, Michael Harig wrote: [snip] > real-time or not, RTLinux may give you the capability to avoid this. my > objection is, that linux kernel really should be able to schedule & notify > a process in about 1 ms if a IRQ occured and the process demanded the > not

Re: modem control line checking - is polling the only way?

2000-05-17 Thread Michael Harig
-- Craig Schlenter schrieb über modem control line checking - is polling the only way? > I don't have seriously hard deadlines to > meet timing-wise in my software so I don't need RTLinux. My objection > to polling is that it's not an elegant way to solve the problem of > detecting a change in the

Re: modem control line checking - is polling the only way?

2000-05-17 Thread Craig Schlenter
On Wed, May 17, 2000 at 04:16:24AM -0400, [EMAIL PROTECTED] wrote: > Well, at a guess, you can wait for me to do a courtesy-call capable > kernel, which may be a while, and a good while more for it to be > accepted, or you can do it yourself, or you can solve the problem in a > totally unexpected

Re: modem control line checking - is polling the only way?

2000-05-17 Thread Craig Schlenter
On Wed, May 17, 2000 at 10:52:04AM -0700, Michael Harig wrote: > Craig, > > remember that Linux is a multitasking kernel with no (generic) real time > capabilities. Your process frequently gets interrupted for an unspecified > amount of time. If a (serial) IRQ occurs then, the signal has to be me

Re: modem control line checking - is polling the only way?

2000-05-17 Thread Michael Harig
Craig, remember that Linux is a multitasking kernel with no (generic) real time capabilities. Your process frequently gets interrupted for an unspecified amount of time. If a (serial) IRQ occurs then, the signal has to be memorized and your process gets aware of it when scheduled the next time. N

Re: modem control line checking - is polling the only way?

2000-05-17 Thread Craig Schlenter
On Tue, May 16, 2000 at 04:06:50PM -0400, [EMAIL PROTECTED] wrote: > It is a pity you couldn't be bothered to read linux-serial. It is not a > terribly busy list, but this very question has been asked and answered > in the last week. Maybe you can find some list archives somewhere. It's not a q