Re: Concurrent accesses to sysfs
On 06.09.2010 15:59, Greg KH wrote:
On Mon, Sep 06, 2010 at 09:23:06AM +0200, Christophe Aeschlimann wrote:
On 04.09.2010 02:58, Greg KH wrote:
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?
Well we have to offer a board-support-package to a customer. When I told
them about sysfs to access LEDS / GPIOS they told me they wanted some layer
above that so they can just call a switch_led_on function and they
wouldn't have to know the way sysfs works. E.G. Know the sysfs path name,
attributes names and values to write to the attributes to control the device.
{sigh} Ok, then write a tiny shell script that does this :)
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.
What happens with the open() on sysfs pseudo files ?
The file descriptor is returned, what exactly are you worried about
here?
Can the file be opened twice ?
Yes, multiple times, try it.
Or does it requires a close first ?
Nope.
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?
Because it's a customer request :)
What type of locking are they asking for?
Is it possible to do the locking with the open() or flock() ? Or should I use
pthread mutex ?
open() isn't going to work.
flock() might, haven't tried it though.
a mutex would, if you are controling all access through your library.
But that's really overkill here, right?
Oh, and you have looked at libudev, right?
No I wasn't aware of that lib but I guess :
udev_device_get_sysattr_value ()
does the open/read/close for me in a thread-safe way ?
Again, what does thread-safe mean here?
The above call opens the file and reads the value and then closes the
file and returns the value to your program. If someone else went in and
wrote to the file right after reading to it, your read will be stale.
That makes it clear for me. Since I wasn't sure of the behaviour of open/close
(exclusive / non-exclusive) and read/write (atomic/non-atomic) I was getting
worried that it might not behave correctly.
Which is the same thing that would happen with your mutex lock as well,
right? You aren't going to ever be able to conclusivly say, Here is
the value, no one else has changed it.
Sure.
So again, I think you are over thinking this a lot. Just wrap up the
libudev call if you want, or just point your customer at libudev if they
are writing their own programs.
I think you got the point, I'm always over thinking :)
I will wrap the libudev call and everything is going to be fine.
Thanks for the help !
Regards,
Christophe
Or just write a simple shell script :)
good luck,
greg k-h
--
Christophe Aeschlimann
Embedded Software Engineer
Advanced Communications Networks S.A.
Rue du Puits-Godet 8a
2000 Neuchâtel, Switzerland
Tél. +41 32 724 74 31
c.aeschlim...@acn-group.ch
--
To unsubscribe from this list: send an email with
unsubscribe kernelnewbies to ecar...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Concurrent accesses to sysfs
Hi Greg, Thanks for taking the time to answer my email. On 04.09.2010 02:58, Greg KH wrote: 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? Well we have to offer a board-support-package to a customer. When I told them about sysfs to access LEDS / GPIOS they told me they wanted some layer above that so they can just call a switch_led_on function and they wouldn't have to know the way sysfs works. E.G. Know the sysfs path name, attributes names and values to write to the attributes to control the device. This library must support multi-threaded accesses. sysfs handles that just fine. Thanks for confirming that. 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. What happens with the open() on sysfs pseudo files ? Can the file be opened twice ? Or does it requires a close first ? 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? Because it's a customer request :) Is it possible to do the locking with the open() or flock() ? Or should I use pthread mutex ? Oh, and you have looked at libudev, right? No I wasn't aware of that lib but I guess : udev_device_get_sysattr_value () does the open/read/close for me in a thread-safe way ? thanks, greg k-h Thank you, Christophe -- Christophe Aeschlimann Embedded Software Engineer Advanced Communications Networks S.A. Rue du Puits-Godet 8a 2000 Neuchâtel, Switzerland Tél. +41 32 724 74 31 c.aeschlim...@acn-group.ch -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Concurrent accesses to sysfs
On Mon, Sep 06, 2010 at 09:23:06AM +0200, Christophe Aeschlimann wrote:
On 04.09.2010 02:58, Greg KH wrote:
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?
Well we have to offer a board-support-package to a customer. When I told
them about sysfs to access LEDS / GPIOS they told me they wanted some layer
above that so they can just call a switch_led_on function and they
wouldn't have to know the way sysfs works. E.G. Know the sysfs path name,
attributes names and values to write to the attributes to control the device.
{sigh} Ok, then write a tiny shell script that does this :)
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.
What happens with the open() on sysfs pseudo files ?
The file descriptor is returned, what exactly are you worried about
here?
Can the file be opened twice ?
Yes, multiple times, try it.
Or does it requires a close first ?
Nope.
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?
Because it's a customer request :)
What type of locking are they asking for?
Is it possible to do the locking with the open() or flock() ? Or should I use
pthread mutex ?
open() isn't going to work.
flock() might, haven't tried it though.
a mutex would, if you are controling all access through your library.
But that's really overkill here, right?
Oh, and you have looked at libudev, right?
No I wasn't aware of that lib but I guess :
udev_device_get_sysattr_value ()
does the open/read/close for me in a thread-safe way ?
Again, what does thread-safe mean here?
The above call opens the file and reads the value and then closes the
file and returns the value to your program. If someone else went in and
wrote to the file right after reading to it, your read will be stale.
Which is the same thing that would happen with your mutex lock as well,
right? You aren't going to ever be able to conclusivly say, Here is
the value, no one else has changed it.
So again, I think you are over thinking this a lot. Just wrap up the
libudev call if you want, or just point your customer at libudev if they
are writing their own programs.
Or just write a simple shell script :)
good luck,
greg k-h
--
To unsubscribe from this list: send an email with
unsubscribe kernelnewbies to ecar...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Concurrent accesses to sysfs
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 ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Concurrent accesses to sysfs
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. This library must support multi-threaded accesses. 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 ? Thank your for your comments / help. Best regards, -- Christophe Aeschlimann Embedded Software Engineer Advanced Communications Networks S.A. Rue du Puits-Godet 8a 2000 Neuchâtel, Switzerland Tél. +41 32 724 74 31 c.aeschlim...@acn-group.ch -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
