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.aeschlimann@xxxxxxxxxxxx
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
