> Hi,
Hi Mark,
>
> On Mon, 14 Apr 1997, Claus Schroeter wrote:
> > is there a simple way to call an user-level funktion from kernel space
> > or at least let the process notify that a driver completed a task.
>
> Not 100% sure why you would want to do this, but as far as I know there is
> no safe way (at the moment). Even calling send_sig() from a drivers
> interrupt routine is unhealthy.
Yes, you got exactly the problem. A normal task for a driver is to lets
do a job by the hardware and notify its completion by an interrupt handler.
For example if I implement a timer handler that issues timeouts the user
process has to be notified about this, but calling send_sig() will be ignored
until a rescheduling is done so this will not help. sometimes it is also
necessary to flush a hardware buffer when a 'upper watermark' interrupt
occurs. in this case it may also be useful if the user process is notified
about this. shure normally the classical unix interface will be
sufficient for this but if I want to use special hardware (measurement
cards for example) the UNIX interface is too slow for this.
Imagine a memory mapped DMA buffer an user process can read and write to
and isssue commands to the driver to fill or flush the buffer.
If you want a continuous data stream to be processed you will get in trouble
very fast if signalling is used.
>
> > I think
> > the IPC message approach, kerneld uses will be a good solution,
> > but it seems that it is not possible to register a message interface
> > with the kernel dynamically.
>
> Correct. There is no generic kernel->user message channel (as opposed to
> user->kernel->user).
> Implementing such a channel would be useful. I was looking at file
> watchdogs yesterday (sending a message to a register task when another
> task performs some operation on a watched file, such as opening or
> writing), which would also needed a kernel->user channel.
> If you want to implement the channel, I'd be v. happy :), but it making it
> "called from interrupt" safe would be over-kill for most uses.
I think implementing a kernel->user channel would be a really good thing.
(Lets think about it :-) )
> Adding a info device node for a driver is possible. Basically, you hide
> another driver along side your driver (add an extra file_operations
> structure with an open, release and read routines).
> When a task reads from your info-driver device node (say
> /dev/mydriver-info), you copy data into the users read buffer. It's easy
> to make the info-read routine block until an event occurs in your
> real-driver (this is useful in debugging).
Yes I know this method from the realtime clock driver, is this interrupt
safe ?
However,
thanks for your ideas
cheers
clausi
-----------------------------------------------------------
Who is General Failure and why he's reading my harddisk ?