device driver / char module interrupt vector -> user space code

device driver / char module interrupt vector -> user space code

[SA]

Dear Kernel List,

I am writing a char module for a PCI stage controller and want to add the 
following functionality; 

The device will generate an interrupt (or software trigger) and I want this to 
run a bit of user code with relatively latency.  (<1ms).  I am unclear how to
do this while still separating the user from the kernel code and maintaining
security - would this usually be handled by issuing a signal to the user space
process? if so how and what latency can I expect? 

Thanks matt


(more info: the stage controller moves little mechanical platforms in an 
experiment, as the platforms reach certain positions (determined by
the hardware or the driver) user code must be run to perform some
action (say take a measurement).  The stages move continuously so
timing errors map to positional errors.  I could do all this in kernel space
by linking the various drivers controlling the various hardware together
under a super-driver for the entire experiment, however, it would be
much nicer to achieve this with separate modules and user code). 

Re: device driver / char module interrupt vector -> user space code

[Alan Cox]

On Fri, 2002-08-09 at 09:49, SA wrote:
> I am writing a char module for a PCI stage controller and want to add the 
> following functionality; 
> 
> The device will generate an interrupt (or software trigger) and I want this to 
> run a bit of user code with relatively latency.  (<1ms).  I am unclear how to
> do this while still separating the user from the kernel code and maintaining
> security - would this usually be handled by issuing a signal to the user space
> process? if so how and what latency can I expect? 

You could deliver a signal, or if appropriate you can have a system call
that blocks until the IRQ. To get good reliable latency, mlockall() the 
process you need to be real time, and set it to a real time scheduling
priority.

Re: device driver / char module interrupt vector -> user space code

[Jan Hudec]

On Fri, Aug 09, 2002 at 11:34:00AM +0100, Alan Cox wrote:
> On Fri, 2002-08-09 at 09:49, SA wrote:
> > I am writing a char module for a PCI stage controller and want to add the 
> > following functionality; 
> > 
> > The device will generate an interrupt (or software trigger) and I want this to 
> > run a bit of user code with relatively latency.  (<1ms).  I am unclear how to
> > do this while still separating the user from the kernel code and maintaining
> > security - would this usually be handled by issuing a signal to the user space
> > process? if so how and what latency can I expect? 
> 
> You could deliver a signal, or if appropriate you can have a system call
> that blocks until the IRQ. To get good reliable latency, mlockall() the 
> process you need to be real time, and set it to a real time scheduling
> priority.

If you noticed the discussion about signal delivery and context switch
latency, a syscall (can be ioctl on special device) waiting for the
event would be faster than signal.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Re: device driver / char module interrupt vector -> user space code

[Gilad Ben-Yossef]

On Fri, 2002-08-09 at 13:34, Alan Cox wrote:
> On Fri, 2002-08-09 at 09:49, SA wrote:
> > I am writing a char module for a PCI stage controller and want to add the 
> > following functionality; 
> > 
> > The device will generate an interrupt (or software trigger) and I want this to 
> > run a bit of user code with relatively latency.  (<1ms).  I am unclear how to
> > do this while still separating the user from the kernel code and maintaining
> > security - would this usually be handled by issuing a signal to the user space
> > process? if so how and what latency can I expect? 
> 
> You could deliver a signal, or if appropriate you can have a system call
> that blocks until the IRQ. To get good reliable latency, mlockall() the 
> process you need to be real time, and set it to a real time scheduling
> priority.


To get <1ms latencies I suspect you will also need the preemtive kernel
and lock-break patches (http://www.tech9.net/rml/linux/) and if you're
running on an x86, changing the HZ value in linux/asm/param.h from 100
to 1000 will also be a good idea IMHO. 

Of course, this requires re-compiling and replacing the kernel which may
or may not be apropriate. AFAIK both the patches and the HZ value change
are already in the 2.5.x development kernels already, but not everyone
are running *that* version quite yet... :-D

Gilad.

-- 
Gilad Ben-Yossef <gilad@benyossef.com>
Code mangler, senior coffee drinker and VP SIGSEGV
Qlusters ltd.

"You got an EMP device in the server room? That is so cool."
      -- from a hackers-il thread on paranoia