Request for Comment: LED device naming for netdev LEDs

Request for Comment: LED device naming for netdev LEDs

[Marek Behun]

Hi,

linux-leds is trying to create a consistent naming mechanism for LEDs
The schema is:
  device:color:function
for example
  system:green:power
  keyboard0:green:capslock

But we are not there yet.

LEDs are often dedicated to specific function by manufacturers, for
example there can be an icon or a text next to the LED on the case of a
router, indicating that the LED should blink on activity on a specific
ethernet port.

This can be specified in device tree via the trigger-sources property.

We therefore want to select the device part of the LED name to
correspond to the device it should trigger to according to the
manufacturer.

What I am wondering is how should we select a name for the device part
of the LED for network devices, when network namespaces are enabled.

a) We could just use the interface name (eth0:yellow:activity). The
   problem is what should happen when the interface is renamed, or
   moved to another network namespace.
   Pavel doesn't want to complicate the LED subsystem with LED device
   renaming, nor, I think, with namespace mechanism. I, for my part, am
   not opposed to LED renaming, but do not know what should happen when
   the interface is moved to another namespace.

b) We could use the device name, as in struct device *. But these names
   are often too long and may contain characters that we do not want in
   LED name (':', or '/', for example).

c) We could create a new naming mechanism, something like
   device_pretty_name(dev), which some classes may implement somehow.

What are your ideas about this problem?

Marek

Re: Request for Comment: LED device naming for netdev LEDs

[Andrew Lunn]

On Sun, Sep 27, 2020 at 12:40:25AM +0200, Marek Behun wrote:
> Hi,
> 
> linux-leds is trying to create a consistent naming mechanism for LEDs
> The schema is:
>   device:color:function
> for example
>   system:green:power
>   keyboard0:green:capslock
> 
> But we are not there yet.
> 
> LEDs are often dedicated to specific function by manufacturers, for
> example there can be an icon or a text next to the LED on the case of a
> router, indicating that the LED should blink on activity on a specific
> ethernet port.
> 
> This can be specified in device tree via the trigger-sources property.
> 
> We therefore want to select the device part of the LED name to
> correspond to the device it should trigger to according to the
> manufacturer.
> 
> What I am wondering is how should we select a name for the device part
> of the LED for network devices, when network namespaces are enabled.
> 
> a) We could just use the interface name (eth0:yellow:activity). The
>    problem is what should happen when the interface is renamed, or
>    moved to another network namespace.
>    Pavel doesn't want to complicate the LED subsystem with LED device
>    renaming, nor, I think, with namespace mechanism. I, for my part, am
>    not opposed to LED renaming, but do not know what should happen when
>    the interface is moved to another namespace.
> 
> b) We could use the device name, as in struct device *. But these names
>    are often too long and may contain characters that we do not want in
>    LED name (':', or '/', for example).
> 
> c) We could create a new naming mechanism, something like
>    device_pretty_name(dev), which some classes may implement somehow.
> 
> What are your ideas about this problem?

I lost track of where these file will appear. I was surprised with the
location in the first proposal

Looking at one of my systems we have:

ls -l /sys/class/net/eth0/
total 0
-r--r--r-- 1 root root 4096 Sep 26 14:34 addr_assign_type
-r--r--r-- 1 root root 4096 Sep 26 14:34 address
-r--r--r-- 1 root root 4096 Sep 26 19:06 addr_len
-r--r--r-- 1 root root 4096 Sep 26 19:06 broadcast
...
phydev -> ../../mdio_bus/400d0000.ethernet-1/400d0000.ethernet-1:00
...

Will the LED class directory appear as a subdirectory of
/sys/class/net/eth0/, or a subdirectory of
../../mdio_bus/400d0000.ethernet-1/400d0000.ethernet-1:00 or in
/sys/class/leds?

If they are in /sys/class/led, the name needs to be globally
unique. That rules out using the interface name, which is not globally
unique, it is only netns unique.

If they are inside /sys/class/net/eth0, we don't need to worry about
the name, we know which interface they belong to simply from the
parent directory. We can then use "phy:yellow:activity".

The same applies for
"../../mdio_bus/400d0000.ethernet-1/400d0000.ethernet-1:00". The user
can follow the symlink from /sys/class/net/eth0 to the phy directory
to find the LEDs for a PHY.

   Andrew

