Hello Greg,
could you give your opinion on this discussion?
Are device names (as returned by dev_name() function) also part of
sysfs ABI? Should these names be stable across reboots / kernel
upgrades?
Marek
On Fri, 1 Oct 2021 14:40:53 +0200
Marek Behún <[email protected]> wrote:
> On Fri, 1 Oct 2021 14:29:17 +0200
> Andrew Lunn <[email protected]> wrote:
>
> > > - Andrew proposed that the numbering should start at non-zero number,
> > > for example at 42, to prevent people from thinking that the numbers
> > > are related to numbers in network interface names (ethN).
> > > A system with interfaces
> > > eth0
> > > eth1
> > > and LEDs
> > > ethphy0:green:link
> > > ethphy1:green:link
> > > may make user think that the ethphy0 LED does correspond to eth0
> > > interface, which is not necessarily true.
> > > Instead if LEDs are
> > > ethphy42:green:link
> > > ethphy43:green:link
> > > the probability of confusing the user into relating them to network
> > > interfaces by these numbers is lower.
> > >
> > > Anyway, the issue with these naming is that it is not stable. Upgrading
> > > the kernel, enabling drivers and so on can change these names between
> > > reboots.
> >
> > Sure, eth0 can become eth1, eth1 can become eth0. That is why we have
> > udev rules, systemd interface names etc. Interface names have never
> > been guaranteed to be stable. Also, you can have multiple interfaces
> > named eth0, so long as they are in different network name spaces.
> >
> > > Also for LEDs on USB ethernet adapters, removing the USB and
> > > plugging it again would change the name, although the device path does
> > > not change if the adapter is re-plugged into the same port.
> > >
> > > To finally settle this then, I would like to ask your opinion on
> > > whether this naming of LEDs should be stable.
> >
> > No. They should be unstable like everything else.
>
> LED classdev names are something different.
> For etherent interfaces, the interface name is different from name of
> the underlying struct device. But LED classdev names are also
> corresponding struct device names, and thus part of sysfs ABI, which,
> as far as I understand, should be stable.
On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Beh?n wrote:
> Hello Greg,
>
> could you give your opinion on this discussion?
What discussion? Top posting ruins that :(
> Are device names (as returned by dev_name() function) also part of
> sysfs ABI? Should these names be stable across reboots / kernel
> upgrades?
Stable in what exact way?
Numbering of devices (where a dynamic value is part of a name, like the
"42" in "usb42"), is never guaranteed to be stable, but the non-number
part of the name (like "usb" is in "usb42") is stable, as that is what
you have properly documented in the Documentation/ABI/ files defining
the bus and class devices, right?
The very reason we export all of this information to userspace is so
that userspace can figure it all out in ways it wants to, if it wants
to, and no naming scheme that has to be static and deterministic is
forced into the kernel, where it does NOT belong.
That is 1/2 of the reason why we created the whole "unified
device/driver model" in the kernel in the first place all those years
ago.
Does that help? I can't figure out what the "problem" is here...
thanks,
greg k-h
Hi Greg,
On Mon, 4 Oct 2021 08:37:37 +0200
Greg Kroah-Hartman <[email protected]> wrote:
> On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Behún wrote:
> > Hello Greg,
> >
> > could you give your opinion on this discussion?
>
> What discussion? Top posting ruins that :(
Sorry, the discussion is here
https://lore.kernel.org/linux-leds/20211001144053.3952474a@thinkpad/T/
But the basic question is below, so you don't need to read the
discussion.
> > Are device names (as returned by dev_name() function) also part of
> > sysfs ABI? Should these names be stable across reboots / kernel
> > upgrades?
>
> Stable in what exact way?
Example:
- Board has an ethernet PHYs that is described in DT, and therefore
has stable sysfs path (derived from DT path), something like
/sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
- The PHY has a subnode describing a LED.
The LED subsystem has a different naming scheme (it uses DT node name
as a last resort). When everything is okay, the dev_name() of the LED
will be something like
ethphy42:green:link
- Now suppose that the PHY driver is unloaded and loaded again. The PHY
sysfs path is unchanged, but the LED will now be named
ethphy43:green:link
Is this OK?
> Numbering of devices (where a dynamic value is part of a name, like the
> "42" in "usb42"), is never guaranteed to be stable, but the non-number
> part of the name (like "usb" is in "usb42") is stable, as that is what
> you have properly documented in the Documentation/ABI/ files defining
> the bus and class devices, right?
It does make sense for removable devices like USB. What I am asking
is whether it is also OK for devices that have stable DT nodes.
Marek
On Mon, Oct 04, 2021 at 09:04:38AM +0200, Marek Beh?n wrote:
> Hi Greg,
>
> On Mon, 4 Oct 2021 08:37:37 +0200
> Greg Kroah-Hartman <[email protected]> wrote:
>
> > On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Beh?n wrote:
> > > Hello Greg,
> > >
> > > could you give your opinion on this discussion?
> >
> > What discussion? Top posting ruins that :(
>
> Sorry, the discussion is here
> https://lore.kernel.org/linux-leds/20211001144053.3952474a@thinkpad/T/
> But the basic question is below, so you don't need to read the
> discussion.
>
> > > Are device names (as returned by dev_name() function) also part of
> > > sysfs ABI? Should these names be stable across reboots / kernel
> > > upgrades?
> >
> > Stable in what exact way?
>
> Example:
> - Board has an ethernet PHYs that is described in DT, and therefore
> has stable sysfs path (derived from DT path), something like
> /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
None of the numbers there are "stable", right?
> - The PHY has a subnode describing a LED.
> The LED subsystem has a different naming scheme (it uses DT node name
> as a last resort). When everything is okay, the dev_name() of the LED
> will be something like
> ethphy42:green:link
Wonderful, but the "42" means nothing.
> - Now suppose that the PHY driver is unloaded and loaded again. The PHY
> sysfs path is unchanged, but the LED will now be named
> ethphy43:green:link
>
> Is this OK?
Yup!
The "link" should point to the device it is associated with, right? You
need to have some way to refer to the device.
> > Numbering of devices (where a dynamic value is part of a name, like the
> > "42" in "usb42"), is never guaranteed to be stable, but the non-number
> > part of the name (like "usb" is in "usb42") is stable, as that is what
> > you have properly documented in the Documentation/ABI/ files defining
> > the bus and class devices, right?
>
> It does make sense for removable devices like USB. What I am asking
> is whether it is also OK for devices that have stable DT nodes.
Any device can be "removed" from the system and added back thanks to the
joy of the driver model :)
Also, what prevents your DT from renumbering things in an update to it
in the future? The kernel doesn't care, and userspace should be able to
handle it.
Again, any numbering scheme is NEVER stable, just because it feels like
it is at the moment for your device, you should NEVER rely on that, but
instead rely on the attributes of the device to determine what it is and
where it is in the device hierarchy (serial number, position location,
partition name, etc.) in order to know what it associated with.
And again, this is 1/2 of the whole reason _why_ we created the unified
driver model in the kernel. Don't try to go back to the nightmare that
we had in the 2.4 and earlier kernel days please.
thanks,
greg k-h
Hi!
> > > > Are device names (as returned by dev_name() function) also part of
> > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > upgrades?
> > >
> > > Stable in what exact way?
> >
> > Example:
> > - Board has an ethernet PHYs that is described in DT, and therefore
> > has stable sysfs path (derived from DT path), something like
> > /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
>
> None of the numbers there are "stable", right?
At least f1072004 part is stable (and probably whole path). DT has
advantages here, and we should provide stable paths when we can.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
On Mon, 4 Oct 2021 09:10:35 +0200
Greg Kroah-Hartman <[email protected]> wrote:
> On Mon, Oct 04, 2021 at 09:04:38AM +0200, Marek Behún wrote:
> > Hi Greg,
> >
> > On Mon, 4 Oct 2021 08:37:37 +0200
> > Greg Kroah-Hartman <[email protected]> wrote:
> >
> > > On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Behún wrote:
> > > > Hello Greg,
> > > >
> > > > could you give your opinion on this discussion?
> > >
> > > What discussion? Top posting ruins that :(
> >
> > Sorry, the discussion is here
> > https://lore.kernel.org/linux-leds/20211001144053.3952474a@thinkpad/T/
> > But the basic question is below, so you don't need to read the
> > discussion.
> >
> > > > Are device names (as returned by dev_name() function) also part of
> > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > upgrades?
> > >
> > > Stable in what exact way?
> >
> > Example:
> > - Board has an ethernet PHYs that is described in DT, and therefore
> > has stable sysfs path (derived from DT path), something like
> > /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
>
> None of the numbers there are "stable", right?
>
> > - The PHY has a subnode describing a LED.
> > The LED subsystem has a different naming scheme (it uses DT node name
> > as a last resort). When everything is okay, the dev_name() of the LED
> > will be something like
> > ethphy42:green:link
>
> Wonderful, but the "42" means nothing.
>
> > - Now suppose that the PHY driver is unloaded and loaded again. The PHY
> > sysfs path is unchanged, but the LED will now be named
> > ethphy43:green:link
> >
> > Is this OK?
>
> Yup!
>
> The "link" should point to the device it is associated with, right? You
> need to have some way to refer to the device.
>
> > > Numbering of devices (where a dynamic value is part of a name, like the
> > > "42" in "usb42"), is never guaranteed to be stable, but the non-number
> > > part of the name (like "usb" is in "usb42") is stable, as that is what
> > > you have properly documented in the Documentation/ABI/ files defining
> > > the bus and class devices, right?
> >
> > It does make sense for removable devices like USB. What I am asking
> > is whether it is also OK for devices that have stable DT nodes.
>
> Any device can be "removed" from the system and added back thanks to the
> joy of the driver model :)
>
> Also, what prevents your DT from renumbering things in an update to it
> in the future? The kernel doesn't care, and userspace should be able to
> handle it.
>
> Again, any numbering scheme is NEVER stable, just because it feels like
> it is at the moment for your device, you should NEVER rely on that, but
> instead rely on the attributes of the device to determine what it is and
> where it is in the device hierarchy (serial number, position location,
> partition name, etc.) in order to know what it associated with.
>
> And again, this is 1/2 of the whole reason _why_ we created the unified
> driver model in the kernel. Don't try to go back to the nightmare that
> we had in the 2.4 and earlier kernel days please.
OK, thanks Greg. This simplifies things. I shall send another version
of LEDs under ethernet PHYs soon :)
Marek
On Mon, Oct 04, 2021 at 09:38:41AM +0200, Pavel Machek wrote:
> Hi!
>
> > > > > Are device names (as returned by dev_name() function) also part of
> > > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > > upgrades?
> > > >
> > > > Stable in what exact way?
> > >
> > > Example:
> > > - Board has an ethernet PHYs that is described in DT, and therefore
> > > has stable sysfs path (derived from DT path), something like
> > > /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
> >
> > None of the numbers there are "stable", right?
>
> At least f1072004 part is stable (and probably whole path). DT has
> advantages here, and we should provide stable paths when we can.
The kernel should enumerate the devices as best that it can, but it
never has the requirement of always enumerating them in the same way
each time as many busses are not deterministic.
On Mon, Oct 04, 2021 at 10:30:25AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Oct 04, 2021 at 09:38:41AM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > > > Are device names (as returned by dev_name() function) also part of
> > > > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > > > upgrades?
> > > > >
> > > > > Stable in what exact way?
> > > >
> > > > Example:
> > > > - Board has an ethernet PHYs that is described in DT, and therefore
> > > > has stable sysfs path (derived from DT path), something like
> > > > /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
> > >
> > > None of the numbers there are "stable", right?
> >
> > At least f1072004 part is stable (and probably whole path). DT has
> > advantages here, and we should provide stable paths when we can.
>
> The kernel should enumerate the devices as best that it can, but it
> never has the requirement of always enumerating them in the same way
> each time as many busses are not deterministic.
And for this particular SoC, it is possible to map the memory mapped
IO at a different address range. It is the bootloader which determines
this. There are some Marvell uboot's which use 0xd0000000, not
0xf0000000. So strictly speaking, f1072004 is not stable, it is not
hard wired in the silicon.
Andrew