Re: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

> >>>>+What:		/sys/class/leds/<led>/available_sync_leds
> >>>>+Date:		February 2015
> >>>>+KernelVersion:	3.20
> >>>>+Contact:	Jacek Anaszewski <j.anaszewski@xxxxxxxxxxx>
> >>>>+Description:	read/write
> >>>>+		Space separated list of LEDs available for flash strobe
> >>>>+		synchronization, displayed in the format:
> >>>>+
> >>>>+		led1_id.led1_name led2_id.led2_name led3_id.led3_name etc.
> >>>
> >>>Multiple values per file, with all the problems we had in /proc. I
> >>>assume led_id is an integer? What prevents space or dot in led name?
> >>
> >>Very good point. How about using a newline instead? That'd be a little bit
> >>easier to parse, too.
> >
> >No, please make it one value per-file, which is what sysfs requires.
> 
> The purpose of this attribute is only to provide an information about
> the range of valid identifiers that can be written to the
> flash_sync_strobe attribute. Wouldn't splitting this to many attributes
> be an unnecessary inflation of sysfs files?

No, it would not. It is required so that we don't end up with broken
parsers.
 
> Apart from it, we have also flash_faults attribute, that currently
> provides a space separated list of flash faults that have occurred.
> If we are to stick tightly to the one-value-per-file rule, then how
> we should approach flash_faults case? Should the separate file be
> dynamically created for each reported fault?

I think you can get away with flash_faults attribute (since the
strings are hardcoded).

Dynamically created files would be extremely ugly interface, but you
could also have files such as "overvoltage_fault" containing either 0
or 1 ...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux