[uClinux-dev] Re: question about Interrupt handler

Tom Walsh tom at cyberiansoftware.com
Mon Nov 26 14:51:15 EST 2001

David Anderson wrote:
> 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 )
> e.g.
> buffer = malloc(MY_BUFFER_SIZE);
> ioctl( blahblahhandle , THISBUFFER , &(buffer) );

Yes, yes, yes... All this will work, you are correct, you *can* do this,
the question is *should* you do this?

Here is the scenario:

1.  App launches by the kernel allocating memory space for the
application to run in.

2.  App then allocs a buffer and reports its' address to the driver.

3.  App then crashes some time in the future and the kernel reclaims all
the memory used by the application and its' buffer(s).

4.  Another app forks, gets allocated this reclaimed memory space.

5.  Driver code is still writing into that dead-buffer address space the
crashed application no longer owns.

Guess what?  You will probably crash the entire uClinux system as:

A. you have no memory protection, programs can write anything /
anywhere, even into the memory space of the newly forked process.

B. the area the driver is now writing to probably contained executable
code for the fork'ed process, <BANG!>.

This is what Greg means when he says that 'yes, you can do this, but it
is dangerous' (SIC).

NOW that we have covered why it is dangerous for us to use user space
for our driver buffers, let's look at the strategy from another,
entirely different direction.  Why not have the user app make an IOCTL
call to the driver to open a buffer for the app.  The IOCTL uses the
kernel memory alloc system to alloc a buffer and the result of the IOCTL
call will be the address of the buffer space (that contains our data)
from the driver?!!  This way, the app has direct access to the buffer,
and the danger of a crash will not affect the system.

Sounds good, right?  AS LONG AS YOU ONLY USE UCLINUX!  One main
advantage to having an MMU is that it affords you very fine control over
ownership of block of alloacted memory.  As long as your product uses
uClinux, you are ok, remember, there is no MMU in uClinux.  But, should
your product expand its' needs and require a more powerful processor
(say an ARM9x0 series, or StrongARM), you are in serious trouble.  These
processors use an MMU + standard linux... ... The MMU will not allow the
user space application to access the buffer(s) of the driver!

This is what Greg means when he says that 'what happens if you switch to
a VM environment' (SIC).

As long as you + your company are fully aware of the limitations to the
strategies you employ in your product, then fine, you can use the IOCTL
returning a buffer address type of approach.  from my experience,
products always seem to be getting more functionality added, which
demands more MIPS to run them, ...

IMO, if you cannot use the strategy of a FIFO, or pulling the data out
of the driver in a "standard" way, then you need a more powerfull
processor for your design.  Your call..



Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

More information about the uClinux-dev mailing list