On Tue, Aug 24, 2010 at 11:52:07AM +0200, Christophe Aeschlimann wrote: > Hi, > > I'm implementing a user-space API that will give access to > custom hardware features through sysfs. This library is here > to hide the sysfs specifics. Ick, don't. What's wrong with the existing sysfs interfaces we have today, open(), read(), close()? And what type of hardware features are you wanting to export through sysfs? Why sysfs? > This library must support multi-threaded accesses. sysfs handles that just fine. > I would like to know if something special must be done in > this library to assure concurrent accesses. > > Here is an example : > > I want the users of my library to be able to switch-on/-off a LED using > a simple function like the following : > > platform_led_on(0); //switches on led '0' > platform_led_off(0); //switches on led '0' > > This led is declared in my platform_data in the board init file as a > gpio_led and can be seen in sysfs under /sys/class/leds/led0 > > the platform_led_on/off(0) functions will : > > - build the sysfs path to the led0 based on the argument (0) > - open the brightness file in the sysfs path > - write to the brightness file a value != 0 to switch the led on or 0 to switch it off > - close the brightness file > - return > > Now what will happen if a thread tries to switch on the led while another > thread tries to switch it off ? Who ever writes to the file first will cause their action to happen, followed by the action of the second process/thread. If you need locking, do it in your library, but again, this really looks like overkill, why do you need to do all of this? Oh, and you have looked at libudev, right? thanks, greg k-h -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
