[uClinux-dev] Re: question about Interrupt handler
david.anderson at dtrack.com
Mon Nov 26 08:37:41 EST 2001
It's an interesting thread..
surely, everything must ( eventually ) transfer data into userland, otherwise the application will not
be able to see the data ( particularily with virtual memory ).
I believe the 'transfer' is supposed to happen via a fifo device, but for uclinux, would it not be possible
for the driver to be allocated a buffer space via an application ioctl call ( invent one )
buffer = malloc(MY_BUFFER_SIZE);
ioctl( blahblahhandle , THISBUFFER , &(buffer) );
It is obvious to anyone reading the code , that the application has loaned the buffer to the device. If you
implement code in the driver to safely free() the buffer when the device is closed, then this should
be relatively safe against unexpected application process termination. The driver then just has to
not store data if the buffer pointer is null.
if data_received and buffer_is_null discard_data
The buffer pointer can be stored as part of the control structure of the device.
I would think this would be more reliable than just assuming the application space
still exists for the data.
the driver is likely to be architecture dependant anyway. If you port to a different architecture, then the driver
will be re-written. At least it keeps all the fuzzy bits in one place.
That's all I;ve got to add. ;-)
On 26 November 2001 12:48, Vladimir Vorobyov [SMTP:Vladimir.Vorobyov at iss.org.ua] wrote:
> > Vladimir Vorobyov wrote:
> > > Continuing Interrupt handlers topic I want to ask some questions:
> > > 1) I know that I can't transfer data to/from user space from interrupt
> > > handler and the best way to do it is to wake_up another part of driver
> > > (for example read function) and let it to perform transferring data from
> > > FIFO-buffer
> > > to user space. But 'woken_up' process can strart executing only after
> > > timer tick (is it correct ?),
> > No, not correct.
> > The code returning from an interrupt can cause a reschedule of tasks.
> > This can only occur if returning to user mode (in other words an
> > application was running). A schedule() call may cause your reading
> > app to run, it may not. Depends on what is running already, and
> > their relative priorities.
> > But the bottom line is that an interrupt can cause a task switch.
> > > in other words after <=10msec. For my task I
> > > have to
> > > read large amount of data from FIFO buffer rather fast and 10msec delay
> > > will dramatically decrease transfer speed. Could you give me an advise
> > > to solve this problem ?
> > You have to allow for reasonably large delays from the interrupt to when
> > you app runs. Normal Linux/uClinux gives you no guarantees. If this is
> > just read data why cannot the driver just keep buffering lots of data?
> > > 2) On the other hand, I work on the rocessor without MMU and
> > > transferring data to/from user space from interrupt handler works
> > > but
> > > is it correct to do it (write to user space directly)?
> > For sufficiently fuzzy values of correct :-)
> > Fundamentally it is a bad thing to do. What if the app dies for some
> > reason? The interrupt could be writing into someone else memory space.
> > What if one day you want to switch to a VM processor?
> OK, but if I need to perform asynchronous reading:
> Buffering data within driver will be useless.
> Writing from interrupt handler happens only after application has called
> read function.
> 1) application calls read
> 2) driver initializes reading sequence and returns
> 3) application does some computations
> 4) application polls driver (or calls IOCTL) to check for completion of data
> transfer and goes to 1)
> how can I avoid writing to user space ?
> Regards, Vladimir.
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
< mailto:david.anderson at dtrack.com >
Protect Your Environment
This message uses 100% recycled electrons
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please destroy
and notify Data Track Technology Plc +44 1425 271900.
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
More information about the uClinux-dev