All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Marek Behun <marek.behun@nic.cz>
Cc: netdev <netdev@vger.kernel.org>,
	linux-leds@vger.kernel.org, David Miller <davem@davemloft.net>,
	Andrew Lunn <andrew@lunn.ch>,
	Russell King <linux@armlinux.org.uk>
Subject: Re: Request for Comment: LED device naming for netdev LEDs
Date: Wed, 25 Nov 2020 11:57:57 +0100	[thread overview]
Message-ID: <20201125105757.GF25562@amd> (raw)
In-Reply-To: <20200927025258.38585d5e@nic.cz>

[-- 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 --]

      parent reply	other threads:[~2020-11-25 10:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-26 22:40 Request for Comment: LED device naming for netdev LEDs Marek Behun
2020-09-27  0:29 ` Andrew Lunn
2020-09-27  0:45   ` Marek Behun
2020-09-27  1:13     ` Andrew Lunn
2020-09-27  0:52 ` Marek Behun
2020-09-28 13:04   ` Alexander Dahl
2020-09-28 15:52     ` Marek Behun
2020-09-28 17:10       ` Alexander Dahl
2020-09-28 17:22         ` Marek Behun
2020-11-25 10:59     ` Pavel Machek
2020-11-25 10:57   ` Pavel Machek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201125105757.GF25562@amd \
    --to=pavel@ucw.cz \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=marek.behun@nic.cz \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.