Re: Request for Comment: LED device naming for netdev LEDs

[Marek Behun]

On Sun, 27 Sep 2020 02:29:35 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> On Sun, Sep 27, 2020 at 12:40:25AM +0200, Marek Behun wrote:
> > Hi,
> > 
> > linux-leds is trying to create a consistent naming mechanism for LEDs
> > The schema is:
> >   device:color:function
> > for example
> >   system:green:power
> >   keyboard0:green:capslock
> > 
> > But we are not there yet.
> > 
> > LEDs are often dedicated to specific function by manufacturers, for
> > example there can be an icon or a text next to the LED on the case of a
> > router, indicating that the LED should blink on activity on a specific
> > ethernet port.
> > 
> > This can be specified in device tree via the trigger-sources property.
> > 
> > We therefore want to select the device part of the LED name to
> > correspond to the device it should trigger to according to the
> > manufacturer.
> > 
> > What I am wondering is how should we select a name for the device part
> > of the LED for network devices, when network namespaces are enabled.
> > 
> > a) We could just use the interface name (eth0:yellow:activity). The
> >    problem is what should happen when the interface is renamed, or
> >    moved to another network namespace.
> >    Pavel doesn't want to complicate the LED subsystem with LED device
> >    renaming, nor, I think, with namespace mechanism. I, for my part, am
> >    not opposed to LED renaming, but do not know what should happen when
> >    the interface is moved to another namespace.
> > 
> > b) We could use the device name, as in struct device *. But these names
> >    are often too long and may contain characters that we do not want in
> >    LED name (':', or '/', for example).
> > 
> > c) We could create a new naming mechanism, something like
> >    device_pretty_name(dev), which some classes may implement somehow.
> > 
> > What are your ideas about this problem?  
> 
> I lost track of where these file will appear. I was surprised with the
> location in the first proposal
> 
> Looking at one of my systems we have:
> 
> ls -l /sys/class/net/eth0/
> total 0
> -r--r--r-- 1 root root 4096 Sep 26 14:34 addr_assign_type
> -r--r--r-- 1 root root 4096 Sep 26 14:34 address
> -r--r--r-- 1 root root 4096 Sep 26 19:06 addr_len
> -r--r--r-- 1 root root 4096 Sep 26 19:06 broadcast
> ...
> phydev -> ../../mdio_bus/400d0000.ethernet-1/400d0000.ethernet-1:00
> ...
> 
> Will the LED class directory appear as a subdirectory of
> /sys/class/net/eth0/, or a subdirectory of
> ../../mdio_bus/400d0000.ethernet-1/400d0000.ethernet-1:00 or in
> /sys/class/leds?
> 
> If they are in /sys/class/led, the name needs to be globally
> unique. That rules out using the interface name, which is not globally
> unique, it is only netns unique.
> 
> If they are inside /sys/class/net/eth0, we don't need to worry about
> the name, we know which interface they belong to simply from the
> parent directory. We can then use "phy:yellow:activity".
> 
> The same applies for
> "../../mdio_bus/400d0000.ethernet-1/400d0000.ethernet-1:00". The user
> can follow the symlink from /sys/class/net/eth0 to the phy directory
> to find the LEDs for a PHY.
> 
>    Andrew

Andrew,

the directory is always, for every device in kernel, in /sys/devices
somewhere, in hierarchy corresponding to dev->parent pointers.
Everything else is via symlink.

/sys/class/net/eth0 is a symlink to something in /sys/devices somewhere.

/sys/class/net/eth0/phydev is a symlink to phydev in /sys/devices
somewhere.

If the phydev has children devices of class "leds", then its directory
will contian "leds" subdirectory, and this "leds" subdirectory will
contain subdirectories corresponding to each LED registered under the
phydev.

So I will have
  /sys/class/net/eth0/phydev/leds/eth0:green:activity
                 |        |
                 symlink  |
                          |
                        symlink

and I will also have
  /sys/class/leds/eth0:green:activity
                  |
                  symlink

