linux-kernel - Re: [PATCH v3] leds: Introduce userspace leds driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Fri, 9 Sep 2016 15:44:34 -0500
From:   David Lechner <david@...hnology.com>
To:     Kelly French <kfrench@...eralhill.net>
Cc:     linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jacek Anaszewski <j.anaszewski@...sung.com>
Subject: Re: [PATCH v3] leds: Introduce userspace leds driver

On 09/09/2016 02:30 PM, Kelly French wrote:
>
> Replying privately, as I'm not involved in the kernel community.
>

By offering your opinion, you are now involved in the community. No need 
to be shy. :-)

> I'm looking forward to this functionality.  I'm a little worried about
> the interface.  Is it possible to create the new uled devices in some
> other way?
>
> Maybe one insmod per uled device?  Maybe a new /proc/ entry (yuck) where
> you can echo the name into it, which will trigger udev to create the
> appropraite /dev/uled-name device?
>
> I'm hoping that the final interface is something I can just "cat
> /dev/uled-name" instead of having to write a binary struct into it at
> the beginning.  I'm even ok with just echoing text into the dev entry
> before reading.  It's the binary struct that's bugging me.
>

I originally considered using configfs to setup new LEDs[1], which would 
be very much like what you are suggesting, but I find the way my current 
patch works to be much simpler.

With this patch, you can create multiple LEDs. You just have to open a 
file handle to /dev/uleds for each LED that you want to create. Also, 
the LED device is automatically destroyed when the file handle is 
closed. I think this is nice because if the program that created it 
crashes, then it is automatically cleaned up.

I agree it would be much more convenient to not use a binary struct, but 
I think the complexity of implementing it outweighs any benefit to be 
gained. And it is easy enough to use an interactive python shell to 
handle the things that bash can't if the interactive part is what you 
really want.

[1]: https://lkml.org/lkml/2016/7/25/505