[uClinux-dev] Re: question about Interrupt handler

Greg Ungerer gerg at snapgear.com
Mon Nov 26 19:47:50 EST 2001


Hi David,

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 ).

That is right. And the kernel has support functions to 
accomplish this, for example:

    copy_to_user()     (memcpy_tofs in 2.0.x)
    copy_from_user()   (memcpy_fromfs in 2.0.x)
    get_user()
    put_user()

It is good practice to use these. This is really important
in VM systems, where user application pages can be paged
to swap. In uClinux these functions are direct copies to
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 )

There is no FIFO device here. This transfer is at a more
fundamental level than a device. You need this to implement
devices.


> e.g.
> 
> buffer = malloc(MY_BUFFER_SIZE);
> ioctl( blahblahhandle , THISBUFFER , &(buffer) );

I hope that buffer is not a variable on the stack!
It had better be global :-)


> 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
> else store_data

I don't disagree that this could be made to work.

But why not get the driver to allocate (use kmalloc) and 
keep the interface clean?  

The app still needs someway to determine when the data is
there or not there. At least a clean driver/buffer interface
gives you this synchronization as well.



> 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.

Mostly not true :-)
Most drivers are very portable. I use many standard Linux
device drivers with very little change under uClinux on
non-x86 cpus. Drivers, for the most part, are surprisingly
portable. Out of the many dozens of devices drivers I have
gotten going on uClinux I have not had to rewrite one due
to the change in architecture. The architectural differences
of addressing and interrupts can almost always be handled
with no more than a few lines of code.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear                                       PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/



More information about the uClinux-dev mailing list