Thread: user space control for device driver

  1. #1
    Registered User
    Join Date
    Jan 2010
    Posts
    7

    user space control for device driver

    Hello,

    I'm currently learning how device drivers are written for Linux (and have to write one shortly). From what i understand, the final control provided to user space for accessing the driver functions is via a device file and system calls.

    Now i've seen that the drivers use a variety of interfaces for this file- viz /dev entries, procfs entries, sysfs entries and debugfs entries.Which would be the right choice for a GPIO driver? Assuming i have 32 GPIO ports which i want to access, making a /dev entry for each port does not seem a good idea.What interface type would be ideal?

  2. #2
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    The /dev file provides access to the driver -- anything written to it is processed by the driver, and (presumably) delivered to the device.

    So if you can structure the driver to interpret the input correctly, then you can select ports that way and just use the one /dev file.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  3. #3
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065
    If I were writing a GPIO driver, I would allow the user to echo commands to the device node. For example, if the user wants to create some as INPUT some as OUTPUT I would allow the following string:

    echo "C0x4821f103M0x7ff2f10f" > /dev/gpio

    Which would mean: (C)onfigure the bits represented by (M)ask 0x7ff2f10f with the configuration of ON being input, OFF being output. Therefore, the driver would know to adjust the input/output mask of the GPIO pin IFF the mask value is set. -- Make sense?

    Likewise a read would have a command:
    echo "R0x0000000f" /dev/gpio
    cat /dev/gpio
    To indicate Read for me ONLY the last 4 bits of the GPIO and would return something like:
    0x00000006
    to the user.

    This would GREATLY simplify your work (as you don't have to do any of the ioctl() subsystem calls) and it makes it so that you can access the GPIO from the command line -- which is often times VERY helpful.

    0.02 USD.

  4. #4
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Kennedy makes a good point about ease of implementation and use, but it's not a very traditional way to go about it. Usually, device commands are implemented by ioctl() calls, and reads/writes to the device are used to transfer raw data after the device has been configured in some way.

    Specially formatted string input/output is the kind of thing you usually find in /proc nodes.

    I realize that implementing ioctl()'s can be painful and boring, but it's the usual way.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  5. #5
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by brewbuck View Post
    I realize that implementing ioctl()'s can be painful and boring, but it's the usual way.
    Please tell me that is not a justification...
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #6
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065
    I guess I would have to argue that point, as for GPIO there is normally no "usual" driver at all (1). Most of the controls I've seen for GPIO are in the form of highly complicated user-space apps that directly access memory via mem-mapping /dev/mem.

    Nothing says that one cannot make the driver answer the call for ioctl(), but how many folks would ****WANT**** to have to access the GPIO from ioctl()?

    Many of the GPIO lines I've used have been for controlling the LEDs provided with the board -- and that's about all. For any of the other functions that GPIO controls, one probably won't be looking at controlling individual lines, but alternate functions of the processor.

    (1) this is certainly true for the Gumstix I've used and the 20-30 boards I've used from about 6-8 different companies (of which I can only recall the name of a couple, which were merged into one: Eurotech). Not a WIDE variety, but not a few either.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. (Multiline) Edit Control Limit
    By P4R4N01D in forum Windows Programming
    Replies: 9
    Last Post: 05-17-2008, 11:56 AM
  2. Contest Results - May 27, 2002
    By ygfperson in forum A Brief History of Cprogramming.com
    Replies: 18
    Last Post: 06-18-2002, 01:27 PM
  3. Tab Controls - API
    By -KEN- in forum Windows Programming
    Replies: 7
    Last Post: 06-02-2002, 09:44 AM
  4. Updating Static Control Color Real-Time :: MFC
    By kuphryn in forum Windows Programming
    Replies: 2
    Last Post: 05-29-2002, 03:09 PM
  5. Program Control Help
    By mattz in forum C Programming
    Replies: 2
    Last Post: 11-27-2001, 10:10 PM