For every X in /sys/class/*/X, X is symlink to something in
/sys/devices.

Even bridge devices are symlinks:

kabel@thinkpad ~ $ ls -l /sys/class/net/br0
lrwxrwxrwx 1 root root 0 Sep 20 14:41 /sys/class/net/br0 -> ../../devices/virtual/net/br0

Marek

Re: Request for Comment: LED device naming for netdev LEDs

[Marek Behun]

On Sun, 27 Sep 2020 00:40:25 +0200
Marek Behun <marek.behun@nic.cz> wrote:

> What I am wondering is how should we select a name for the device part
> of the LED for network devices, when network namespaces are enabled.
> 
> a) We could just use the interface name (eth0:yellow:activity). The
>    problem is what should happen when the interface is renamed, or
>    moved to another network namespace.
>    Pavel doesn't want to complicate the LED subsystem with LED device
>    renaming, nor, I think, with namespace mechanism. I, for my part, am
>    not opposed to LED renaming, but do not know what should happen when
>    the interface is moved to another namespace.
> 
> b) We could use the device name, as in struct device *. But these names
>    are often too long and may contain characters that we do not want in
>    LED name (':', or '/', for example).
>
> c) We could create a new naming mechanism, something like
>    device_pretty_name(dev), which some classes may implement somehow.
> 
> What are your ideas about this problem?
> 
> Marek

BTW option b) and c) can be usable if we create a new utility, ledtool,
to report infromation about LEDs and configure LEDs.

In that case it does not matter if the LED is named
  ethernet-adapter0:red:activity
or
  ethernet-phy0:red:activity
because this new ledtool utility could just look deeper into sysfs to
find out that the LED corresponds to eth0, whatever it name is.

Still does not solve namespaces, though, because ethernet PHY devices
(struct phy_device) do not currently support network namespaces.

Marek

Re: Request for Comment: LED device naming for netdev LEDs

[Andrew Lunn]

> So I will have
>   /sys/class/net/eth0/phydev/leds/eth0:green:activity
>                  |        |
>                  symlink  |
>                           |
>                         symlink
> 
> and I will also have
>   /sys/class/leds/eth0:green:activity
>                   |
>                   symlink

So this forces the name to be globally unique, not netns unique. So
you cannot use the interface name alone.

i don't think the name is actually too important. You are going to
find it via /sys/class/net/eth0/phydev/leds/eth0:green:activity so the
proposal of an incremental number works.

    Andrew

Re: Request for Comment: LED device naming for netdev LEDs

[Alexander Dahl]

Hei Marek,

Am Sonntag, 27. September 2020, 02:52:58 CEST schrieb Marek Behun:
> On Sun, 27 Sep 2020 00:40:25 +0200
> 
> Marek Behun <marek.behun@nic.cz> wrote:
> > What I am wondering is how should we select a name for the device part
> > of the LED for network devices, when network namespaces are enabled.
> > 
> > a) We could just use the interface name (eth0:yellow:activity). The
> > 
> >    problem is what should happen when the interface is renamed, or
> >    moved to another network namespace.
> >    Pavel doesn't want to complicate the LED subsystem with LED device
> >    renaming, nor, I think, with namespace mechanism. I, for my part, am
> >    not opposed to LED renaming, but do not know what should happen when
> >    the interface is moved to another namespace.
> > 
> > b) We could use the device name, as in struct device *. But these names
> > 
> >    are often too long and may contain characters that we do not want in
> >    LED name (':', or '/', for example).
> > 
> > c) We could create a new naming mechanism, something like
> > 
> >    device_pretty_name(dev), which some classes may implement somehow.
> > 
> > What are your ideas about this problem?
> > 
> > Marek
> 
> BTW option b) and c) can be usable if we create a new utility, ledtool,
> to report infromation about LEDs and configure LEDs.
> 
> In that case it does not matter if the LED is named
>   ethernet-adapter0:red:activity
> or
>   ethernet-phy0:red:activity
> because this new ledtool utility could just look deeper into sysfs to
> find out that the LED corresponds to eth0, whatever it name is.

I like the idea to have such a tool.  What do you have in mind?  Sounds for me 
like it would be somehow similar to libgpiod with gpio* for GPIO devices or 
like libevdev for input devices or like mtd-utils …

Especially a userspace library could be helpful to avoid reinventing the wheel 
on userspace developer side?

Does anyone else know prior work for linux leds sysfs interface from 
userspace?

Greets
Alex

Re: Request for Comment: LED device naming for netdev LEDs

[Marek Behun]

On Mon, 28 Sep 2020 15:04:10 +0200
Alexander Dahl <ada@thorsis.com> wrote:

> Hei Marek,
> 
> Am Sonntag, 27. September 2020, 02:52:58 CEST schrieb Marek Behun:
> > On Sun, 27 Sep 2020 00:40:25 +0200
> > 
> > Marek Behun <marek.behun@nic.cz> wrote:  
> > > What I am wondering is how should we select a name for the device part
> > > of the LED for network devices, when network namespaces are enabled.
> > > 
> > > a) We could just use the interface name (eth0:yellow:activity). The
> > > 
> > >    problem is what should happen when the interface is renamed, or
> > >    moved to another network namespace.
> > >    Pavel doesn't want to complicate the LED subsystem with LED device
> > >    renaming, nor, I think, with namespace mechanism. I, for my part, am
> > >    not opposed to LED renaming, but do not know what should happen when
> > >    the interface is moved to another namespace.
> > > 
> > > b) We could use the device name, as in struct device *. But these names
> > > 
> > >    are often too long and may contain characters that we do not want in
> > >    LED name (':', or '/', for example).
> > > 
> > > c) We could create a new naming mechanism, something like
> > > 
> > >    device_pretty_name(dev), which some classes may implement somehow.
> > > 
> > > What are your ideas about this problem?
> > > 
> > > Marek  
> > 
> > BTW option b) and c) can be usable if we create a new utility, ledtool,
> > to report infromation about LEDs and configure LEDs.
> > 
> > In that case it does not matter if the LED is named
> >   ethernet-adapter0:red:activity
> > or
> >   ethernet-phy0:red:activity
> > because this new ledtool utility could just look deeper into sysfs to
> > find out that the LED corresponds to eth0, whatever it name is.  
> 
> I like the idea to have such a tool.  What do you have in mind?  Sounds for me 
> like it would be somehow similar to libgpiod with gpio* for GPIO devices or 
> like libevdev for input devices or like mtd-utils …
> 
As Pavel said, we have ethtool, maybe we could have ledtool.

> Especially a userspace library could be helpful to avoid reinventing the wheel 
> on userspace developer side?

If such a need arises, than yes. For most embedded systems though I
think ledtool would be enough, since mostly LEDs can be controlled from
shell scripts.

> Does anyone else know prior work for linux leds sysfs interface from 
> userspace?

I am not aware of that, everyone just uses sysfs now.

Marek

Re: Request for Comment: LED device naming for netdev LEDs

[Alexander Dahl]

[-- Attachment #1: Type: text/plain, Size: 3689 bytes --]

Hei hei,

On Mon, Sep 28, 2020 at 05:52:09PM +0200, Marek Behun wrote:
> On Mon, 28 Sep 2020 15:04:10 +0200
> Alexander Dahl <ada@thorsis.com> wrote:
> 
> > Hei Marek,
> > 
> > Am Sonntag, 27. September 2020, 02:52:58 CEST schrieb Marek Behun:
> > > On Sun, 27 Sep 2020 00:40:25 +0200
> > > 
> > > Marek Behun <marek.behun@nic.cz> wrote:  
> > > > What I am wondering is how should we select a name for the device part
> > > > of the LED for network devices, when network namespaces are enabled.
> > > > 
> > > > a) We could just use the interface name (eth0:yellow:activity). The
> > > > 
> > > >    problem is what should happen when the interface is renamed, or
> > > >    moved to another network namespace.
> > > >    Pavel doesn't want to complicate the LED subsystem with LED device
> > > >    renaming, nor, I think, with namespace mechanism. I, for my part, am
> > > >    not opposed to LED renaming, but do not know what should happen when
> > > >    the interface is moved to another namespace.
> > > > 
> > > > b) We could use the device name, as in struct device *. But these names
> > > > 
> > > >    are often too long and may contain characters that we do not want in
> > > >    LED name (':', or '/', for example).
> > > > 
> > > > c) We could create a new naming mechanism, something like
> > > > 
> > > >    device_pretty_name(dev), which some classes may implement somehow.
> > > > 
> > > > What are your ideas about this problem?
> > > > 
> > > > Marek  
> > > 
> > > BTW option b) and c) can be usable if we create a new utility, ledtool,
> > > to report infromation about LEDs and configure LEDs.
> > > 
> > > In that case it does not matter if the LED is named
> > >   ethernet-adapter0:red:activity
> > > or
> > >   ethernet-phy0:red:activity
> > > because this new ledtool utility could just look deeper into sysfs to
> > > find out that the LED corresponds to eth0, whatever it name is.  
> > 
> > I like the idea to have such a tool.  What do you have in mind?  Sounds for me 
> > like it would be somehow similar to libgpiod with gpio* for GPIO devices or 
> > like libevdev for input devices or like mtd-utils …
> > 
> As Pavel said, we have ethtool, maybe we could have ledtool.

Yes.  IIRC ethtool uses libmnl for communicating with the kernel
through the netlink interface.

> > Especially a userspace library could be helpful to avoid reinventing the wheel 
> > on userspace developer side?
> 
> If such a need arises, than yes. For most embedded systems though I
> think ledtool would be enough, since mostly LEDs can be controlled from
> shell scripts.

I saw proprietary embedded C++ applications building on top of
proprietary C libraries interacting with the sysfs leds interface …
O:-)

> > Does anyone else know prior work for linux leds sysfs interface from 
> > userspace?
> 
> I am not aware of that, everyone just uses sysfs now.

Sorry, that was maybe misleading.  What I wanted to know was if there
already is some free library/tool using that sysfs interface?  I
suppose not, otherwise "ledtool" would not be needed?  IIRC there are
generic libs for abstracting sysfs access, but I did not like them.
;-)

Long story short, I would be interested in helping on a ledtool /
libledtool in C in my spare time.  (No time to learn Rust at the
moment though.)

Greets
Alex

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN     | speech censured, the first thought forbidden, the
 X  AGAINST      | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL    | (Jean-Luc Picard, quoting Judge Aaron Satie)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Request for Comment: LED device naming for netdev LEDs

[Marek Behun]

On Mon, 28 Sep 2020 19:10:05 +0200
Alexander Dahl <post@lespocky.de> wrote:

> Hei hei,
> 
> On Mon, Sep 28, 2020 at 05:52:09PM +0200, Marek Behun wrote:
> > On Mon, 28 Sep 2020 15:04:10 +0200
> > Alexander Dahl <ada@thorsis.com> wrote:
> >   
> > > Hei Marek,
> > > 
> > > Am Sonntag, 27. September 2020, 02:52:58 CEST schrieb Marek Behun:  
> > > > On Sun, 27 Sep 2020 00:40:25 +0200
> > > > 
> > > > Marek Behun <marek.behun@nic.cz> wrote:    
> > > > > What I am wondering is how should we select a name for the device part
> > > > > of the LED for network devices, when network namespaces are enabled.
> > > > > 
> > > > > a) We could just use the interface name (eth0:yellow:activity). The
> > > > > 
> > > > >    problem is what should happen when the interface is renamed, or
> > > > >    moved to another network namespace.
> > > > >    Pavel doesn't want to complicate the LED subsystem with LED device
> > > > >    renaming, nor, I think, with namespace mechanism. I, for my part, am
> > > > >    not opposed to LED renaming, but do not know what should happen when
> > > > >    the interface is moved to another namespace.
> > > > > 
> > > > > b) We could use the device name, as in struct device *. But these names
> > > > > 
> > > > >    are often too long and may contain characters that we do not want in
> > > > >    LED name (':', or '/', for example).
> > > > > 
> > > > > c) We could create a new naming mechanism, something like
> > > > > 
> > > > >    device_pretty_name(dev), which some classes may implement somehow.
> > > > > 
> > > > > What are your ideas about this problem?
> > > > > 
> > > > > Marek    
> > > > 
> > > > BTW option b) and c) can be usable if we create a new utility, ledtool,
> > > > to report infromation about LEDs and configure LEDs.
> > > > 
> > > > In that case it does not matter if the LED is named
> > > >   ethernet-adapter0:red:activity
> > > > or
> > > >   ethernet-phy0:red:activity
> > > > because this new ledtool utility could just look deeper into sysfs to
> > > > find out that the LED corresponds to eth0, whatever it name is.    
> > > 
> > > I like the idea to have such a tool.  What do you have in mind?  Sounds for me 
> > > like it would be somehow similar to libgpiod with gpio* for GPIO devices or 
> > > like libevdev for input devices or like mtd-utils …
> > >   
> > As Pavel said, we have ethtool, maybe we could have ledtool.  
> 
> Yes.  IIRC ethtool uses libmnl for communicating with the kernel
> through the netlink interface.
> 
> > > Especially a userspace library could be helpful to avoid reinventing the wheel 
> > > on userspace developer side?  
> > 
> > If such a need arises, than yes. For most embedded systems though I
> > think ledtool would be enough, since mostly LEDs can be controlled from
> > shell scripts.  
> 
> I saw proprietary embedded C++ applications building on top of
> proprietary C libraries interacting with the sysfs leds interface …
> O:-)
> 

:-O okaaaay...

> > > Does anyone else know prior work for linux leds sysfs interface from 
> > > userspace?  
> > 
> > I am not aware of that, everyone just uses sysfs now.  
> 
> Sorry, that was maybe misleading.  What I wanted to know was if there
> already is some free library/tool using that sysfs interface?  I
> suppose not, otherwise "ledtool" would not be needed?  IIRC there are
> generic libs for abstracting sysfs access, but I did not like them.
> ;-)
> 
> Long story short, I would be interested in helping on a ledtool /
> libledtool in C in my spare time.  (No time to learn Rust at the
> moment though.)

Well, we can always work on something independent of Pavel, but I
don't think that would be wise...

> Greets
> Alex
> 

Re: Request for Comment: LED device naming for netdev LEDs

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

Hi!

> > What I am wondering is how should we select a name for the device part
> > of the LED for network devices, when network namespaces are enabled.
> > 
> > a) We could just use the interface name (eth0:yellow:activity). The
> >    problem is what should happen when the interface is renamed, or
> >    moved to another network namespace.
> >    Pavel doesn't want to complicate the LED subsystem with LED device
> >    renaming, nor, I think, with namespace mechanism. I, for my part, am
> >    not opposed to LED renaming, but do not know what should happen when
> >    the interface is moved to another namespace.
> > 
> > b) We could use the device name, as in struct device *. But these names
> >    are often too long and may contain characters that we do not want in
> >    LED name (':', or '/', for example).
> >
> > c) We could create a new naming mechanism, something like
> >    device_pretty_name(dev), which some classes may implement somehow.
> > 
> > What are your ideas about this problem?
> 
> BTW option b) and c) can be usable if we create a new utility, ledtool,
> to report infromation about LEDs and configure LEDs.
> 
> In that case it does not matter if the LED is named
>   ethernet-adapter0:red:activity
> or
>   ethernet-phy0:red:activity

Or simply ethernet0:... or ether0:... I'd avoid using eth0 to make it
clear that this is different namespace from ethX.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Request for Comment: LED device naming for netdev LEDs

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

Hi!

> > > What are your ideas about this problem?
> > > 
> > > Marek
> > 
> > BTW option b) and c) can be usable if we create a new utility, ledtool,
> > to report infromation about LEDs and configure LEDs.
> > 
> > In that case it does not matter if the LED is named
> >   ethernet-adapter0:red:activity
> > or
> >   ethernet-phy0:red:activity
> > because this new ledtool utility could just look deeper into sysfs to
> > find out that the LED corresponds to eth0, whatever it name is.
> 
> I like the idea to have such a tool.  What do you have in mind?  Sounds for me 
> like it would be somehow similar to libgpiod with gpio* for GPIO devices or 
> like libevdev for input devices or like mtd-utils …
> 
> Especially a userspace library could be helpful to avoid reinventing the wheel 
> on userspace developer side?
> 
> Does anyone else know prior work for linux leds sysfs interface from 
> userspace?

I have code in tui project which accesses the LEDs from python... and
I started writing ledtool in rust.

Anyway, I agree we should provide shared library, too. Going through
the fork/exec is just too ugly.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]