SPI (and others) has a way to define bus number in a aliases:
aliases {
ethernet4 = &enet4;
ethernet0 = &enet0;
ethernet1 = &enet1;
ethernet2 = &enet2;
ethernet3 = &enet3;
spi0 = &spi0
};
The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
I am looking for the same for ethernet devices:
ethernet4 = &enet4; /* should become eth4 */
ethernet0 = &enet0; /* should become eth0 */
but I cannot find something like that for eth devices.
Could such functionality be added?
Jocke
SPI (and others) has a way to define bus number in a aliases:
aliases {
ethernet4 = &enet4;
ethernet0 = &enet0;
ethernet1 = &enet1;
ethernet2 = &enet2;
ethernet3 = &enet3;
spi0 = &spi0
};
The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
I am looking for the same for ethernet devices:
ethernet4 = &enet4; /* should become eth4 */
ethernet0 = &enet0; /* should become eth0 */
but I cannot find something like that for eth devices.
Could such functionality be added?
It could, do we want and need to, no. You have the Ethernet alias in
/sys/class/net/*/device/uevent already that would allow you to perform
that (re)naming in user-space:
# cat /sys/class/net/eth0/device/uevent
DRIVER=bcmgenet
OF_NAME=ethernet
OF_FULLNAME=/rdb/ethernet@f0480000
OF_TYPE=network
OF_COMPATIBLE_0=brcm,genet-v5
OF_COMPATIBLE_N=1
OF_ALIAS_0=eth0 <==================
MODALIAS=of:NethernetTnetworkCbrcm,genet-v5
--
Florian
From: Andrew Lunn <andrew@lunn.ch> Date: 2018-10-23 17:37:53
On Tue, Oct 23, 2018 at 04:49:59PM +0000, Joakim Tjernlund wrote:
SPI (and others) has a way to define bus number in a aliases:
aliases {
ethernet4 = &enet4;
ethernet0 = &enet0;
ethernet1 = &enet1;
ethernet2 = &enet2;
ethernet3 = &enet3;
spi0 = &spi0
};
The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
I am looking for the same for ethernet devices:
ethernet4 = &enet4; /* should become eth4 */
ethernet0 = &enet0; /* should become eth0 */
but I cannot find something like that for eth devices.
Could such functionality be added?
Hi Jocke
This has been discussed before. Take a look at
arch/arm/boot/dts/armada-38x.dtsi
/*
* As a special exception to the "order by
* register address" rule, the eth0 node is
* placed here to ensure that it gets
* registered as the first interface, since
* the network subsystem doesn't allow naming
* interfaces using DT aliases. Without this,
* the ordering of interfaces is different
* from the one used in U-Boot and the
* labeling of interfaces on the boards, which
* is very confusing for users.
*/
You should be able to find the discuss about this, and why aliases
cannot be used.
Andrew
On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On 10/23/18 9:49 AM, Joakim Tjernlund wrote:
quoted
SPI (and others) has a way to define bus number in a aliases:
aliases {
ethernet4 = &enet4;
ethernet0 = &enet0;
ethernet1 = &enet1;
ethernet2 = &enet2;
ethernet3 = &enet3;
spi0 = &spi0
};
The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
I am looking for the same for ethernet devices:
ethernet4 = &enet4; /* should become eth4 */
ethernet0 = &enet0; /* should become eth0 */
but I cannot find something like that for eth devices.
Could such functionality be added?
It could, do we want and need to, no. You have the Ethernet alias in
/sys/class/net/*/device/uevent already that would allow you to perform
that (re)naming in user-space:
# cat /sys/class/net/eth0/device/uevent
DRIVER=bcmgenet
OF_NAME=ethernet
OF_FULLNAME=/rdb/ethernet@f0480000
OF_TYPE=network
OF_COMPATIBLE_0=brcm,genet-v5
OF_COMPATIBLE_N=1
OF_ALIAS_0=eth0 <==================
MODALIAS=of:NethernetTnetworkCbrcm,genet-v5
Yes, one can if one uses udev and can find something to identify the hw I/F with, my
cat /sys/class/net/eth0/device/uevent looks like:
DRIVER=fsl_dpa
MODALIAS=platform:dpaa-ethernet
not sure mdev supports this, does it?
Our simple installer FS(initramfs) doesn't have either udev or mdev.
I also noted that using status = "disabled" didn't work either to create a fix name scheme.
Even worse, all the eth I/F after gets renumbered. It seems to me there
is value in having stability in eth I/F naming at boot.
Then userspace(udev) can rename if need be.
Sure would like to known more about why this feature is not wanted ?
I found
https://patchwork.kernel.org/patch/4122441/
You quote policy as reason but surely it must be better to
have something stable, connected to the hardware name, than semirandom naming?
Jocke
On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
quoted
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On 10/23/18 9:49 AM, Joakim Tjernlund wrote:
quoted
SPI (and others) has a way to define bus number in a aliases:
aliases {
ethernet4 = &enet4;
ethernet0 = &enet0;
ethernet1 = &enet1;
ethernet2 = &enet2;
ethernet3 = &enet3;
spi0 = &spi0
};
The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
I am looking for the same for ethernet devices:
ethernet4 = &enet4; /* should become eth4 */
ethernet0 = &enet0; /* should become eth0 */
but I cannot find something like that for eth devices.
Could such functionality be added?
It could, do we want and need to, no. You have the Ethernet alias in
/sys/class/net/*/device/uevent already that would allow you to perform
that (re)naming in user-space:
# cat /sys/class/net/eth0/device/uevent
DRIVER=bcmgenet
OF_NAME=ethernet
OF_FULLNAME=/rdb/ethernet@f0480000
OF_TYPE=network
OF_COMPATIBLE_0=brcm,genet-v5
OF_COMPATIBLE_N=1
OF_ALIAS_0=eth0 <==================
MODALIAS=of:NethernetTnetworkCbrcm,genet-v5
Yes, one can if one uses udev and can find something to identify the hw I/F with, my
cat /sys/class/net/eth0/device/uevent looks like:
DRIVER=fsl_dpa
MODALIAS=platform:dpaa-ethernet
Does not dpaa have a notion of Ethernet ports and those should have
proper information? Maybe that is part of your problem here, it should
have the OF_ALIAS information somehow available.
not sure mdev supports this, does it?
Our simple installer FS(initramfs) doesn't have either udev or mdev.
I don't know, but you could have a simple shell script that looks at
specific network device properties to decide on the naming and call
ifrename.
I also noted that using status = "disabled" didn't work either to create a fix name scheme.
Even worse, all the eth I/F after gets renumbered. It seems to me there
is value in having stability in eth I/F naming at boot.
Then userspace(udev) can rename if need be.
Sure would like to known more about why this feature is not wanted ?
I found
https://patchwork.kernel.org/patch/4122441/
You quote policy as reason but surely it must be better to
have something stable, connected to the hardware name, than semirandom naming?
If the Device Tree nodes are ordered by ascending base register address,
my understanding is that you get the same order as far as
platform_device creation goes, this may not be true in the future if Rob
decides to randomize that, but AFAICT this is still true. This may not
work well with status = disabled properties being inserted here and
there, but we have used that here and it has worked for as far as I can
remember doing it.
Second, you might want to name network devices ethX, but what if I want
to name them ethernetX or fooX or barX? Should we be accepting a
mechanism in the kernel that would allow someone to name the interfaces
the way they want straight from a name being provided in Device Tree?
Aliases are fine for providing relative stability within the Device Tree
itself and boot programs that might need to modify the Device Tree (e.g:
inserting MAC addresses) such that you don't have to encode logic to
search for nodes by compatible strings etc. but outside of that use
case, it seems to me that you can resolve every naming decision in
user-space.
--
Florian
On Tue, 2018-10-23 at 11:20 -0700, Florian Fainelli wrote:
On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
quoted
On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
quoted
On 10/23/18 9:49 AM, Joakim Tjernlund wrote:
quoted
SPI (and others) has a way to define bus number in a aliases:
aliases {
ethernet4 = &enet4;
ethernet0 = &enet0;
ethernet1 = &enet1;
ethernet2 = &enet2;
ethernet3 = &enet3;
spi0 = &spi0
};
The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
I am looking for the same for ethernet devices:
ethernet4 = &enet4; /* should become eth4 */
ethernet0 = &enet0; /* should become eth0 */
but I cannot find something like that for eth devices.
Could such functionality be added?
It could, do we want and need to, no. You have the Ethernet alias in
/sys/class/net/*/device/uevent already that would allow you to perform
that (re)naming in user-space:
# cat /sys/class/net/eth0/device/uevent
DRIVER=bcmgenet
OF_NAME=ethernet
OF_FULLNAME=/rdb/ethernet@f0480000
OF_TYPE=network
OF_COMPATIBLE_0=brcm,genet-v5
OF_COMPATIBLE_N=1
OF_ALIAS_0=eth0 <==================
MODALIAS=of:NethernetTnetworkCbrcm,genet-v5
Yes, one can if one uses udev and can find something to identify the hw I/F with, my
cat /sys/class/net/eth0/device/uevent looks like:
DRIVER=fsl_dpa
MODALIAS=platform:dpaa-ethernet
Does not dpaa have a notion of Ethernet ports and those should have
proper information? Maybe that is part of your problem here, it should
have the OF_ALIAS information somehow available.
I cannot say ATM, but this lack of standard does not make it easier to rename I/F's in udev.
quoted
not sure mdev supports this, does it?
Our simple installer FS(initramfs) doesn't have either udev or mdev.
I don't know, but you could have a simple shell script that looks at
specific network device properties to decide on the naming and call
ifrename.
This reinventing of the wheel is what I am trying to avoid.
quoted
I also noted that using status = "disabled" didn't work either to create a fix name scheme.
Even worse, all the eth I/F after gets renumbered. It seems to me there
is value in having stability in eth I/F naming at boot.
Then userspace(udev) can rename if need be.
Sure would like to known more about why this feature is not wanted ?
I found
https://patchwork.kernel.org/patch/4122441/
You quote policy as reason but surely it must be better to
have something stable, connected to the hardware name, than semirandom naming?
If the Device Tree nodes are ordered by ascending base register address,
my understanding is that you get the same order as far as
platform_device creation goes, this may not be true in the future if Rob
decides to randomize that, but AFAICT this is still true. This may not
work well with status = disabled properties being inserted here and
there, but we have used that here and it has worked for as far as I can
remember doing it.
I recall it is the order in which the eth alias appear that controls the naming,
not 100% sure though.
Second, you might want to name network devices ethX, but what if I want
to name them ethernetX or fooX or barX? Should we be accepting a
mechanism in the kernel that would allow someone to name the interfaces
the way they want straight from a name being provided in Device Tree?
I just want to have stable boot names, aka ethX, which can defined in
the platforms DT. Then userspace can go from there to whatever it needs,
udev could possibly use these stable boot names to identify the I/F's to rename.
ATM, it is pretty hard to even use udev when /sys/class/net/eth0/device/uevent
can look different even for OF created interfaces.
Aliases are fine for providing relative stability within the Device Tree
itself and boot programs that might need to modify the Device Tree (e.g:
inserting MAC addresses) such that you don't have to encode logic to
search for nodes by compatible strings etc. but outside of that use
case, it seems to me that you can resolve every naming decision in
user-space.
Well, you can resolve MAC address assignment in user space too but most
will agree that is not convenient. I suggest it is also handy to have
some control of I/F enumeration(ethX that is) from platform code like DT.
Jocke
On Tue, 2018-10-23 at 11:20 -0700, Florian Fainelli wrote:
quoted
On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
quoted
On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
quoted
On 10/23/18 9:49 AM, Joakim Tjernlund wrote:
quoted
SPI (and others) has a way to define bus number in a aliases:
aliases {
ethernet4 = &enet4;
ethernet0 = &enet0;
ethernet1 = &enet1;
ethernet2 = &enet2;
ethernet3 = &enet3;
spi0 = &spi0
};
The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
I am looking for the same for ethernet devices:
ethernet4 = &enet4; /* should become eth4 */
ethernet0 = &enet0; /* should become eth0 */
but I cannot find something like that for eth devices.
Could such functionality be added?
It could, do we want and need to, no. You have the Ethernet alias in
/sys/class/net/*/device/uevent already that would allow you to perform
that (re)naming in user-space:
# cat /sys/class/net/eth0/device/uevent
DRIVER=bcmgenet
OF_NAME=ethernet
OF_FULLNAME=/rdb/ethernet@f0480000
OF_TYPE=network
OF_COMPATIBLE_0=brcm,genet-v5
OF_COMPATIBLE_N=1
OF_ALIAS_0=eth0 <==================
MODALIAS=of:NethernetTnetworkCbrcm,genet-v5
Yes, one can if one uses udev and can find something to identify the hw I/F with, my
cat /sys/class/net/eth0/device/uevent looks like:
DRIVER=fsl_dpa
MODALIAS=platform:dpaa-ethernet
Does not dpaa have a notion of Ethernet ports and those should have
proper information? Maybe that is part of your problem here, it should
have the OF_ALIAS information somehow available.
I cannot say ATM, but this lack of standard does not make it easier to rename I/F's in udev.
quoted
quoted
not sure mdev supports this, does it?
Our simple installer FS(initramfs) doesn't have either udev or mdev.
I don't know, but you could have a simple shell script that looks at
specific network device properties to decide on the naming and call
ifrename.
This reinventing of the wheel is what I am trying to avoid.
Embedded is all about being a special snowflake and re-inventing the
wheel, but having some desktop-like distribution user-space would
certainly allow you to re-invent other parts of the wheel.
quoted
quoted
I also noted that using status = "disabled" didn't work either to create a fix name scheme.
Even worse, all the eth I/F after gets renumbered. It seems to me there
is value in having stability in eth I/F naming at boot.
Then userspace(udev) can rename if need be.
Sure would like to known more about why this feature is not wanted ?
I found
https://patchwork.kernel.org/patch/4122441/
You quote policy as reason but surely it must be better to
have something stable, connected to the hardware name, than semirandom naming?
If the Device Tree nodes are ordered by ascending base register address,
my understanding is that you get the same order as far as
platform_device creation goes, this may not be true in the future if Rob
decides to randomize that, but AFAICT this is still true. This may not
work well with status = disabled properties being inserted here and
there, but we have used that here and it has worked for as far as I can
remember doing it.
I recall it is the order in which the eth alias appear that controls the naming,
not 100% sure though.
Aliases are not looked up at all by the platform bus code other that
with of_get_alias() and friends, it is the order in which the nodes are
declared in the Device Tree, preferably ordered by base address that
dictates the order in which platform devices are created.
quoted
Second, you might want to name network devices ethX, but what if I want
to name them ethernetX or fooX or barX? Should we be accepting a
mechanism in the kernel that would allow someone to name the interfaces
the way they want straight from a name being provided in Device Tree?
I just want to have stable boot names, aka ethX, which can defined in
the platforms DT. Then userspace can go from there to whatever it needs,
udev could possibly use these stable boot names to identify the I/F's to rename.
ATM, it is pretty hard to even use udev when /sys/class/net/eth0/device/uevent
can look different even for OF created interfaces.
network devices have a gazillion of other sysfs attributes that all make
them unique enough to create stable names.
quoted
Aliases are fine for providing relative stability within the Device Tree
itself and boot programs that might need to modify the Device Tree (e.g:
inserting MAC addresses) such that you don't have to encode logic to
search for nodes by compatible strings etc. but outside of that use
case, it seems to me that you can resolve every naming decision in
user-space.
Well, you can resolve MAC address assignment in user space too but most
will agree that is not convenient. I suggest it is also handy to have
some control of I/F enumeration(ethX that is) from platform code like DT.
If that is what you desire because you do not want to use user-space to
do that job, that is probably fine, it's open source after all, an not
every patch is a candidate for being included upstream. A patch doing
what you describe would likely be rejected again.
--
Florian
On Tue, 2018-10-23 at 13:07 -0700, Florian Fainelli wrote:
On 10/23/18 1:02 PM, Joakim Tjernlund wrote:
quoted
On Tue, 2018-10-23 at 11:20 -0700, Florian Fainelli wrote:
quoted
On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
quoted
On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
quoted
On 10/23/18 9:49 AM, Joakim Tjernlund wrote:
quoted
SPI (and others) has a way to define bus number in a aliases:
aliases {
ethernet4 = &enet4;
ethernet0 = &enet0;
ethernet1 = &enet1;
ethernet2 = &enet2;
ethernet3 = &enet3;
spi0 = &spi0
};
The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
I am looking for the same for ethernet devices:
ethernet4 = &enet4; /* should become eth4 */
ethernet0 = &enet0; /* should become eth0 */
but I cannot find something like that for eth devices.
Could such functionality be added?
It could, do we want and need to, no. You have the Ethernet alias in
/sys/class/net/*/device/uevent already that would allow you to perform
that (re)naming in user-space:
# cat /sys/class/net/eth0/device/uevent
DRIVER=bcmgenet
OF_NAME=ethernet
OF_FULLNAME=/rdb/ethernet@f0480000
OF_TYPE=network
OF_COMPATIBLE_0=brcm,genet-v5
OF_COMPATIBLE_N=1
OF_ALIAS_0=eth0 <==================
MODALIAS=of:NethernetTnetworkCbrcm,genet-v5
Yes, one can if one uses udev and can find something to identify the hw I/F with, my
cat /sys/class/net/eth0/device/uevent looks like:
DRIVER=fsl_dpa
MODALIAS=platform:dpaa-ethernet
Does not dpaa have a notion of Ethernet ports and those should have
proper information? Maybe that is part of your problem here, it should
have the OF_ALIAS information somehow available.
I cannot say ATM, but this lack of standard does not make it easier to rename I/F's in udev.
quoted
quoted
not sure mdev supports this, does it?
Our simple installer FS(initramfs) doesn't have either udev or mdev.
I don't know, but you could have a simple shell script that looks at
specific network device properties to decide on the naming and call
ifrename.
This reinventing of the wheel is what I am trying to avoid.
Embedded is all about being a special snowflake and re-inventing the
wheel, but having some desktop-like distribution user-space would
certainly allow you to re-invent other parts of the wheel.
quoted
quoted
quoted
I also noted that using status = "disabled" didn't work either to create a fix name scheme.
Even worse, all the eth I/F after gets renumbered. It seems to me there
is value in having stability in eth I/F naming at boot.
Then userspace(udev) can rename if need be.
Sure would like to known more about why this feature is not wanted ?
I found
https://patchwork.kernel.org/patch/4122441/
You quote policy as reason but surely it must be better to
have something stable, connected to the hardware name, than semirandom naming?
If the Device Tree nodes are ordered by ascending base register address,
my understanding is that you get the same order as far as
platform_device creation goes, this may not be true in the future if Rob
decides to randomize that, but AFAICT this is still true. This may not
work well with status = disabled properties being inserted here and
there, but we have used that here and it has worked for as far as I can
remember doing it.
I recall it is the order in which the eth alias appear that controls the naming,
not 100% sure though.
Aliases are not looked up at all by the platform bus code other that
with of_get_alias() and friends, it is the order in which the nodes are
declared in the Device Tree, preferably ordered by base address that
dictates the order in which platform devices are created.
I see, thanks.
quoted
quoted
Second, you might want to name network devices ethX, but what if I want
to name them ethernetX or fooX or barX? Should we be accepting a
mechanism in the kernel that would allow someone to name the interfaces
the way they want straight from a name being provided in Device Tree?
I just want to have stable boot names, aka ethX, which can defined in
the platforms DT. Then userspace can go from there to whatever it needs,
udev could possibly use these stable boot names to identify the I/F's to rename.
ATM, it is pretty hard to even use udev when /sys/class/net/eth0/device/uevent
can look different even for OF created interfaces.
network devices have a gazillion of other sysfs attributes that all make
them unique enough to create stable names.
That is kind of my point, there doesn't seem to be any stable source of info
that can be relied on. Each platform/driver is it own, DT/OF created I/F's should
look the same in /sys/class/net/eth0/device/uevent but that is not so.
I am sure I can find something though.
quoted
quoted
Aliases are fine for providing relative stability within the Device Tree
itself and boot programs that might need to modify the Device Tree (e.g:
inserting MAC addresses) such that you don't have to encode logic to
search for nodes by compatible strings etc. but outside of that use
case, it seems to me that you can resolve every naming decision in
user-space.
Well, you can resolve MAC address assignment in user space too but most
will agree that is not convenient. I suggest it is also handy to have
some control of I/F enumeration(ethX that is) from platform code like DT.
If that is what you desire because you do not want to use user-space to
do that job, that is probably fine, it's open source after all, an not
every patch is a candidate for being included upstream. A patch doing
what you describe would likely be rejected again.
--
Of course, but I didn't start this thread just to hack my own patch. I wanted
buy in from the community and that is not happening so I will rest now.
Thanks you for taking the time to discuss this,
Jocke
From: Michal Suchánek <hidden> Date: 2018-10-26 12:37:19
On Tue, 23 Oct 2018 11:20:36 -0700
Florian Fainelli [off-list ref] wrote:
On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
quoted
On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
quoted
I also noted that using status = "disabled" didn't work either to
create a fix name scheme. Even worse, all the eth I/F after gets
renumbered. It seems to me there is value in having stability in
eth I/F naming at boot. Then userspace(udev) can rename if need be.
Sure would like to known more about why this feature is not wanted ?
I found
https://patchwork.kernel.org/patch/4122441/
You quote policy as reason but surely it must be better to
have something stable, connected to the hardware name, than
semirandom naming?
If the Device Tree nodes are ordered by ascending base register
address, my understanding is that you get the same order as far as
platform_device creation goes, this may not be true in the future if
Rob decides to randomize that, but AFAICT this is still true. This
may not work well with status = disabled properties being inserted
here and there, but we have used that here and it has worked for as
far as I can remember doing it.
So this is unstable in several respects. First is changing the
enabled/disabled status in the deivecetrees provided by the kernel.
Second is if you have hardware hotplug mechanism either by firmware or
by loading device overlays.
Third is the case when the devicetree is not built as part of the
kernel but is instead provided by firmware that initializes the
low-level hardware details. Then the ordering by address is not
guaranteed nor is that the same address will be used to access the same
interface every time. There might be multiple ways to configure the
hardware depending on firmware configuration and/or version.
Second, you might want to name network devices ethX, but what if I
want to name them ethernetX or fooX or barX? Should we be accepting a
mechanism in the kernel that would allow someone to name the
interfaces the way they want straight from a name being provided in
Device Tree?
Clearly if there is text Ethernet1 printed above the Ethernet port we
should provide a mechanism to name the port Ethernet1 by default.
Aliases are fine for providing relative stability within the Device
Tree itself and boot programs that might need to modify the Device
Tree (e.g: inserting MAC addresses) such that you don't have to
encode logic to search for nodes by compatible strings etc. but
outside of that use case, it seems to me that you can resolve every
naming decision in user-space.
However, this is pushing platform-specific knowledge to userspace. The
way the Ethernet interface is attached and hence the device properties
usable for identifying the device uniquely are platform-specific.
On the other hand, aliases are universal when provided. If they are
good enough to assign a MAC address they are good enough to provide a
stable default name.
I think this is indeed forcing the userspace to reinvent several wheels
for no good reason.
What is the problem with adding the aliases?
Thanks
Michal
On Wed, 2018-10-24 at 08:22 +0200, Michal Suchánek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Tue, 23 Oct 2018 11:20:36 -0700
Florian Fainelli [off-list ref] wrote:
quoted
On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
quoted
On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
I also noted that using status = "disabled" didn't work either to
create a fix name scheme. Even worse, all the eth I/F after gets
renumbered. It seems to me there is value in having stability in
eth I/F naming at boot. Then userspace(udev) can rename if need be.
Sure would like to known more about why this feature is not wanted ?
I found
https://patchwork.kernel.org/patch/4122441/
You quote policy as reason but surely it must be better to
have something stable, connected to the hardware name, than
semirandom naming?
If the Device Tree nodes are ordered by ascending base register
address, my understanding is that you get the same order as far as
platform_device creation goes, this may not be true in the future if
Rob decides to randomize that, but AFAICT this is still true. This
may not work well with status = disabled properties being inserted
here and there, but we have used that here and it has worked for as
far as I can remember doing it.
So this is unstable in several respects. First is changing the
enabled/disabled status in the deivecetrees provided by the kernel.
Second is if you have hardware hotplug mechanism either by firmware or
by loading device overlays.
Third is the case when the devicetree is not built as part of the
kernel but is instead provided by firmware that initializes the
low-level hardware details. Then the ordering by address is not
guaranteed nor is that the same address will be used to access the same
interface every time. There might be multiple ways to configure the
hardware depending on firmware configuration and/or version.
quoted
Second, you might want to name network devices ethX, but what if I
want to name them ethernetX or fooX or barX? Should we be accepting a
mechanism in the kernel that would allow someone to name the
interfaces the way they want straight from a name being provided in
Device Tree?
Just to be clear, I am saying that we don't need to control the full
name of the Ethernet device, just the numerical id so one can tie eth0
to a fixed physical device.
Clearly if there is text Ethernet1 printed above the Ethernet port we
should provide a mechanism to name the port Ethernet1 by default.
quoted
Aliases are fine for providing relative stability within the Device
Tree itself and boot programs that might need to modify the Device
Tree (e.g: inserting MAC addresses) such that you don't have to
encode logic to search for nodes by compatible strings etc. but
outside of that use case, it seems to me that you can resolve every
naming decision in user-space.
However, this is pushing platform-specific knowledge to userspace. The
way the Ethernet interface is attached and hence the device properties
usable for identifying the device uniquely are platform-specific.
On the other hand, aliases are universal when provided. If they are
good enough to assign a MAC address they are good enough to provide a
stable default name.
I think this is indeed forcing the userspace to reinvent several wheels
for no good reason.
What is the problem with adding the aliases?
On Tue, 23 Oct 2018 11:20:36 -0700
Florian Fainelli [off-list ref] wrote:
quoted
On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
quoted
On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
quoted
quoted
I also noted that using status = "disabled" didn't work either to
create a fix name scheme. Even worse, all the eth I/F after gets
renumbered. It seems to me there is value in having stability in
eth I/F naming at boot. Then userspace(udev) can rename if need be.
Sure would like to known more about why this feature is not wanted ?
I found
https://patchwork.kernel.org/patch/4122441/
You quote policy as reason but surely it must be better to
have something stable, connected to the hardware name, than
semirandom naming?
If the Device Tree nodes are ordered by ascending base register
address, my understanding is that you get the same order as far as
platform_device creation goes, this may not be true in the future if
Rob decides to randomize that, but AFAICT this is still true. This
may not work well with status = disabled properties being inserted
here and there, but we have used that here and it has worked for as
far as I can remember doing it.
So this is unstable in several respects. First is changing the
enabled/disabled status in the deivecetrees provided by the kernel.
Second is if you have hardware hotplug mechanism either by firmware or
by loading device overlays.
Third is the case when the devicetree is not built as part of the
kernel but is instead provided by firmware that initializes the
low-level hardware details. Then the ordering by address is not
guaranteed nor is that the same address will be used to access the same
interface every time. There might be multiple ways to configure the
hardware depending on firmware configuration and/or version.
quoted
Second, you might want to name network devices ethX, but what if I
want to name them ethernetX or fooX or barX? Should we be accepting a
mechanism in the kernel that would allow someone to name the
interfaces the way they want straight from a name being provided in
Device Tree?
Clearly if there is text Ethernet1 printed above the Ethernet port we
should provide a mechanism to name the port Ethernet1 by default.
Yes, but then have a specific property that is flexible enough to
retrieve things like "vital product information". For DSA switches, we
have an optional "label" property which names the network device
directly like it would be found on the product's case. Ideally this
should be much more flexible such that it can point to the appropriate
node/firmware service/whatever to get that name, which is what some
people have been working on lately, see [1].
[1]: https://lkml.org/lkml/2018/8/14/1039
The point is don't re-purpose the aliases which is something that exists
within Device Tree to basically provide a shorter path to a specific set
of nodes for the boot program to mangle and muck with instead of having
to resolve a full path to a node. At least that is how I conceive it.
Now what complicates the matter is that some OSes like Linux tend to use
it to also generate seemingly stable index for peripherals that are
numbered by index such as SPI, I2C, etc buses, which is why we are
having this conversation here, see below for more.
quoted
Aliases are fine for providing relative stability within the Device
Tree itself and boot programs that might need to modify the Device
Tree (e.g: inserting MAC addresses) such that you don't have to
encode logic to search for nodes by compatible strings etc. but
outside of that use case, it seems to me that you can resolve every
naming decision in user-space.
However, this is pushing platform-specific knowledge to userspace. The
way the Ethernet interface is attached and hence the device properties
usable for identifying the device uniquely are platform-specific.
There is always going to be some amount of platform specific knowledge
to user-space, what matters is the level of abstraction that is
presented to you.
On the other hand, aliases are universal when provided. If they are
good enough to assign a MAC address they are good enough to provide a
stable default name.
We are not talking about the same aliases then. The special Device Tree
node named "aliases" is a way to create shorted Device Tree node paths,
it is not by any means an equivalent for what I would rather call a
"label", or "port name" or silk screen annotation on a PCB for instance.
I think this is indeed forcing the userspace to reinvent several wheels
for no good reason.
udev or systemd will come up with some stable names for your network
device right off the bat. If you are deeply embedded maybe you don't
want those, but then use something like the full path in /sys to get
some stable names based on the SoC's topology.
What is the problem with adding the aliases?
aliases is IMHO the wrong tool for the job because it is too limiting,
you want it to be used to have Ethernet controller instance N to be
named "ethN", what if someone tomorrows says, no this is not good, I
want the aliases to automatically name my network devices
"ethernet-controllerN" or "blahblahN"? You see where I am getting with that?
And yes, I do realize that Linux has traditionally named Ethernet
adapters ethN, but also allows people to name interfaces just the way
they want even from within the drivers themselves.
Now imagine your platform uses ACPI, and there are no aliases there to
point a node with a shorter name, how we would go about naming your
Ethernet controller unless there is a specific VPD/label/sticker
property that can be somehow be retried?
--
Florian
From: Michal Suchánek <hidden> Date: 2018-10-28 18:27:00
On Fri, 26 Oct 2018 15:57:15 -0700
Florian Fainelli [off-list ref] wrote:
On 10/23/18 11:22 PM, Michal Suchánek wrote:
quoted
On Tue, 23 Oct 2018 11:20:36 -0700
Florian Fainelli [off-list ref] wrote:
quoted
On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
quoted
On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
quoted
quoted
I also noted that using status = "disabled" didn't work either to
create a fix name scheme. Even worse, all the eth I/F after gets
renumbered. It seems to me there is value in having stability in
eth I/F naming at boot. Then userspace(udev) can rename if need
be.
Sure would like to known more about why this feature is not
wanted ?
I found
https://patchwork.kernel.org/patch/4122441/
You quote policy as reason but surely it must be better to
have something stable, connected to the hardware name, than
semirandom naming?
If the Device Tree nodes are ordered by ascending base register
address, my understanding is that you get the same order as far as
platform_device creation goes, this may not be true in the future
if Rob decides to randomize that, but AFAICT this is still true.
This may not work well with status = disabled properties being
inserted here and there, but we have used that here and it has
worked for as far as I can remember doing it.
So this is unstable in several respects. First is changing the
enabled/disabled status in the deivecetrees provided by the kernel.
Second is if you have hardware hotplug mechanism either by firmware
or by loading device overlays.
Third is the case when the devicetree is not built as part of the
kernel but is instead provided by firmware that initializes the
low-level hardware details. Then the ordering by address is not
guaranteed nor is that the same address will be used to access the
same interface every time. There might be multiple ways to
configure the hardware depending on firmware configuration and/or
version.
quoted
Second, you might want to name network devices ethX, but what if I
want to name them ethernetX or fooX or barX? Should we be
accepting a mechanism in the kernel that would allow someone to
name the interfaces the way they want straight from a name being
provided in Device Tree?
Clearly if there is text Ethernet1 printed above the Ethernet port
we should provide a mechanism to name the port Ethernet1 by
default.
Yes, but then have a specific property that is flexible enough to
retrieve things like "vital product information". For DSA switches, we
have an optional "label" property which names the network device
directly like it would be found on the product's case. Ideally this
should be much more flexible such that it can point to the appropriate
node/firmware service/whatever to get that name, which is what some
people have been working on lately, see [1].
[1]: https://lkml.org/lkml/2018/8/14/1039
That's nice for something unique per-device like MAC address. However,
for something per-model like port labels DT properties should suffice.
The point is don't re-purpose the aliases which is something that
exists within Device Tree to basically provide a shorter path to a
specific set of nodes for the boot program to mangle and muck with
instead of having to resolve a full path to a node. At least that is
how I conceive it.
Now what complicates the matter is that some OSes like Linux tend to
use it to also generate seemingly stable index for peripherals that
are numbered by index such as SPI, I2C, etc buses, which is why we are
having this conversation here, see below for more.
quoted
quoted
Aliases are fine for providing relative stability within the Device
Tree itself and boot programs that might need to modify the Device
Tree (e.g: inserting MAC addresses) such that you don't have to
encode logic to search for nodes by compatible strings etc. but
outside of that use case, it seems to me that you can resolve every
naming decision in user-space.
However, this is pushing platform-specific knowledge to userspace.
The way the Ethernet interface is attached and hence the device
properties usable for identifying the device uniquely are
platform-specific.
There is always going to be some amount of platform specific knowledge
to user-space, what matters is the level of abstraction that is
presented to you.
quoted
On the other hand, aliases are universal when provided. If they are
good enough to assign a MAC address they are good enough to provide
a stable default name.
We are not talking about the same aliases then. The special Device
Tree node named "aliases" is a way to create shorted Device Tree node
paths, it is not by any means an equivalent for what I would rather
call a "label", or "port name" or silk screen annotation on a PCB for
instance.
However, if the kernel ethN names are deterministic based on something
like aliases it is trivial to translate them to "port name". As it is
they are pretty much random which is the issue aliases *can* solve.
quoted
I think this is indeed forcing the userspace to reinvent several
wheels for no good reason.
udev or systemd will come up with some stable names for your network
device right off the bat.
As has been already pointed out these names are not stable for various
reasons. *Making* them stable is the whole point of this discussion.
If you are deeply embedded maybe you don't
want those, but then use something like the full path in /sys to get
some stable names based on the SoC's topology.
However, it some devices might be disabled depending on the device
configuration generating stable names is not that easy. Also if bus
topology may differ depending on device/firmware configuration you
cannot assign stable names based just on /sys hierarchy. Also it is
said that /sys hierarchy is not an ABI in the kernel docs so you should
not base your stable device names which *are* an ABI on the
unstable /sys hierarchy.
quoted
What is the problem with adding the aliases?
aliases is IMHO the wrong tool for the job because it is too limiting,
you want it to be used to have Ethernet controller instance N to be
named "ethN", what if someone tomorrows says, no this is not good, I
want the aliases to automatically name my network devices
"ethernet-controllerN" or "blahblahN"? You see where I am getting
with that?
Then you can write udev rule to translate ethN to blahlbahN and so long
as the ethN is stable the translation is stable as well. Alternatively
you might want to use a different devicetree property if one existed.
And yes, I do realize that Linux has traditionally named Ethernet
adapters ethN, but also allows people to name interfaces just the way
they want even from within the drivers themselves.
Now imagine your platform uses ACPI, and there are no aliases there to
point a node with a shorter name, how we would go about naming your
Ethernet controller unless there is a specific VPD/label/sticker
property that can be somehow be retried?
There is biosdevname for that which uses proprietary BIOS extensions to
look up device names in BIOS.
Thanks
Michal