0

I have a userspace application which interacts with a kernel-space driver in a Linux environment. The driver, in this case, is an LED driver. In typical *nix fashion, the driver exposes a file in /sys/class/leds/actled1:green/ called value. When the value of value exceeds a threshold, the LED turns on.

So, my question is, what is the best-practice way of updating value from user-space in C?

My current approach is to simply write to the file, with a hardcoded filepath:

int value = 0;
FILE *fp;

/* update value here... */

fp = fopen("/sys/class/leds/actled1:green/value", "w");
if(fp != NULL) fprintf(fp, "%d", value);
fclose(fp);

Is there a better way to do this? It seems that there should be a standard POSIX C api for this, perhaps one that allows for driver lookup (so that I don't need to hard-code the filepath).

  • 3
    How userland applications communicate with kernel-level drivers is inherently OS dependent, as each OS has its own conventions. – Bart van Ingen Schenau Oct 27 '15 at 19:53
  • @BartvanIngenSchenau okay, that makes sense and comes as no surprise. but still, is there an API so i'm not writing to a hard-coded filepath? (i also realize i could write my own logic to avoid hard-coding the path, i just want to be sure i'm not reinventing the wheel). – Woodrow Barlow Oct 27 '15 at 20:05
  • Is the file name value, or is it really brightness? – Craig McQueen Jun 2 '16 at 1:56
  • @CraigMcQueen in my case, there was a value which indicates the amount of activity on the peripheral being monitored as well as a brightness which indicates whether the LED is on. brightness changed from 0 to 255 when value reached a certain threshold. – Woodrow Barlow Jun 2 '16 at 15:58
  • @WoodrowBarlow It sounds as though the LED might be configured to use a custom LED trigger, which creates the extra value attribute. cat trigger to see what trigger is in use. – Craig McQueen Jun 3 '16 at 1:23
1

There are lots of Linux kernel APIs. E.g. to name a few:

  • system calls
  • char and block devices (under /dev/)
    • write and read data
    • call ioctl() on the open device
  • netlink sockets
  • sysfs
  • procfs
  • configfs

Sometimes objectives determine the suitable API to use. Sometimes it's a bit arbitrary which one to pick. At some point an API was picked by one or more developers who created the API (probably after some discussion on Linux kernel mailing lists).

In the case of Linux kernel LEDs, /sys/class/leds/ in the sysfs filesystem is the API for userspace applications to control LEDs. So your app will control LEDs by writing to a file in sysfs.

I just recommend you make the LED's name configurable in your application. You could just make the name configurable (e.g. actled1:green), or you could make the entire path configurable (e.g. /sys/class/leds/actled1:green/brightness). That might allow the option of using some sort of userspace pseudo-LED API (e.g. a userspace app that controls LEDs over a network connection, providing a pseudo-LED API under /var/run/led-net/actled1:green/brightness).

  • sysfs was definitely the way to go on linux for this scenario. – Woodrow Barlow Jun 2 '16 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.