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 ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
