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