2002-08-12 15:36:43

by daniel sheltraw

[permalink] [raw]
Subject: kernel to user-space communication

Hello Kernel

Is there a way to comminicate to a user-space program that an
interrupt has occurred in a kernel module?

Thanks,
Daniel Sheltraw


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx


2002-08-12 15:48:00

by Jan Hudec

[permalink] [raw]
Subject: Re: kernel to user-space communication

On Mon, Aug 12, 2002 at 10:40:27AM -0500, daniel sheltraw wrote:
> Is there a way to comminicate to a user-space program that an
> interrupt has occurred in a kernel module?

You can send a signal or you can create a device for a process to wait
on in poll or blocking read. Signals have quite high overhead because of
the need to save state, so device will be faster (it's faster even if
the process shoul clone a thread to handle it).

-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[email protected]>

2002-08-12 15:57:54

by Richard B. Johnson

[permalink] [raw]
Subject: Re: kernel to user-space communication

On Mon, 12 Aug 2002, daniel sheltraw wrote:

> Hello Kernel
>
> Is there a way to comminicate to a user-space program that an
> interrupt has occurred in a kernel module?
>
> Thanks,
> Daniel Sheltraw

Yes, poll() or select(). Look at some character drivers in the kernel.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

2002-08-12 17:49:05

by Woodruff, Robert J

[permalink] [raw]
Subject: RE: kernel to user-space communication

There are a couple of techniques one can use.
First, you can set up a piece of memory that is shared
between the kernel and the user process and when the
interrupt occurs, set a flag in memory. The user process
can poll the memory to see if an interrupt happened.

Coarse, you might not want to waist CPU polling all day,
so you could use signals (like SIGUSR1) to block, and have the
kernel send the signal when the interrupt occurs. Only problem
with signals is that they are not stackable.

Another technique is to implement the concept of a wait object,
you write a simple driver that manages these. The user process
does an ioctl to the wait object driver when it wants to wait for
an interrupt. The ioctl sleeps if the interrupt has not occurred.
The kernel then calls wakeup when the interrupt
happens and the ioctl completes.
We implemented a mechanism like this for InfiniBand,
which allows user level I/O to the hardware and we needed a way to
signal I/O completions (interrupts) to the user process.
If you are interested
in an example, take a look at the early reference InfiniBand code
at http://sourceforge.net/projects/infiniband.

-----Original Message-----
From: daniel sheltraw [mailto:[email protected]]
Sent: Monday, August 12, 2002 8:40 AM
To: [email protected]
Subject: kernel to user-space communication


Hello Kernel

Is there a way to comminicate to a user-space program that an
interrupt has occurred in a kernel module?

Thanks,
Daniel Sheltraw


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx

2002-08-13 07:21:25

by Jan Hudec

[permalink] [raw]
Subject: Re: kernel to user-space communication

On Mon, Aug 12, 2002 at 10:52:45AM -0700, Woodruff, Robert J wrote:
> There are a couple of techniques one can use.
> First, you can set up a piece of memory that is shared
> between the kernel and the user process and when the
> interrupt occurs, set a flag in memory. The user process
> can poll the memory to see if an interrupt happened.
>
> Coarse, you might not want to waist CPU polling all day,
> so you could use signals (like SIGUSR1) to block, and have the
> kernel send the signal when the interrupt occurs. Only problem
> with signals is that they are not stackable.

You don't waste CPU polling all day! The name 'poll' seems to imply
that, but it does not use CPU wile waiting (what it does is looks if
event is already pending and add current to wait queue on each
descriptor - the function that makes data available then wakes it up).
And it's a whole lot faster than signals. Signal setup is slower than
context switch.

> Another technique is to implement the concept of a wait object,
> you write a simple driver that manages these. The user process
> does an ioctl to the wait object driver when it wants to wait for
> an interrupt. The ioctl sleeps if the interrupt has not occurred.
> The kernel then calls wakeup when the interrupt
> happens and the ioctl completes.
> We implemented a mechanism like this for InfiniBand,
> which allows user level I/O to the hardware and we needed a way to
> signal I/O completions (interrupts) to the user process.
> If you are interested
> in an example, take a look at the early reference InfiniBand code
> at http://sourceforge.net/projects/infiniband.

Which is _exactly_ what poll does, just more work! (because you have to
write things poll_wait would do for you and you have to be very
careful).

-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[email protected]>