• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 865 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How do I access my Linux drivers (kernel space) from application level (user space)?

Juan Gonzales
Mastermind 37340 points

There are 5 application level system calls normally supported by Linux character-type drivers (bulk of Linux drivers, e.g. V4L2 video driver)

open, close, read, write, ioctl

The first four are pretty self-explanatory, but the last one is of particular interest since the ioctl function is used is to send request (known as IOCTLs or IO control requests) from the application to the driver.  Each Linux driver standard (V4L2, FBDev, ALSA, OSS,...) defines a corresponding set of standardized IOCTLs which the drivers conforming to those standards support; thereby allowing portability of application from one platform to the next. 

In a typical scenario, an application would first call open to get handle to the device drive, then issue a few ioctl calls to configure device (get capabilities, set desired video frame size...) and spend the bulk of its time issuing read, write, and ioctl requests; finally, it would issue a close to release the driver handle before exiting.

 

  • 0
    Intellectual 375 points

    Is there a standard method for a user space application to be notified when the kernel receives an interrupt from a device?  For example, whenever a device external to the DaVinci communicates with it via UART or SPI, I would like my application to be notified so that it can handle the incoming message as soon as possible.

  • 0 in reply to SJackson
    TI__Mastermind 37340 points

    SJackson,

    My first thought was that there should be a clean way to register a user-level callback with a driver (available in many operating systems); however, after doing a little digging I have not been able to find any documentation to this effect. 

    It appears there are mechanisms to communicate events up to user level via udev (sysfs and hotplug); I have also read suggestions that a callback type architecture could be implemented using 'signals' or 'pipes'. 

    For the most part though, I find that user applications 1) Either poll driver using ioctl, or 2) make blocking call on driver ioctl which return once interrupt is received.

  • 0 in reply to SJackson
    TI__Mastermind 37340 points

    One more thing...

     A very good resource for learning about the Linux driver model is the Linux Device Driver book from O'Reilly available for free at the following link

     http://lwn.net/Kernel/LDD3/

     

  • 0 in reply to Juan Gonzales
    Intellectual 380 points

    Juan Gonzales said:
    For the most part though, I find that user applications 1) Either poll driver using ioctl, or 2) make blocking call on driver ioctl which return once interrupt is received.

    Polling interrupt flag via ioctl sounds straight forward vs implementing an event comm link via sysfs/hotplug or any of the other suggested methods.  What are the implications for implementing my interrupt service routine with this method (ioctl poll)?  I'm thinking I can dedicate a thread to this ioctl interrupt polling driver and continue working on my other threads, however I'm worried about the delay this type of interrupt event communication will introduce.  I'm also unsure about the consequences this blocking call can  have on my implementation design.  Since, this will be my first multi-threaded design, can someone explain what negative effect this blocking ioctl call can have on my design?