Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 16.04.2016 um 16:15 schrieb Xen:

The backlash against this renaming may have been enormous but people
just say "oh, that's political". Systemd in general has been the single
thing with the most opposition in the history of Linux that I'm aware of.


stop spreading uneducated nonsense, the NIC renaming was imßplemented 
*long before* systemd took this part over too


https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming






signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 16-04-16 14:27:

>> So at that point, I am immediately stuck. This was in large part about
>> people who are NOT expert administrators, remember?
> 
> they don't care about how their interfaces are named

And this is the lie to begin with. You people say this so you can keep
on doing what you do.

You don't ASK those users. You just assume. And when they tell you, you
don't listen.

Linux is not a system where you can remain in a Nice GUI until the end
of the day, to begin with.

Practically everyone will have to use command line commands. Many many
guides require a form of "sudo ". Many guides require the user to
edit configuration files, and whatever you say, this is usually more
convenient using the command line because browsing the FHS in a GUI is
just not very very pleasant due to the way that it is constructed.

The backlash against this renaming may have been enormous but people
just say "oh, that's political". Systemd in general has been the single
thing with the most opposition in the history of Linux that I'm aware of.

Lennart Poettering calls it "the right technical solution in the context
of politically minded objections" or something of the kind (my words,
paraphrasing).

Linux people in general espouse this myth that the Linux user is at once
a complete novice who doesn't care, and at the same time someone who
should be able to learn Vi in three days.

Installing Linux typically means you care to begin with. Unless someone
else does it for you and you have no say in it.

The idea that someone who cares enough to install Linux then won't care
AT ALL about the internals of the system is something entirely
inaccurate and flies in the face of the reality of the kind of people
who actually like Linux.

Not just do you say "doesn't care a LOT" -- you say "doesn't care AT ALL".

You try to treat this average or novice user as some kind of ideal
person who cares /nothing at all/ about system internals. Not just 5%,
but 0%.

This is a myth because Linux is not that kind of system. Mac users? Maybe.

But if you told them, they'd say "ooh yeah, that's not very nice".

That's instant caring. That's an instant level of caring.

The approach to making Linux easy to use with the GUI has generally been
of the kind "cross our fingers and hope he doesn't press ctrl-alt-f2".

Just last night I had to go to a TTY to kill a game that had hung in the
loader. There is a Windows game that runs in Wine but not exactly
flawlessly and I require a TTY to kill it if it happens. Not the game
itself, but the loader, which takes 100% CPU and renders the redrawing
of the screen defunct. That in itself is advanced usage and I am not
doing anything advanced.

I try to start a game. Boom, gone is the ease of use of Linux.

I kill the program. For no reason whatsoever I am logged out of my
session the moment I press ALT-F7 to return to the GUI.

Like, what? If I had been writing anything I would have lost my work now.

You really think you can use Linux to any reasonable degree without
being confronted with system internals?

My kinda person is MORE average than that ideal user that doesn't really
exist. The user that does, at some point, regularly use a shell (command
line) is basically what can be considered the "ordinary" Linux user.

The user that at one point learns about "ifconfig" is more average. If
"nmcli" wasn't so hard to use, people would also be using that program
to configure network or do stuff about it. If it had a nice (ncurses) GUI.

You cannot hold in all reasonability that the use case exists for linux
where you never have to open a shell if it is your own system.

You cannot maintain that a user will never encounter Bash or whatever
shell there is.

If this was my girlfriend (if I had one) (which I may soon do, I guess)
and she'd be stuck in something (and I guess it'd happen regularly) it
would be a lot of support needed for her and I would *try* to teach her
some of the internals. But It'd be very hard I guess (for the type of
girl she is).

Nevertheless people like pretty. Just recently in #nm an expert user
went to great lengths to change the udev database so his NetworkManager
applet would show a nicer name instead of a very long device
identification label.

If and when people are confronted with enp3s0, it will be completely
incomprehensible. What if a guide requires using ifconfig? What if a
guide requires manually configuring something?

You are crossing your fingers and hope it never happens.

You people seem to separate humanhood into two different segments:
either you are too novice and too stupid to understand anything, or you
require having immense skill to do the most basic things.


So either you are the person that has 5000 NICs in his machine and
requires ultimately stable addressing, or you are a turd with no brain
who can't care less about what goes on inside his system.

Or her system. Don't forget the girls. I happen to know girls. I happen
to know they do 

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 16.04.2016 um 14:20 schrieb Xen:

So I deleted your email that belonged to this piece and then tried to
find what you wrote about myself. But the beginning of it is of course
that Debian/Ubuntu doesn't have "sysconfig" directory. I know OpenSUSE
does, but Debian doesn't.


that is all completly *off topic* here


So at that point, I am immediately stuck. This was in large part about
people who are NOT expert administrators, remember?


they don't care about how their interfaces are named


There is no /etc/init.d/network, but there is networking, and
/etc/default/networking, but no hint of anything.

I check
/etc/systemd/system/network-online.target.wants/networking.service and
there is no hint for anything either.

I wanted, for an ordinary user, to generate a mapping, but now you're
talking about having the skills to be a network or system administrator


the ordinary user is not affected at all by the whole topic just because 
the only thing he cares is that he has a network connection, what piece 
of software made it, how interfaces are named and even what a interface 
is don't bother the ordinary user


how you configure network on your distribution is really up to you

Google "debian configure network ifcfg files"

http://www.cyberciti.biz/faq/linux-configure-a-static-ip-address-tutorial/
http://www.cyberciti.biz/faq/setting-up-an-network-interfaces-file/

Google "debian rename network interfaces by MAC"
http://unix.stackexchange.com/questions/28878/changing-the-names-of-network-interfaces-debian-wheezy

http://www.cyberciti.biz/faq/linux-configure-a-static-ip-address-tutorial/



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 16-04-16 12:07:
> 
> 
> Am 16.04.2016 um 06:46 schrieb Andrei Borzenkov:
>> 16.04.2016 03:14, Reindl Harald пишет:
>>>
>>>
>>> Am 15.04.2016 um 21:06 schrieb Xen:
 If you cannot give me a default mapping automatically, why not allow me
 to generate one easily? Is there a tool that can take the current
 device
 and produce the list I proposed?
>>>
>>> just use network.service aka /etc/init.d/network, enter the MAC and you
>>> are done - so what is the problem you can't solve for hundret network
>>> devices
>>
>> Motherboard dies and is replaced. All your interface names disappear
> 
> and the same happens when you change the server in most cases with all
> that "predictable" stuff because it's proven to be not that predictable
> when changing hardware and you are not married with a specific vendor
> 
> the old world was at least able to give you a predictable "eth0" on a
> new machine after the initial setup
> 
>> This makes rather challenging affair requiring relatively high
>> administration skills out of mundane technical task
> 
> high administration skills?
> 
> just connect to ILO while have a trained monkey on the phone who tells
> you which of the labeled cables he put in at the moment - sorry but
> besides that this happens very rarely at all but if you can't cope with
> it you lack the skills for beeing a sysadmin at all

So I deleted your email that belonged to this piece and then tried to
find what you wrote about myself. But the beginning of it is of course
that Debian/Ubuntu doesn't have "sysconfig" directory. I know OpenSUSE
does, but Debian doesn't.

So at that point, I am immediately stuck. This was in large part about
people who are NOT expert administrators, remember?

There is no /etc/init.d/network, but there is networking, and
/etc/default/networking, but no hint of anything.

I check
/etc/systemd/system/network-online.target.wants/networking.service and
there is no hint for anything either.

I wanted, for an ordinary user, to generate a mapping, but now you're
talking about having the skills to be a network or system administrator.

I try to search for it but don't find anything. So I go now to ask in
#debian.

Of course we're back at the "man systemd.link" that we started with.

Which requires MAC addresses or volatile PCI bus addresses.

He also says: "renaming via udev rules (NAME="") also works, as long as
it's done before 80-*.rules". But I'd have to dive into that before I
know how to do that (it's not like it's obvious or anything).

In this situation, if I have to use something that obtuse to get the
configuration I want, I would rather just turn the whole thing off.

I don't want to use configuration files I can only know about and learn
how to write by reading man pages I don't know how to find unless I am
asking around.

There is no "best of both worlds" here. You cannot turn the systemd
thing on AND have an easy time.

> DEVICE=lan-guest
> HWADDR=ac:16:2d:a1:74:ec
> TYPE=Ethernet
> BOOTPROTO=static
> ONBOOT=yes
> ARPCHECK=no
> NM_CONTROLLED=no
> USERCTL=no
> IPV6INIT=no

This creates a systemd mapping file? How does that work?

You imply that systemd/udev is going to use this to rename?

So the reality is still and remains to this day:


A regular non-hardcore user is not going to have any kind of agreeable
system because doing so requires doing stuff that is just too hard to do
with too little benefits to worry about it, OR

That person is just going to turn the whole thing off if she knows about it.

I would *never* recommend anyone to dive into this configuration and do
it by hand the way it is.

If it was a single configuration file in /etc/network, perhaps I would.
But depending on MAC addresses is not pleasant and requires a level of
knowledge an ordinary user should not need to have. PCI path is even
worse. Using the currently available name (ie. enp3s0) would be agreeable.

If you can give me a system where I can enter enp3s0 and turn it into
eth0 or ethernet0, I'm okay with that.

However it is not a stable thing because these addresses change
depending on what hardware I take out.

So for me if you'd say "use first available ethernet device as eth0 and
first available wlan device as wlan0" I'd be yes please, but at that
point there is no benefit to the systemd thing.

So this magic default system,: where is the benefit?

There is still no benefit to it. There is just no benefit to it.

It HAS no benefit for people with one ethernet NIC and one wlan NIC.

It just doesn't. It is a detriment.

At the very least you could ensure that you needed to do nothing special
to have a system like you had before.

At the very least you could condense these network name and then people
wouldn't bother. Then you'd have a system with improved names over
eth0/wlan0.

Then people would actually like you for doing that, a bit.

Now?

"All I wanna say is that, they don't really care about us."

Oh and:

"so what is the problem you can't 

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 16.04.2016 um 06:46 schrieb Andrei Borzenkov:

16.04.2016 03:14, Reindl Harald пишет:



Am 15.04.2016 um 21:06 schrieb Xen:

If you cannot give me a default mapping automatically, why not allow me
to generate one easily? Is there a tool that can take the current device
and produce the list I proposed?


just use network.service aka /etc/init.d/network, enter the MAC and you
are done - so what is the problem you can't solve for hundret network
devices


Motherboard dies and is replaced. All your interface names disappear


and the same happens when you change the server in most cases with all 
that "predictable" stuff because it's proven to be not that predictable 
when changing hardware and you are not married with a specific vendor


the old world was at least able to give you a predictable "eth0" on a 
new machine after the initial setup



This makes rather challenging affair requiring relatively high
administration skills out of mundane technical task


high administration skills?

just connect to ILO while have a trained monkey on the phone who tells 
you which of the labeled cables he put in at the moment - sorry but 
besides that this happens very rarely at all but if you can't cope with 
it you lack the skills for beeing a sysadmin at all




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Andrei Borzenkov]

16.04.2016 03:14, Reindl Harald пишет:
> 
> 
> Am 15.04.2016 um 21:06 schrieb Xen:
>> If you cannot give me a default mapping automatically, why not allow me
>> to generate one easily? Is there a tool that can take the current device
>> and produce the list I proposed?
> 
> just use network.service aka /etc/init.d/network, enter the MAC and you
> are done - so what is the problem you can't solve for hundret network
> devices

Motherboard dies and is replaced. All your interface names disappear.
This makes rather challenging affair requiring relatively high
administration skills out of mundane technical task.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 15.04.2016 um 21:06 schrieb Xen:

If you cannot give me a default mapping automatically, why not allow me
to generate one easily? Is there a tool that can take the current device
and produce the list I proposed?


just use network.service aka /etc/init.d/network, enter the MAC and you 
are done - so what is the problem you can't solve for hundret network 
devices in the time you wrote a lot of mails?


[root@srv-rhsoft:/etc/sysconfig/network-scripts]$ cat ifcfg-lan-guest
DEVICE=lan-guest
HWADDR=ac:16:2d:a1:74:ec
TYPE=Ethernet
BOOTPROTO=static
ONBOOT=yes
ARPCHECK=no
NM_CONTROLLED=no
USERCTL=no
IPV6INIT=no

[root@srv-rhsoft:/etc/sysconfig/network-scripts]$ cat ifcfg-lan-phone
DEVICE=lan-phone
HWADDR=ac:16:2d:a1:74:ef
TYPE=Ethernet
BOOTPROTO=static
ONBOOT=yes
ARPCHECK=no
NM_CONTROLLED=no
USERCTL=no
IPV6INIT=no

[root@srv-rhsoft:/etc/sysconfig/network-scripts]$ cat ifcfg-lan-tv
DEVICE=lan-tv
HWADDR=ac:16:2d:a1:74:ee
TYPE=Ethernet
BOOTPROTO=static
ONBOOT=yes
ARPCHECK=no
NM_CONTROLLED=no
USERCTL=no
IPV6INIT=no

[root@srv-rhsoft:~]$ ifconfig
br-guest: flags=67  mtu 1500
inet 192.168.10.1  netmask 255.255.255.0  broadcast 192.168.10.255
ether 28:92:4a:2b:5d:45  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br-lan: flags=4675  mtu 1500
inet 192.168.2.2  netmask 255.255.255.0  broadcast 192.168.2.255
ether 28:92:4a:2b:5d:44  txqueuelen 1000  (Ethernet)
RX packets 200795  bytes 13539651 (12.9 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 361993  bytes 348652911 (332.5 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br-wan: flags=67  mtu 1500
inet 62.178.103.85  netmask 255.255.255.0  broadcast 
255.255.255.255

ether 00:50:8d:b5:cc:de  txqueuelen 1000  (Ethernet)
RX packets 19907295  bytes 13469242158 (12.5 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 8931216  bytes 2759476933 (2.5 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lan-guest: flags=4099  mtu 1500
ether ac:16:2d:a1:74:ec  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device memory 0xf798-f79f

lan-phone: flags=67  mtu 1500
ether ac:16:2d:a1:74:ef  txqueuelen 1000  (Ethernet)
RX packets 18846  bytes 4093274 (3.9 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 50325  bytes 6833909 (6.5 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 3
device memory 0xf780-f787

lan-spare: flags=4099  mtu 1500
ether ac:16:2d:a1:74:ed  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device memory 0xf790-f797

lan-tv: flags=4099  mtu 1500
ether ac:16:2d:a1:74:ee  txqueuelen 1000  (Ethernet)
RX packets 1604  bytes 389611 (380.4 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 7863  bytes 1345947 (1.2 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device memory 0xf788-f78f

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
loop  txqueuelen 1  (Lokale Schleife)
RX packets 677749  bytes 137663241 (131.2 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 677749  bytes 137663241 (131.2 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vmnet1: flags=67  mtu 1500
ether 00:50:56:c0:00:01  txqueuelen 1000  (Ethernet)
RX packets 24579  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 7133198  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vmnet8: flags=4163  mtu 1500
inet 192.168.196.2  netmask 255.255.255.0  broadcast 
192.168.196.255

ether 00:50:56:c0:00:08  txqueuelen 1000  (Ethernet)
RX packets 3896512  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 7861144  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vpn-client: flags=4163  mtu 1472
inet 10.0.0.241  netmask 255.255.255.0  broadcast 10.0.0.255
ether 

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Andrei Borzenkov schreef op 13-04-16 05:39:
> Yes. And I do not see how all this information is expected to be stuffed
> into 14 characters available for interface name, or even less if we
> account to VLAN numbers.
> 
> I am not aware of any OS that tries to do it. All of them maintain
> persistent association between interface names and hardware
> characteristics; most use physical topology, but this is not really
> mandatory. Interface names themselves are usually allocated on the first
> come first serve basis. This gives reasonable behavior for small systems
> (where existing interface will always get the same name irrespectively
> of how it is connected) and stable names for large systems.
> 
> That is what we used in the past as well in form of udev rules. And any
> answer "but you can easily disable predictable names" is hypocritical
> because the whole infrastructure to maintain such name database was
> ripped out, so anyone who disables predictable names is forced to
> reinvent the wheel and reimplement it. Which by far exceeds what average
> user is capable of. So average user simply has no choice.


What you are saying is that most OSes keep a record on disk of an
association they have chosen at some point in time, right.

And that you can either use physical topology for this, but other device
identification measures are possible too.



The thing what I am currently thinking just comes down on three things:

1. an interface name is not the place where a hardware address needs to
   be registered, kept, maintained, or encoded. The name itself must be
   an alias.

2. this alias is the place to find and access the root device, if any
   device is configured with multiple ports or virtual devices/ports,
   that is an addressing following the resolution of the alias, not as
   part of it

3. persistent mapping may be preferable. But if the mapping is going to
   be redone at every boot, at least make it reasonably persistent
   across reboots, but don't expect it to be the holy grail. If people
   need a truly persistent mapping for persistent hardware (addresses)
   they should create it themselves or operating system software should
   cater to its configuration. For instance.

If you cannot give me a default mapping automatically, why not allow me
to generate one easily? Is there a tool that can take the current device
and produce the list I proposed?

Is there anything against me using that list as a persistent mapping I
device myself? Can this be automated?

Is there a way to generate a (udev) config that will bind my network
device (ep3s0, for instance) to eth0 or ethernet0?

Is any of this made easier? Udev rules are persistent mappings, or could be.

Why not have an operating system installer generate this persistent mapping?


Andrei suggests that you can't:

> And any answer "but you can easily disable predictable names" is
> hypocritical because the whole infrastructure to maintain such name
> database was ripped out, so anyone who disables predictable names is
> forced to reinvent the wheel and reimplement it. Which by far exceeds
> what average user is capable of. So average user simply has no choice.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Greg KH schreef op 13-04-16 05:04:
> On Wed, Apr 13, 2016 at 02:42:29AM +0200, Xen wrote:
>> When you say that probing on the PCI bus never ends, and if we are
>> talking not about some form of hotplugging, then I really wonder what
>> you're on about ;-) because I do think the kernel has a limited set of
>> probes that it can perform, and at some point it is going to quit.
> 
> Not if it is interrupt driven, the kernel only responds to devices when
> they show up, it doesn't know how many devices are going to be ever
> found.
> 
>> It seems clear that some things are only going to be done once.
> 
> "once"?

Okay so I did just a very small amount of reading for your pleasure and
amusement.

I quote:

"There are two problems to be solved for network device drivers.
Firstly, not all of the network device drivers built into the Linux
kernel will have devices to control. Secondly, the ethernet devices in
the system are always called /dev/eth0, /dev/eth1 and so on, no matter
what their underlying device drivers are. The problem of ``missing''
network devices is easily solved. As the initialization routine for each
network device is called, it returns a status indicating whether or not
it located an instance of the controller that it is driving. If the
driver could not find any devices, its entry in the device list pointed
at by dev_base is removed. If the driver could find a device it fills
out the rest of the device data structure with information about the
device and the addresses of the support functions within the network
device driver."


So yes, drivers are tried one by one and they try to find devices they
can manage. When they cannot, they are removed from the list and never
tried again.

"never"? Yes, not ever again during the running of the system.

Not a mention of any waiting needing to be done and the entire document
only mentions "at boot time" -- this is not a thing that happens "after
boot".

Another indication:

"The second problem, that of dynamically assigning ethernet devices to
the standard /dev/ethN device special files is solved more elegantly.
There are eight standard entries in the devices list; one for eth0, eth1
and so on to eth7. The initialization routine is the same for all of
them, it tries each ethernet device driver built into the kernel in turn
until one finds a device. When the driver finds its ethernet device it
fills out the ethN device data structure, which it now owns. It is also
at this time that the network device driver initializes the physical
hardware that it is controlling and works out which IRQ it is using,
which DMA channel (if any) and so on. A driver may find several
instances of the network device that it is controlling and, in this
case, it will take over several of the /dev/ethN device data structures.
Once all eight standard /dev/ethN have been allocated, no more ethernet
devices will be probed for."

Does THAT sound like for-ever trying to find more devices? No, it
doesn't at all.

It's an old document (1999) but I think nothing ever changed about that.
("nothing" -- yes, nothing that fundamentally changed this model).

See I'm helping you here with your clever words. Sometimes people call
that "inb4" but I hate that acronym.

Ethernet device discovery ENDS at a certain point which is pretty clear
from this document.


I do not question your expertise. I question your sincerity here.

Device drivers are being asked to POLL for devices -- THIS IS NOT EVENT
DRIVEN.

> Not if it is interrupt driven, the kernel only responds to devices
> when they show up, it doesn't know how many devices are going to be
> ever found.

You didn't say whether it was event driven, so technically you never
lied. You were however creating a thought experiment about something
that isn't true.

Device polling is not interrupt driven. It seems clear these device
drivers perform their functions of discovery in a timely fashion, and it
is not an everlasting process at all.

Even if it works using bios callbacks (I don't know) it is still not
event driven.

I could look at the source for the driver of my own device, you know?
That would amuse you even more, I'm sure.


>> So I am not sure what you are alluding to. If there is some theoretical
>> tail (and it has not to do with hotplugging) I'm not sure if it is ever
>> going to be relevant here. If there is a theoretical tail, the system
>> cannot wait for it anyway.
> 
> The issue is that you need to create a system that allows devices to
> show up whenever they decide to show up, you can't "wait around" for
> anything as you never know just how long, or what will, or will not,
> show up.

This "showing up" -- you pretend or insinuate or imply here that these
devices decide to do that thing on their own whenever they have had a
nice cup of tea they liked.

No, the device driver polls for it.

Also, you didn't say that this was the reality now, only that I need to
create such a system. Again, not technically lying ;-).

You never said 

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 15-04-16 18:06:
> 
> 
> Am 15.04.2016 um 18:02 schrieb Xen:
>> Reindl Harald schreef op 15-04-16 17:55:
> so 3 seconds is unacceptable and the idea ist a joke in general
> because
> you wait for something possibly happen while you don't know how
> long you
> have to wait and jsut hope for luck - that's not a good design and
> won't
> bew accepted anywhere

 You are the only one taking 3 seconds seriously as something to hang
 onto just so you can say that I am full of shit
>>>
>>> it don't matter *how long* you wait for something you don't know if it
>>> ever appears and how long it take to appear - period
>>
>> That's why you *don't* and you just proceed with it in line with the
>> current booting of the system, you just postpone the renaming to a later
>> stage where you rename all in one go, instead of each time a device is
>> discovered
> 
> * you don't know *when* that later is
> * until that has happened all other services have to wait
> * this won#t work in real life
> * if it would work that way it would have been implemented
> 
> HONESTLY: i *hate* that predictable stuff too, i don't need it, i
> disable it and would prefer that the ones who *really* need it has to
> enable it instead you need to touch your config on the majority of
> machines which have only one NIC (since current mainboards don't have
> dualport NICs as some yaers ago)
> 
> BUT: i would be careful to pretend i have a doable solution which works
> for *all* usecases when people working for many years on the kernel did
> not found one

Well thank you for these kind words.

But what you say is just not entirely accurate.

You do not respond to this statement that by default, and by definition,
almost, networking services have to wait on networking hardware anyway.

The only time when what you say would make sense, if is there exists the
condition where *some* networking devices are allowed to show up at a
later time, and networking *services* are capable of dealing with that.
I do not think that is common reality and current boot systems are also
not designed around that. I mean, am I so stupid here or is this just
common sense?

Show me the system that can handle networking devices showing up after
network service start on those devices.

Either it knows what to wait for, or it will fail.

So not all other services would have to wait, only network services, and
you do NOT wait, you just go ahead.

At least if what I say makes sense, but what you have said until now
does not disprove that. And there are other solutions as well.

*The udev solution that uses biosdevname (program) falls completely
along the line of what I have proposed here and it already exist, it is
packaged, and apparently it works*. It is apparently a udev rule that
renames devices one by one (in the all_ethX policy) provided there is no
hotplugging.

If this system already exists and demonstrably works, why are you
battling against it? Just because I am stupid or have a big mouth???

> * if it would work that way it would have been implemented

Not if political choices are being made. Conversely, only if those
kernel/systemd developers are somehow infallable beings that never make
a partial choice.

> BUT: i would be careful to pretend i have a doable solution which
> worksfor *all* usecases when people working for many years on the
> kernel did not found one

That entirely depends on what interests they are trying to harmonize
with each other and this is a willfull choice.

If you want every house to have a sink, and you also want every house
for the new owners to choose their own sink, you will have a problem
because these things cannot be united.

These designers have wanted ALL linux systems to have like hardware
addresses encoded into network device names.

Andrei suggested that this is just impossible to begin with.

He also suggested that other vendors have different solutions.

For instance, Windows from what I know keeps a track record of devices
and only changes something about their configuration if they suddenly go
missing or new ones appear.

The Linux kernel / system does not normally maintain persistent records
of what hardware has been found and retries the same procedures on every
boot.

Even simply maintaining a saved mapping of
hardware-address-to-device-names would instantly solve this issue
provided you provide for a way to handle mutations.

That is because if hardware-addresses in this case are reliable and
persistent, the device names they are mapped to would be identical on
each boot as it would not depend on the time the driver or device made
itself known.

Gives its own complications but this is what Windows has done (I believe).

Moreoever you can also use different froms of identification such as
vendor ID and all of that. You don't have to use hardware address
exclusively.

If I remove a device from my slot the sound card in the next slot will
have a different address 

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 15.04.2016 um 18:02 schrieb Xen:

Reindl Harald schreef op 15-04-16 17:55:

so 3 seconds is unacceptable and the idea ist a joke in general because
you wait for something possibly happen while you don't know how long you
have to wait and jsut hope for luck - that's not a good design and won't
bew accepted anywhere


You are the only one taking 3 seconds seriously as something to hang
onto just so you can say that I am full of shit


it don't matter *how long* you wait for something you don't know if it
ever appears and how long it take to appear - period


That's why you *don't* and you just proceed with it in line with the
current booting of the system, you just postpone the renaming to a later
stage where you rename all in one go, instead of each time a device is
discovered


* you don't know *when* that later is
* until that has happened all other services have to wait
* this won#t work in real life
* if it would work that way it would have been implemented

HONESTLY: i *hate* that predictable stuff too, i don't need it, i 
disable it and would prefer that the ones who *really* need it has to 
enable it instead you need to touch your config on the majority of 
machines which have only one NIC (since current mainboards don't have 
dualport NICs as some yaers ago)


BUT: i would be careful to pretend i have a doable solution which works 
for *all* usecases when people working for many years on the kernel did 
not found one




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 15-04-16 17:55:
> 
> 
> Am 15.04.2016 um 17:48 schrieb Xen:
>> Reindl Harald schreef op 13-04-16 10:24:
>>> 4xHDD raid-10, hardware from 2011
>>> Startup finished in 660ms (kernel) + 5.380s (initrd) + 12.769s
>>> (userspace) = 18.810s
>>>
>>> os on sd-card
>>> Startup finished in 375ms (kernel) + 4.306s (initrd) + 8.323s
>>> (userspace) = 13.005s
>>>
>>> so 3 seconds is unacceptable and the idea ist a joke in general because
>>> you wait for something possibly happen while you don't know how long you
>>> have to wait and jsut hope for luck - that's not a good design and won't
>>> bew accepted anywhere
>>
>> You are the only one taking 3 seconds seriously as something to hang
>> onto just so you can say that I am full of shit
> 
> it don't matter *how long* you wait for something you don't know if it
> ever appears and how long it take to appear - period

That's why you *don't* and you just proceed with it in line with the
current booting of the system, you just postpone the renaming to a later
stage where you rename all in one go, instead of each time a device is
discovered.

The thing I talked about was not any form of "sleep".

Even Greg thought it was not completely out of the ordinary.

If you can produce for me systems that see networking devices added
after they have already been tried to "up" - meaning the software
configuration (firewall, routing) is being started on non-existing
devices, fine. Produce that list.

Show me those systems where not all devices are present at network up time.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 15.04.2016 um 17:42 schrieb Xen:

Greg KH schreef op 13-04-16 05:04:
You are lying to me and trying to lead me in the woods.

The stuff you say is stuff people say that in the end don't end up being
true. It does not even agree with the reality of how the system works
currently.

They are nonsense rebuttals and anyone with enough knowledge would be
able to refute them. You're playing mind games here


and NOW you finally reached the point where you should just shut up and 
don't say any word because you have no clue about what you are talking 
nor to whom you are talking - your bad that the person you responded to 
have more knowledge about the kernel the half of this whole mailing list 
together


https://en.wikipedia.org/wiki/Greg_Kroah-Hartman



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 15.04.2016 um 17:54 schrieb Xen:

Reindl Harald schreef op 13-04-16 10:26:

What are you on about?

Just because I don't have a superfast system, I cannot say anything?


no beause of "hmm let wait 3 seconds for something we don't know if it
ever appears and how long it would take to appear" is unacceptable in
general as additional boot time and on many setups would double the
whole boot time

nobody right in his mind would implement a "sleep 3" for a general
purpose setup in the boot process

*kernel time* is below 1 second on most machines


Do you realize how utterly ridiculous you sound? Even if what you say is
true, it would double the boot time of a 5 second boot to 10 seconds.


which is unacceptable, not a solution and can even not be called a 
workaround



I'm sure your life is now at stake.

I'm sure all your vital services are now failing. Call life support.
This guy is in trouble.


yes, when i have to decide to reboot 30 machines and find a timewindow 
for the task it makes a large difference if it takes just 4 seconds 
where nobody out there could provie that it was my server or his 
internet connection



Yes I'm making a mockery of your state of life here. Being concerned
about 4 fucking seconds when each time reliably your system has all
devices present in any case.


if only 3 people with your attitude would have anything to say we would 
be back at boot times from 10 years ago



That means "IN ANY CASE". That means: ALL THE TIME.

Systems do not wait 3 fucking hours for a networking device to show up okay.


you where the one who started with "wait for something"



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 15.04.2016 um 17:48 schrieb Xen:

Reindl Harald schreef op 13-04-16 10:24:

4xHDD raid-10, hardware from 2011
Startup finished in 660ms (kernel) + 5.380s (initrd) + 12.769s
(userspace) = 18.810s

os on sd-card
Startup finished in 375ms (kernel) + 4.306s (initrd) + 8.323s
(userspace) = 13.005s

so 3 seconds is unacceptable and the idea ist a joke in general because
you wait for something possibly happen while you don't know how long you
have to wait and jsut hope for luck - that's not a good design and won't
bew accepted anywhere


You are the only one taking 3 seconds seriously as something to hang
onto just so you can say that I am full of shit


it don't matter *how long* you wait for something you don't know if it 
ever appears and how long it take to appear - period




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 13-04-16 10:26:
> 
> 
> Am 13.04.2016 um 03:08 schrieb Xen:
>> Reindl Harald schreef op 13-04-16 02:06:
>>>
>>> Am 13.04.2016 um 01:20 schrieb Xen:
 Greg KH schreef op 13-04-16 01:16:
> On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote:
>> All you need to do is wait a few seconds before you start renaming
>
> Most machines boot to login faster than a "few seconds", so:

 Most machines boot to login faster than a few seconds?

 What machines are you talking about?

 Anyway the 3 seconds I mentioned is or would be a relative number
>>>
>>> STOP IT NOW
>>
>> What are you on about?
>>
>> Just because I don't have a superfast system, I cannot say anything?
> 
> no beause of "hmm let wait 3 seconds for something we don't know if it
> ever appears and how long it would take to appear" is unacceptable in
> general as additional boot time and on many setups would double the
> whole boot time
> 
> nobody right in his mind would implement a "sleep 3" for a general
> purpose setup in the boot process
> 
> *kernel time* is below 1 second on most machines

Do you realize how utterly ridiculous you sound? Even if what you say is
true, it would double the boot time of a 5 second boot to 10 seconds.

I'm sure your life is now at stake.

I'm sure all your vital services are now failing. Call life support.
This guy is in trouble.

Yes I'm making a mockery of your state of life here. Being concerned
about 4 fucking seconds when each time reliably your system has all
devices present in any case.

That means "IN ANY CASE". That means: ALL THE TIME.

Systems do not wait 3 fucking hours for a networking device to show up okay.

And systems that condense boot times to 4 seconds do not either, because
they could not reliably do so if this was true, this theoretical
hypothetical thing you are so consistently alluding to just to have a
stick to throw at me.

If your system boots in 4 seconds then your networking device is going
to be there.

And it is also going to be there prior to starting networking.

Christ, letting me be drawn into a debate where people can lie to me
because I am not intimiate with certain details of the boot process.

I invite you to produce a real dmesg in which your networking device is
not detected / kernel loaded prior to having a login prompt or something
of the kind. I honestly invite you to back up your false statements in
this way, and if not, just let me be for a change and like that other
person said: fume elsewhere. But it appears you are doing enough of that
already.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 13-04-16 10:24:
> 
> 
> Am 13.04.2016 um 02:42 schrieb Xen:
>> Greg KH schreef op 13-04-16 01:29:
>>> On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote:
>>
>>> All execpt for 4-socket and larger servers.  They take tens of minutes
>>> in the BIOS and then less than a minute in the kernel/userspace,
>>> depending on the amount of memory.
>>>
>>> Doesn't your laptop/desktop boot that fast?  If not, you are using the
>>> wrong distro :)
>>
>> I have no SSD. Even a 4-rotating-disk raid-10 system using a relatively
>> new processor (FX 6300) does definitely not boot within a few seconds
> 
> 4xHDD raid-10, hardware from 2011
> Startup finished in 660ms (kernel) + 5.380s (initrd) + 12.769s
> (userspace) = 18.810s
> 
> os on sd-card
> Startup finished in 375ms (kernel) + 4.306s (initrd) + 8.323s
> (userspace) = 13.005s
> 
> so 3 seconds is unacceptable and the idea ist a joke in general because
> you wait for something possibly happen while you don't know how long you
> have to wait and jsut hope for luck - that's not a good design and won't
> bew accepted anywhere

You are the only one taking 3 seconds seriously as something to hang
onto just so you can say that I am full of shit.

That makes you a retard, not me.

If the system needs to start networking and its devices are not present,
it is in trouble anyway. You seem to fail to appreciate that logical
problem.

You so proudly profess that your system is booted in whatever short
amount of time but good old you is willing to wait three hours before
the networking device is actually detected?

What fool you are then.

It is perfectly clear that in every boot you do this device is going to
be present at a perfectly rational and predictable interval of time.

You have systems that boot in 4 seconds but now you have issues with
networking hardware not showing up in time? Can you please stop
contradicting yourself

Jesus christ, I am out of here, or at least not responding anymore to
you (after the next).

Oh and yes to restate:

If you currently have systems that reliably are able to start
networking, then you will also have systems that reliably are able to
start networking if you rename devices prior to that moment in one go.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Greg KH schreef op 13-04-16 05:04:
> On Wed, Apr 13, 2016 at 02:42:29AM +0200, Xen wrote:
>> When you say that probing on the PCI bus never ends, and if we are
>> talking not about some form of hotplugging, then I really wonder what
>> you're on about ;-) because I do think the kernel has a limited set of
>> probes that it can perform, and at some point it is going to quit.
> 
> Not if it is interrupt driven, the kernel only responds to devices when
> they show up, it doesn't know how many devices are going to be ever
> found.
> 
>> It seems clear that some things are only going to be done once.
> 
> "once"?
> 
>> So I am not sure what you are alluding to. If there is some theoretical
>> tail (and it has not to do with hotplugging) I'm not sure if it is ever
>> going to be relevant here. If there is a theoretical tail, the system
>> cannot wait for it anyway.
> 
> The issue is that you need to create a system that allows devices to
> show up whenever they decide to show up, you can't "wait around" for
> anything as you never know just how long, or what will, or will not,
> show up.
> 
> You have to design a system that is event driven, as that is how
> hardware works, and is the only way your system can work properly due to
> it possibly changing all the time (devices added / removed between
> boots, etc.)

You are lying to me and trying to lead me in the woods.

The stuff you say is stuff people say that in the end don't end up being
true. It does not even agree with the reality of how the system works
currently.

They are nonsense rebuttals and anyone with enough knowledge would be
able to refute them. You're playing mind games here.

Any system needing to take into account that some urgently needed
networking device might shop up after 3 days when the moon is in the
right position in the sky this is what you are saying.

It doesn't agree with reality and I am not going to respond to this
nonsense.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 13.04.2016 um 02:15 schrieb pgndev:

On Tue, Apr 12, 2016 at 5:06 PM, Reindl Harald  wrote:

Is there a ML anywhere on which you don't sputter, fume, rant and insult?


interesting that you say that to me in this thread while the OP started 
very early to call people "Idiot", "why someone does not do a certain 
thing, you are an idiot" and "are you silly"


given that and that he even admit repeatly that he have no really clue 
about many things which are relevant to the topic and then comes up with 
"well, do a sleep 3" the only correct answer is STOP IT, the whole thread




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 13.04.2016 um 03:08 schrieb Xen:

Reindl Harald schreef op 13-04-16 02:06:


Am 13.04.2016 um 01:20 schrieb Xen:

Greg KH schreef op 13-04-16 01:16:

On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote:

All you need to do is wait a few seconds before you start renaming


Most machines boot to login faster than a "few seconds", so:


Most machines boot to login faster than a few seconds?

What machines are you talking about?

Anyway the 3 seconds I mentioned is or would be a relative number


STOP IT NOW


What are you on about?

Just because I don't have a superfast system, I cannot say anything?


no beause of "hmm let wait 3 seconds for something we don't know if it 
ever appears and how long it would take to appear" is unacceptable in 
general as additional boot time and on many setups would double the 
whole boot time


nobody right in his mind would implement a "sleep 3" for a general 
purpose setup in the boot process


*kernel time* is below 1 second on most machines





signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 13.04.2016 um 02:42 schrieb Xen:

Greg KH schreef op 13-04-16 01:29:

On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote:



All execpt for 4-socket and larger servers.  They take tens of minutes
in the BIOS and then less than a minute in the kernel/userspace,
depending on the amount of memory.

Doesn't your laptop/desktop boot that fast?  If not, you are using the
wrong distro :)


I have no SSD. Even a 4-rotating-disk raid-10 system using a relatively
new processor (FX 6300) does definitely not boot within a few seconds


4xHDD raid-10, hardware from 2011
Startup finished in 660ms (kernel) + 5.380s (initrd) + 12.769s 
(userspace) = 18.810s


os on sd-card
Startup finished in 375ms (kernel) + 4.306s (initrd) + 8.323s 
(userspace) = 13.005s


so 3 seconds is unacceptable and the idea ist a joke in general because 
you wait for something possibly happen while you don't know how long you 
have to wait and jsut hope for luck - that's not a good design and won't 
bew accepted anywhere




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Wed, Apr 13, 2016 at 02:42:29AM +0200, Xen wrote:
> When you say that probing on the PCI bus never ends, and if we are
> talking not about some form of hotplugging, then I really wonder what
> you're on about ;-) because I do think the kernel has a limited set of
> probes that it can perform, and at some point it is going to quit.

Not if it is interrupt driven, the kernel only responds to devices when
they show up, it doesn't know how many devices are going to be ever
found.

> It seems clear that some things are only going to be done once.

"once"?

> So I am not sure what you are alluding to. If there is some theoretical
> tail (and it has not to do with hotplugging) I'm not sure if it is ever
> going to be relevant here. If there is a theoretical tail, the system
> cannot wait for it anyway.

The issue is that you need to create a system that allows devices to
show up whenever they decide to show up, you can't "wait around" for
anything as you never know just how long, or what will, or will not,
show up.

You have to design a system that is event driven, as that is how
hardware works, and is the only way your system can work properly due to
it possibly changing all the time (devices added / removed between
boots, etc.)

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Andrei Borzenkov]

13.04.2016 02:24, Jordan Hargrave пишет:
> 
> I am the primary developer of biosdevname.  I've been wanting this
> naming functionality built into systemd or even the OS itself.
> Primarily I am interested in servers with multiple physical and
> virtual NICs but getting it working on desktops would be a bonus as
> well.
> 
> The problem lies in the mapping itself.  Network devices can be on a
> single, dual, or even quad-port cards.  Each one of these ports can be
> 'virtualized' through SR-IOV or NIC partitioning, one physical card
> can potentially have hundreds of virtual NICs.  Other cards implement
> multiple network interfaces for a single PCI bus:dev:func pair.
> SMBIOS table has a mapping from slot number to PCI device, this can be
> used to determine the physical slot number of a network card (and its
> ports).
> 
> So there are at least 4 variables that you must keep track of, for add-in 
> cards
> 
> PCI slot #
> NIC physical port # (for multi-port cards)
> NIC device ID (Each physical port can implement multiple network
> devices)  see mlx4 driver or i.
> NIC partition number (each device can then have multiple
> partitions/virtual devices)  See. SR-IOV or Dell NPAR (network
> partitioning)
> 
> For embedded devices (onboard), PCI slot # is replaced by instance
> number.  This is also available through SMBIOS.

Yes. And I do not see how all this information is expected to be stuffed
into 14 characters available for interface name, or even less if we
account to VLAN numbers.

I am not aware of any OS that tries to do it. All of them maintain
persistent association between interface names and hardware
characteristics; most use physical topology, but this is not really
mandatory. Interface names themselves are usually allocated on the first
come first serve basis. This gives reasonable behavior for small systems
(where existing interface will always get the same name irrespectively
of how it is connected) and stable names for large systems.

That is what we used in the past as well in form of udev rules. And any
answer "but you can easily disable predictable names" is hypocritical
because the whole infrastructure to maintain such name database was
ripped out, so anyone who disables predictable names is forced to
reinvent the wheel and reimplement it. Which by far exceeds what average
user is capable of. So average user simply has no choice.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 13-04-16 02:06:
> 
> 
> Am 13.04.2016 um 01:20 schrieb Xen:
>> Greg KH schreef op 13-04-16 01:16:
>>> On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote:
 All you need to do is wait a few seconds before you start renaming
>>>
>>> Most machines boot to login faster than a "few seconds", so:
>>
>> Most machines boot to login faster than a few seconds?
>>
>> What machines are you talking about?
>>
>> Anyway the 3 seconds I mentioned is or would be a relative number
> 
> STOP IT NOW

What are you on about?

Just because I don't have a superfast system, I cannot say anything?

If you have a system that has logged on to the internet and cracked the
white house in a fraction of a millisecond, that still doesn't change or
take away from anything I have said.

The system still needs to do things in a certain order.

That order is relevant, not actual times I just mentioned as an example.

And very wonderful for you to have systems that boot in 4 seconds and
you then keep running for 20 weeks.

My applauds. You have saved an amazing amount of time, now you can go on
a holiday. Because your system boots fast.

Congratulations.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 13-04-16 02:04:
> 
> 
> Am 13.04.2016 um 00:03 schrieb Xen:
>> Reindl Harald schreef op 12-04-16 21:35:
>>>
>>> Am 12.04.2016 um 21:24 schrieb Xen:
 However currently for me, biosdev renumbers these, while my scheme
 wouldn't
>>>
>>> wow - you even don't realise that "biosdevname" and
>>> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
>>>
>>> are two completly different things
>>
>> I was just curious whether installing biosdevname would change things,
>> but apparently the program doesn't return anything for -i eth0
> 
> oh my god - they are oth *not* supposed to give back eth0 adn you should
> at leats not throwing with words around you which have a specific
> meaning in the topic

Apparently it was due to systemd already doing its thing. If I turn it
off, now biosdevname -i eth0 will return:

p10p1

The all_ethN policy simply returns:

eth0 --- this is apparently a reordered system, but since I have only
one NIC, you won't see anything special. I guess this is the system that
was said to create race conditions.

I don't know why biosdevname is not actually used, even though the
online document says so, by the systemd scheme.

"The all_ethN policy makes a best guess at what the device order should
be, with embedded devices first, PCI cards in ascending slot order, and
ports in  ascending  PCI bus/device/function order breadth-first.
However, this policy does not work if your PCI devices are hot-plugged
or hot-plug‐gable, including the virtual functions on an SR-IOV device.
In a hot-plug scenario, each separate udev instance will be  invoked  in
parallel, while the device tree is still being populated with new
devices.  Each udev instance will see a different PCI tree, and thus
cannot provide con‐sistent enumeration.  Use of this policy should be
limited to only scenarios where all PCI devices are present at boot
(cold-plug)."

Seems close to what I wanted. Seems almost exactly what I wanted. The
"ethernet0" scheme I proposed is also only meant for cold-plug.

So basically, Reindl / Greg, the thing you are criticising is already
implemented and functioning in biosdevname, the program.

So I don't know what you are on about. You say it cannot be done, and it
has already been done.

Apparently you can use it in udev rules you design yourself (I have no
knowhow about that).

biosdevname, according to the web page, has formed the basis for the
current systemd scheme.

But it is also still a program you can use to accomplish the thing I
want, albeit in a limited fashion.

I guess it needed a kernel parameter to be activated.

You are bitching about terminology I use, but everyone already knew what
I was talking about.

Reminds me of this image ;-).

https://s-media-cache-ak0.pinimg.com/736x/09/6a/f8/096af8445c29b9be6c485abecfac7e04.jpg


As well, even though technically the biosdevname and the systemd scheme
are distinct, no one of you or anyone has ever mentioned biosdevname,
all of it has been about the systemd scheme and everyone understood what
I was saying.

So, yes, arguably pretentious. And maybe also purely pedantic here.


> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html

I had already seen both pages, thank you very much.

It did take a while for me to sink in what biosdevname actually was, and
indeed I did not differentiate, but it was also not necessary before
because no one actually refered to the actual "biosdevname".

So thank you for pointing it out, but if it had been relevant, someone
would already have mentioned it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Greg KH schreef op 13-04-16 01:29:
> On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote:

> All execpt for 4-socket and larger servers.  They take tens of minutes
> in the BIOS and then less than a minute in the kernel/userspace,
> depending on the amount of memory.
> 
> Doesn't your laptop/desktop boot that fast?  If not, you are using the
> wrong distro :)

I have no SSD. Even a 4-rotating-disk raid-10 system using a relatively
new processor (FX 6300) does definitely not boot within a few seconds.

The system I'm on now has a 2.5" 5400 hdd and a mobo/cpu from 2009. Or
2010. I think it takes about 30 seconds before the network is up (by
DHCP probably, is what it means). That's 30 seconds into booting the
kernel, not counting the BIOS.

It seems to take 22 seconds before it loads the nVidia kernel and mounts
/boot and activates swap.

>> Anyway the 3 seconds I mentioned is or would be a relative number.
> 
> You have to define this in a way that will properly work.

I think using timing might not be smart anyway. I don't know.

>> I am sure you can provision that in your boot sequence.
> 
> How?

I would think in the initrd, the most obvious way would be to perform it
right before starting networking. I'm not intimiate on current details
of how booting works. In general you'd think that if networking is a
target, then it would depend on the activation of the renaming/aliasing.

Since the renaming has no impact on anything other than networking, you
can do it right before you start that up.

>> What buses are you mentioning here?
> 
> PCI, USB, etc.

There is a concept in statistics where some (or many) distributions have
a "tail" that is never quite going to disappear.

Even if the probability that something is going to appear in that tail
might at some point be less that 0.1%, it is never going to be zero,
although it converges on zero.

When you say that probing on the PCI bus never ends, and if we are
talking not about some form of hotplugging, then I really wonder what
you're on about ;-) because I do think the kernel has a limited set of
probes that it can perform, and at some point it is going to quit.

It seems clear that some things are only going to be done once.

So I am not sure what you are alluding to. If there is some theoretical
tail (and it has not to do with hotplugging) I'm not sure if it is ever
going to be relevant here. If there is a theoretical tail, the system
cannot wait for it anyway.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Jordan Hargrave schreef op 13-04-16 01:24:

> I am the primary developer of biosdevname.  I've been wanting this
> naming functionality built into systemd or even the OS itself.
> Primarily I am interested in servers with multiple physical and
> virtual NICs but getting it working on desktops would be a bonus as
> well.
> 
> The problem lies in the mapping itself.  Network devices can be on a
> single, dual, or even quad-port cards.  Each one of these ports can be
> 'virtualized' through SR-IOV or NIC partitioning, one physical card
> can potentially have hundreds of virtual NICs.  Other cards implement
> multiple network interfaces for a single PCI bus:dev:func pair.
> SMBIOS table has a mapping from slot number to PCI device, this can be
> used to determine the physical slot number of a network card (and its
> ports).
> 
> So there are at least 4 variables that you must keep track of, for add-in 
> cards
> 
> PCI slot #
> NIC physical port # (for multi-port cards)
> NIC device ID (Each physical port can implement multiple network
> devices)  see mlx4 driver or i.
> NIC partition number (each device can then have multiple
> partitions/virtual devices)  See. SR-IOV or Dell NPAR (network
> partitioning)
> 
> For embedded devices (onboard), PCI slot # is replaced by instance
> number.  This is also available through SMBIOS.

Given this technology and virtualisation possibilities for larger
systems it seems unwanted, unnecessary and improbably that you would
ever want a simple "works for everyone scheme".

Any complex system that actually uses all of these features might even
have 100s of "nics". If you need to be able to address all of these
devices by a simple name, it becomes clear you need something structured
and deterministic.

Anything else would probably not make sense for the usage scenario you'd
start to envision.

I take it, such a usage scenario could for instance this being a host
system for a hypervisor that distributes all of these individual nics to
its guests (for instance, I don't know).

I cannot really imagine any other system where you'd need that. But
again, aside.

* Do you feel pure-name addressing is the way this should be done? You
are basically encoding an address in a name. The software that sets up
or uses this name is going to know about the scheme or it couldn't do
anything with it. To this system, these names are not going to be "black
boxes", their generation and usage might see code constructing them or
deconstructing them to know about its elements.

What you get is something like a sequence of arrays (multi-dimensional
array) but instead of addressing [0][2][4] you are going to be doing
name-p0p2p4 using an encoded address.

At that point you wonder whether you do not want the system to enable
direct addressing of the components using a filesystem path (for
instance) such as not "/sys/class/net/enp3s0" but rather
"/sys/class/net/en/3/0" as a manner of speaking.

So my first question and consideration is: from your point of view, do
these names suffice for you, or do you require more direct addressing of
the components?



Then the second question is: can you imagine a need for people to map
any of these names or components to well-understood "aliases" such as
eth0 or ethernet0?

Ideally speaking, if you set up a system of ports and virtualized ports
and so on, the direct path to the root device (of such) would not be
very relevant to you, as long as you can access that root device
directly (e.g. through an alias).

As such, this /net/en/3/0 as a root "address" might not be as meaningful
to you as what would come beneath it.

In other words, the subtree you have "designed" for your particular
system becomes more important to you than the place where that subtree
is "mounted" as long as you know where.

The actual physical hardware address of your "root device" is not going
to be as important as being able to address it reliably in the first
place. The fact that it is going to be /net/3/0 or /net/4/0 is not going
to be relevant to you.

Moreoever, if you want your system to be portable, you would want it to
be independent in some way of these "hardcoded" hardware addresses.

You might have a system image or an entire suit of configuration tools,
that is already constructed towards generating this system you want.

Where your root device is going to be in this particular system, is not
that important. However, while setting up, you will need to know this
address and use it as the "anchor".

This form of anchoring could equally well be done by using an alias.

So considering that I'm actually proposing (or have been thinking about)
keeping this "internal subdivision" intact while making the addressing
of the root device a system-independent thing, you could for instance
think that:

"ethernet0" does not indicate a final port an sich, it would indicate a
root ethernet device.

If this device had 4 ports, they would then not be "ethernet0"
"ethernet1" and so on, but you would 

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[pgndev]

> On Tue, Apr 12, 2016 at 5:06 PM, Reindl Harald  wrote:

Is there a ML anywhere on which you don't sputter, fume, rant and insult?

If you don't like what you're reading -- walk away and don't participate.

Adding yet another rule to the 'Raindl-Filter(tm)'.  The filterset's
getting to be almost as large as the kernel ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 13.04.2016 um 01:20 schrieb Xen:

Greg KH schreef op 13-04-16 01:16:

On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote:

All you need to do is wait a few seconds before you start renaming


Most machines boot to login faster than a "few seconds", so:


Most machines boot to login faster than a few seconds?

What machines are you talking about?

Anyway the 3 seconds I mentioned is or would be a relative number


STOP IT NOW

Startup finished in 550ms (kernel) + 652ms (initrd) + 3.872s (userspace) 
= 5.074s
Startup finished in 566ms (kernel) + 319ms (initrd) + 1.430s (userspace) 
= 2.316s
Startup finished in 491ms (kernel) + 635ms (initrd) + 1.909s (userspace) 
= 3.036s
Startup finished in 508ms (kernel) + 600ms (initrd) + 3.001s (userspace) 
= 4.110s
Startup finished in 361ms (kernel) + 604ms (initrd) + 11.529s 
(userspace) = 12.495s
Startup finished in 366ms (kernel) + 614ms (initrd) + 2.194s (userspace) 
= 3.174s
Startup finished in 1.041s (kernel) + 1.120s (initrd) + 3.231s 
(userspace) = 5.394s
Startup finished in 499ms (kernel) + 648ms (initrd) + 4.224s (userspace) 
= 5.372s
Startup finished in 570ms (kernel) + 983ms (initrd) + 4.155s (userspace) 
= 5.708s
Startup finished in 355ms (kernel) + 694ms (initrd) + 2.052s (userspace) 
= 3.102s
Startup finished in 563ms (kernel) + 1.071s (initrd) + 3.103s 
(userspace) = 4.739s
Startup finished in 1.038s (kernel) + 1.283s (initrd) + 3.385s 
(userspace) = 5.708s
Startup finished in 585ms (kernel) + 1.368s (initrd) + 3.701s 
(userspace) = 5.656s
Startup finished in 1.003s (kernel) + 1.269s (initrd) + 3.505s 
(userspace) = 5.778s
Startup finished in 1.084s (kernel) + 1.163s (initrd) + 2.968s 
(userspace) = 5.217s
Startup finished in 1.161s (kernel) + 1.200s (initrd) + 3.858s 
(userspace) = 6.220s
Startup finished in 896ms (kernel) + 1.319s (initrd) + 3.572s 
(userspace) = 5.788s
Startup finished in 1.071s (kernel) + 940ms (initrd) + 3.711s 
(userspace) = 5.723s
Startup finished in 849ms (kernel) + 1.172s (initrd) + 3.130s 
(userspace) = 5.152s
Startup finished in 982ms (kernel) + 1.176s (initrd) + 3.768s 
(userspace) = 5.926s
Startup finished in 889ms (kernel) + 1.255s (initrd) + 3.798s 
(userspace) = 5.943s
Startup finished in 429ms (kernel) + 1.166s (initrd) + 28.956s 
(userspace) = 30.552s




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 13.04.2016 um 00:03 schrieb Xen:

Reindl Harald schreef op 12-04-16 21:35:


Am 12.04.2016 um 21:24 schrieb Xen:

However currently for me, biosdev renumbers these, while my scheme
wouldn't


wow - you even don't realise that "biosdevname" and
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
are two completly different things


I was just curious whether installing biosdevname would change things,
but apparently the program doesn't return anything for -i eth0


oh my god - they are oth *not* supposed to give back eth0 adn you should 
at leats not throwing with words around you which have a specific 
meaning in the topic


https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote:
> Greg KH schreef op 13-04-16 01:16:
> > On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote:
> >> All you need to do is wait a few seconds before you start renaming
> > 
> > Most machines boot to login faster than a "few seconds", so:
> 
> Most machines boot to login faster than a few seconds?
> 
> What machines are you talking about?

All execpt for 4-socket and larger servers.  They take tens of minutes
in the BIOS and then less than a minute in the kernel/userspace,
depending on the amount of memory.

Doesn't your laptop/desktop boot that fast?  If not, you are using the
wrong distro :)

> Anyway the 3 seconds I mentioned is or would be a relative number.

You have to define this in a way that will properly work.

> I am sure you can provision that in your boot sequence.

How?

> >> or wait on some defined trigger.
> > 
> > Exactly what type of "defined trigger" would work for busses that you
> > never know when they are finished being probed?
> 
> What buses are you mentioning here?

PCI, USB, etc.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Jordan Hargrave]

On Tue, Apr 12, 2016 at 5:39 PM, Xen  wrote:
> Just want to summarize here very shortly.
>
>
> If you turn the hotplug naming scheme into something more attractive.
>
> If you turn the USB naming scheme into something more attractive.
>
> If you accept like a 99.9% confidence interval for waiting until
> hardware has shown itself, then taking the (embedded + pci bus) numbers
> and condensing that into a sequential list for ethernet and wireless
>
> And if you deal with any other naming scheme there might be.
>
> Then it would solve the utmost total majority of instability issues in
> the kernel loading the driver for multiple NICs in quick succession
> (this whole issue was mostly about very short intervals I believe) even
> if you don't have a 100.0% guarantee (but you would have a rounded
> 100% guarantee) particularly if you take into account that
> networking+firewall+routing should perhaps not start for a production
> system that is very important if not all networking devices for it are
> present.
>
> If you are going to start routing and firewalling on non-present
> networking devices, you have a problem anyway and the current
> "PredictableNetworkInterfaceNames" is not going to solve that.
>
> Then you will have ethernet0 and wireless0 names for the majority (vast
> majority) of consumer devices out there.
>
> You will have an almost 100.000% guarantee that an ordinary user with 2
> ethernet NICs (like a motherboard with 2 ports) will never ever
> experience NIC swapping (eth0 becoming eth1 and vice versa).
>
> You will not see a difference for USB and hotplug because you only
> prettify the names, compared to the current system.
>
> The statistical likelihood of this ever going wrong for those 2 NICs is
> just very very very very small. I don't care what you say about NICs
> showing up 2 hours after the system is booted. If you have a system that
> has to wait 2 hours for a relevant or essential NIC, it is going to be
> nonfunctional anyway.
>
> If you feel I'm being thick, please say so. I feel I am (but do explain
> ;-)).
>
> I just don't see how this is going to turn into any problem ever for
> anyone. If you do the renaming prior to starting networking, it is
> nearly impossible EVER that this will impact real people in a real way.
>
> Maybe that is not acceptable. From my point of view currently with the
> knowledge I have, it would work out fine and "waiting for devices to be
> present before you act on it" seems like a very nice thing to do anyway.
> It feels nice to me.
>
> It is only relevant for networking setups and if both devices you need
> are not present (or even more) you should not act on it anyway and the
> system should fail. Or you should have a provision that you are alerted
> of networking hardware not having come online.
>
> There is not really any scenario where this condensing of enp3s0 names
> is going to cause a problem.
>
> And if it does, reboot you know ;-). But it is not going to happen.
> Consumer systems usually have one NIC (eth). Routers running systemd
> need to guarantee that both needed devices (or more) are present before
> starting networking. I bet it is not a problem for them to depend on
> fixed bus names, especially if they are embedded systems. But hardware
> failure would usually disrupt functioning anyway.
>
> And you could turn that system off if you wanted. It doesn't have to be
> the same for everyone, as long as it is convenient and usable for the
> majority. Right?
>
> All you need to do is wait a few seconds before you start renaming or
> wait on some defined trigger.
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

I am the primary developer of biosdevname.  I've been wanting this
naming functionality built into systemd or even the OS itself.
Primarily I am interested in servers with multiple physical and
virtual NICs but getting it working on desktops would be a bonus as
well.

The problem lies in the mapping itself.  Network devices can be on a
single, dual, or even quad-port cards.  Each one of these ports can be
'virtualized' through SR-IOV or NIC partitioning, one physical card
can potentially have hundreds of virtual NICs.  Other cards implement
multiple network interfaces for a single PCI bus:dev:func pair.
SMBIOS table has a mapping from slot number to PCI device, this can be
used to determine the physical slot number of a network card (and its
ports).

So there are at least 4 variables that you must keep track of, for add-in cards

PCI slot #
NIC physical port # (for multi-port cards)
NIC device ID (Each physical port can implement multiple network
devices)  see mlx4 driver or i.
NIC partition number (each device can then have multiple
partitions/virtual devices)  See. SR-IOV or Dell NPAR (network
partitioning)

For embedded devices (onboard), PCI slot # is replaced by instance

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Greg KH schreef op 13-04-16 01:16:
> On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote:
>> All you need to do is wait a few seconds before you start renaming
> 
> Most machines boot to login faster than a "few seconds", so:

Most machines boot to login faster than a few seconds?

What machines are you talking about?

Anyway the 3 seconds I mentioned is or would be a relative number.

I am sure you can provision that in your boot sequence.

>> or wait on some defined trigger.
> 
> Exactly what type of "defined trigger" would work for busses that you
> never know when they are finished being probed?

What buses are you mentioning here?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote:
> All you need to do is wait a few seconds before you start renaming

Most machines boot to login faster than a "few seconds", so:

> or wait on some defined trigger.

Exactly what type of "defined trigger" would work for busses that you
never know when they are finished being probed?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Just want to summarize here very shortly.


If you turn the hotplug naming scheme into something more attractive.

If you turn the USB naming scheme into something more attractive.

If you accept like a 99.9% confidence interval for waiting until
hardware has shown itself, then taking the (embedded + pci bus) numbers
and condensing that into a sequential list for ethernet and wireless

And if you deal with any other naming scheme there might be.

Then it would solve the utmost total majority of instability issues in
the kernel loading the driver for multiple NICs in quick succession
(this whole issue was mostly about very short intervals I believe) even
if you don't have a 100.0% guarantee (but you would have a rounded
100% guarantee) particularly if you take into account that
networking+firewall+routing should perhaps not start for a production
system that is very important if not all networking devices for it are
present.

If you are going to start routing and firewalling on non-present
networking devices, you have a problem anyway and the current
"PredictableNetworkInterfaceNames" is not going to solve that.

Then you will have ethernet0 and wireless0 names for the majority (vast
majority) of consumer devices out there.

You will have an almost 100.000% guarantee that an ordinary user with 2
ethernet NICs (like a motherboard with 2 ports) will never ever
experience NIC swapping (eth0 becoming eth1 and vice versa).

You will not see a difference for USB and hotplug because you only
prettify the names, compared to the current system.

The statistical likelihood of this ever going wrong for those 2 NICs is
just very very very very small. I don't care what you say about NICs
showing up 2 hours after the system is booted. If you have a system that
has to wait 2 hours for a relevant or essential NIC, it is going to be
nonfunctional anyway.

If you feel I'm being thick, please say so. I feel I am (but do explain
;-)).

I just don't see how this is going to turn into any problem ever for
anyone. If you do the renaming prior to starting networking, it is
nearly impossible EVER that this will impact real people in a real way.

Maybe that is not acceptable. From my point of view currently with the
knowledge I have, it would work out fine and "waiting for devices to be
present before you act on it" seems like a very nice thing to do anyway.
It feels nice to me.

It is only relevant for networking setups and if both devices you need
are not present (or even more) you should not act on it anyway and the
system should fail. Or you should have a provision that you are alerted
of networking hardware not having come online.

There is not really any scenario where this condensing of enp3s0 names
is going to cause a problem.

And if it does, reboot you know ;-). But it is not going to happen.
Consumer systems usually have one NIC (eth). Routers running systemd
need to guarantee that both needed devices (or more) are present before
starting networking. I bet it is not a problem for them to depend on
fixed bus names, especially if they are embedded systems. But hardware
failure would usually disrupt functioning anyway.

And you could turn that system off if you wanted. It doesn't have to be
the same for everyone, as long as it is convenient and usable for the
majority. Right?

All you need to do is wait a few seconds before you start renaming or
wait on some defined trigger.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 12-04-16 21:35:
> 
> 
> Am 12.04.2016 um 21:24 schrieb Xen:
>> However currently for me, biosdev renumbers these, while my scheme
>> wouldn't
> 
> wow - you even don't realise that "biosdevname" and
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> are two completly different things

I was just curious whether installing biosdevname would change things,
but apparently the program doesn't return anything for -i eth0.

Or, apparently my BIOS does not give information or whatever.

They are not completely different things. That online document describes
that biosdevname will take predence if installed.

It also, once more, describes that there are different schemes for
hotplug devices (this takes care of Thunderbolt).

Basically the scheme has two dimensions: prefix (en, wl, ..) and the
first viable "address" naming scheme it finds.

Onboard, hotplug, and card devices are apparently separated as best it can.

In my case my onboard NIC ends up in the 3rd scheme.

Maybe you will say that if my BIOS provided adequate information, it
would have become something else and the PCI renumbering wouldn't be an
issue.

But still everything I wrote was about naming (and sequence condensing).

And yes I want my systems by default to make sense (and for everyone
else as well).

From a user's perspective, my remembrance is that:
- my ethernet devices have always been enpXsY
- my wlan device has been something short but also something long and
  people report long names.

Why not just pioneer a representation scheme where:

- ethernet (wired) onboard and card devices are called ethernetX with
any onboard device taking precedence

- ethernet (hotplug) devices are called eth-hotplug

- wireless do the same: wirelessX and wifi-hotplug

- wired usb: eth-usb- such as "eth-usb1-2"

There can be multiple USB controllers but USB already has a scheme like
that. These controllers I think are already numbered in sequence. I'm
not sure if that is stable, but it is also not very important. Make it
work without requiring the PCI bus number (p0s29 is not going to be very
meaningful).

So you might get:

eth-usb1-4 or eth-usb1.4-1-2 or something of the kind even. Make it pretty.

Maybe those USB numbers are unstable too?

- wireless usb: same thing: wifi-usb

There is no need for condensing usb numbers. Just as with PCIe-hotplug,
you can't really care about any persistence. You can't really care about
pretty names (too much) because it is obvious that "eth0" wouldn't make
much sense for it.

So propose a scheme for:

- ethernet0, wireless0 as condensed numbers
- eth-hotplug0, wifi-hotplug1 as port numbers
- eth-usb1-4-1 as usb path, same for wifi-usb1-4-1

(could also be wifi-usb1-4p12 or wifi-usb14-12 or wifi-usb1-4_1-2 or
wifi-usb1-4p1p2)

And fill in the rest for stuff I haven't mentioned / don't know about.

The ONLY thing that is required is that you are willing to wait a few
seconds before you fix the list in the case of condensed numbers.

That before networking is started, you take the list of "onboard"
(embedded and card slot) devices and condense that.

Meaning, you wait with renaming until you can be reasonably sure that
everything has made itself known.

Maybe that does not theoretically solve every possible "unstableness"
but I'm pretty sure it would solve 99% of issues that people had even if
you cannot guarantee it.


So yes I am concerned with two things:

- pretty names
- condensation of some default devices.

wireless0
wifi-hotplug1
ethernet0
eth-usb1-4u2

these seem reasonably sensible to me.

the onboard-and-pci-card thing guarantees within bounds that no new
devices are going to show up "suddenly" (like with 99% certainty or more)

In statistics this is called a confidence interval. I am pretty sure a
99% confidence interval for pretty much all embedded/pci-card-hardware
being recognised by the kernel drivers falls within 10 seconds, and even
more sure that it is probably going to fall within a second or 3
starting from boot. On my system, other systems may be faster.

"Greg KH is completely correct -- that can totally happen." (with
reference to some networking device taking 2 hours to respond).

I am pretty sure the occurance of that will fall outside of the 99%
confidence.

I mean, am I being thick here?

I think that for pretty much all functional systems you can with 99%
confidence state that these two types of networking hardware are going
to get recognised within 3 seconds if they get recognised at all.

If you do the renaming and condensing after that, you're done.

It will not change hotplug, it does not depend on fixed PCI bus numbers,
it will not change USB, and it will not change any other thing you don't
want it to.

It will just give people pretty names and predictable names and
99.99% certainty that this will always work for them and anyone.

With the only possibility that it wouldn't work, being the possibility
that a networking device 

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 12-04-16 20:54:

>> Then do it yourself.
> 
> what?

Design or propose something better.

Maybe you thought the original system was better, I guess you mentioned
something like that.


> i am just a user like you but with technical understanding, the point is
> that you talk about things which you don't gasp in a way like you are
> the king

I don't see anybody else taking up the ball.

And the king wouldn't do this himself, he would assign someone to do it
for him. My mind is not utterly perfect and I often cannot describe
myself very well.

Maybe you think I am eloquent, currently, I am not.

I just do my best in what you could describe as some kind of uphill
battle, right.

Let me just say this, and I think you can agree:

Many times in life we are shoved off by people who have a superior
technical understanding, which means we cannot stand up to them. But we
still feel that the decisions they make are bullshit.

This can be as simple as a monitor that makes noise when in standby
(coilwhine or something similar) and the salesman says "that's what all
devices do, that's just a part of it".

We feel that an injustice is being done to us, but we don't have all the
knowledge to prove it. People with more knowledge can throw us in the
woods, and hide information from us what would serve us. Because they
have an agenda and do not want to accept your objections or demands.

Yes what I am doing is simply making a demand of some kind, and I guess
you know that.

I mean you are not unsympathetic to it, but I just cannot do anything
well these days (my mind is too much fucked up) and this is not just here.

The way these things go is that you would invite the technically
knowledgeable people to prove that the decisions they've made are sound.
Like Andrei Borzenkov said

"You need to explain why your new naming scheme is better than that."

And this is reasonably accurate you know. It doesn't work here because
the person making a complaint does have to justify it.

But after a complaint has been justified the people responsible for the
system can also be invited to demonstrate why their system is really
necessary.

However this is not really happening here. So suddenly I am the one that
needs to have all the knowledge.

You know what it's like being governed by a technocracy. Most economical
decisions in government are also made by politians who convince the
populance of the necessity of their choices but meanwhile they do not
reveal who is really pulling their strings and what interests they are
really serving.

It's the same here: the designers and important people in this industry
work for some large corporations or work for vendors that supply to them.

I think you will agree that what we see in this point in time is a
weighing of interests and the large businesses win out. Right.

And no matter my lack of technical knowhow: I can see this happening.

>> Thunderbolt is a largely irrelevant technology from what it seems.
> 
> says who?

You ask why it is relevant to this topic. I was just explaining why I
don't have this knowledge.

As a random computer user, it is impossible that I would have in-depth
knowledge about e.g. Thunderbolt or the way it is presented on the (PCI)
bus.

I explain why this technology is so far removed from me that I cannot
possibly have either an interest, or a way to know all about it.

So I hope I can be excused I do not know everything before saying something.


>> Recent years have seen a proliferation of new technologies but most
>> people don't even use them:
>>
>> * DisplayPort, the vast majority of computer users may not ever have
>> used it.
> 
> tell that the 6 workstations i am responsible for

I am saying this to illustrate that the current concerns may not be
concerns of the vast majority of users.

The 6 workstations you are responsible for may not represent the
majority, and you know that.

People often talk about the disconnect between politicians and ordinary
people. Well, what we see today.

Do you not think it can be described as a disconnect between designers
and actual users?

So I will tell your 6 workstations that the vast majority of computer
users may not ever have used DisplayPort.

Your workstations will say, "Well, but we are bit higher end machines.
Many people at home buy cheaper monitors that do not have DisplayPort.
We may reflect the minority on a global scale. It's not that our
technology is not widely used, but in the lower range and on smaller
size monitors, it is true that a displayport connector is often not
found. It is also true that displayport (I think) is mainly used for the
higher resolutions it supports, which may not be relevant for smaller
screens. DisplayPort is currently present on many motherboards and even
laptops, but I suspect there is indeed a large share of users who have
never come into contact with it. For instance, as an illustration"

MSI produced an nVidia GTX 960 card with 3x DisplayPort.

They 

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 12.04.2016 um 21:24 schrieb Xen:

However currently for me, biosdev renumbers these, while my scheme wouldn't


wow - you even don't realise that "biosdevname" and 
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ 
are two completly different things






signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Manuel Amador (Rudd-O) schreef op 12-04-16 12:46:
> On 04/12/2016 02:26 AM, Xen wrote:
>> That is completely nonsensical because it would imply that some network
>> device could be initialized 2 hours after the system had booted.
> 
> Greg KH is completely correct -- that can totally happen.

If that happens you have worse problems than a renumber of network
device, I'm sure you'd agree.

In any case if you have a solution of hotpluggable devices, and these
devices can appear anywhere in that biosdev tree, then yes mapping it to
a linear set of lists might be problematic. You would need to separate
hotplug vs non-hotplug.

But thus far, I have demonstrated to myself that removing a non-hotplug
device defeats the biosdev scheme.

I cannot know at this point whether worse stuff does not happen to
biosdev if you remove e.g. Thunderbolt ethernet devices.

So I am not really in the position to decide or even say much about that.

Use some common sense. Most of the rebuttals I get here are stuff you,
yourself, are capable of solving.

> But it's clear that rational, calm, evidence-based arguments aren't
> swaying you.

If hotplugging a device can change PCI numbers, then there is nothing
rational about it. You have defeated yourself already.

The PCI device is supposed to be geographical location but it changes
depending on number of devices present (at least on my system). That
means on my system the biosdev system behaves as the thing that I have
proposed, with the exception and difference that although PCI numbers
would change (do change), the resulting ethernetX networking list, would
not.

So for MY system my solution would work whereas your current (??) system
doesn't.

If you consider that irrational arguments, then I consider you a turd
person.

I could go and test on on the other 2 systems currently present in my
house, one would require booting a live DVD, the other would require
turning on diosdev in a Debian 8 system.

Both are rather current.

The scheme I did propose would solve the kernel reordering problem. You
say or imply that some network device present-at-boot can take 2 hours
to be recognised by the kernel. In that case you have worse problems
than a reordering of numbers. What are you really solving here.

The arbitariness in detection would be solved by my scheme by assuming
that the normal period of detecting the hardware happens before the
hardware is getting used.

But yes, the thing I proposed is unstable if devices can get removed and
those devices end up in a list you depend on. Just like when I remove a
card from my computer.

Because if those removable devices end up in the PCI list and are used
in the enpXsY notation, you have the same problem in biosdev.

So you have two situations:

* If things can change order because of hotplugging, don't use a
condensed iteration scheme like I proposed
* (Don't use a condensed numbering scheme anyway for things that can
appear/disappear due to user intervention)

Maybe you think all devices fit into the category of things that can
appear/disappear.

However currently for me, biosdev renumbers these, while my scheme wouldn't.

The second situation is:

* Things that cannot change (biosdev) order would benefit from a scheme
that just condenses them.

Are you saying that in our current day life, everything is now up in the
water?

Thunderbolt can randomly change PCI numbers on the fly.
A hardware (onboard) networking device can suddenly pop out of nowhere 2
hours down the road reordering a (live) system.

Of course all of that can be solved with a little engineering, it
depends on what you want. Does make the solution more complex.

I'm not sure all of you are telling me the truth though.


> So I'll try asking a question instead:
> 
> 1. Why don't you follow the documented procedure to disable the feature
> you hate?  What's it with posting on the list repeatedly about it?

Are you stupid?

> 2. The new netdev naming system has made the lives of many people much
> better (me included).  Why should /your/ preference -- which would
> instantly make us all worse off -- become the new default, over our
> well-served needs?

Counter question: why do you think your needs are well served, but
anothers aren't?

Who are these many people? Who do you think you represent? Who are you
working for?

And in case you didn't notice I tried to come up with something that
wouldn't ruin the boot-after-boot stability (and I think I have)
although I didn't know that "hotplugging" is really the crux of the
issue here.

So why don't you explain how it has made your life better and what
scenario you have, instead? What kind of life do you have, that you
couldn't solve with fixed MAC addresses, (for instance) that got so much
better now?

What corner case individual are you?

Why don't you explain where you are coming from before you make such
allegations.

You do not creatively evaluate, but only assault. Perhaps you yourself
can come up with something that would 

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 12.04.2016 um 20:37 schrieb Xen:

Reindl Harald schreef op 12-04-16 11:24:


Regular hardware should not suddenly appear out of nowhere, but I do not
know about that Thunderbolt thing you mentioned


that is nonsense

* USB hardware is often *onboard* like SD-card slots on ProLiant
   machines down to the HP microserver
* touchpad is typically a internal USB device
* hotplug exists for SATA, SAS and many other interfaces

"that Thunderbolt thing you mentioned"? please do your homework
https://en.wikipedia.org/wiki/Thunderbolt_%28interface%29

not that i am a big fan of the "predictable" names but you appear
talking about things you have not much clue


Then do it yourself.


what?


If you know more about it. Someone has to take up the ball, right?


i did my homework


Why should some average user like me know everything about a system they
are designing just to say a few things on the topic of how utterly
insane the current solution is?


maybe you did not realize it:

i am just a user like you but with technical understanding, the point is 
that you talk about things which you don't gasp in a way like you are 
the king



Thunderbolt is a largely irrelevant technology from what it seems.


says who?


Recent years have seen a proliferation of new technologies but most
people don't even use them:

* DisplayPort, the vast majority of computer users may not ever have
used it.


tell that the 6 workstations i am responsible for


* USB 3.0, I have two cases that have a front USB 3.0 port, while having
motherboards that do not support them (I'm using eSATA, it is enough for
me) - and another motherboard with 3.0 at the back but no support for a
connector (I mean onboard).


it does not matter what is enough for you


When I look back at my parents, they have not even used a computer. I
grew up with the technology of the 80s / 90s. Now people are going crazy
about 4k displays. My mother uses less than a 37" display. I actually
mean 37cm. For a television, yes that small.


sad enough that you have no self-expierience
as i started prohramming i was 9 years old on a C64
frankly i used that thing until 1999

but what has this to do with the topic?


There are people in the world that cannot afford food, but we are
selling 4k displays that no one needs, and technology that goes with it
to support that data that, in the end, therefore, no one needs either.


but what has this to do with the topic?


Huge data, sure, it can use the technology, and maybe that is your
clientele. But that also makes it clear that this is not about regular
users, but probably only about server parks.


but what has this to do with the topic?


So Thunderbolt can connect PCIe prior to booting, causing it to obtain a
number on the PCI bus? See, I don't know the exact functioning of the
technology from reading that Wikipedia page (and I did, thank you).

If it does obtain a number on the PCI bus, it means disconnecting it
might do what? Have these people been honest about what actually happens?

For the most part, the more I learn the more I am astounded as to how
bad this technology is.


but what has this to do with the topic?


Well my apologies for not being as brilliant as I could be. I have been
a loser in life lately.


but what has this to do with the topic?


I would like to apologize to the entire human race ;-). I have let you
down :p ;-). For real.

In a certain sense yes You could say I have.

Or myself, or you, doesn't matter. Anyway.


but what has this to do with the topic?


The number of Thunderbolt devices is abysmally small and it is only
going to be a success relatively speaking due to USB-C, which is also
the reason USB 3 is going to be more of a sane thing in the end.


but what has this to do with the topic?


I do not even need Full HD in my home. I still watch DVDs and many
people don't have BluRay. I am happy with 720p, it is more than what I
need actually for the stuff I do.


but what has this to do with the topic?


If there is no provision to put Thunderbolt devices behind "regular"
PCIe, and there probably won't be, what is going to happen to the
biosdev naming scheme if such a device is removed? Did people think
about that? Do bus numbers stay the same? What then, what else?


but what has this to do with the topic?


Well my apologies for not having in-depth knowledge about these issues.


DO YOUR HOMEWORK about topics you start to talk about like you are the king


But I was led to believe biosdev led to stability and I based my
arguments on that, but it is not even stable in my own system.

We were talking specifically about networking here.

I do not know how many hotpluggable devices there are apart from USB,
I'm sorry.


DO YOUR HOMEWORK about topics you start to talk about like you are the king


It appears the standard provisions for "BCMA", "CCW" and a few other
things including "hotplug slot index number".

The USB hardware you mention is not going to appear out of nowhere.

Stay focussed 

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 12-04-16 11:24:

>> Regular hardware should not suddenly appear out of nowhere, but I do not
>> know about that Thunderbolt thing you mentioned
> 
> that is nonsense
> 
> * USB hardware is often *onboard* like SD-card slots on ProLiant
>   machines down to the HP microserver
> * touchpad is typically a internal USB device
> * hotplug exists for SATA, SAS and many other interfaces
> 
> "that Thunderbolt thing you mentioned"? please do your homework
> https://en.wikipedia.org/wiki/Thunderbolt_%28interface%29
> 
> not that i am a big fan of the "predictable" names but you appear
> talking about things you have not much clue

Then do it yourself.

If you know more about it. Someone has to take up the ball, right?

Why should some average user like me know everything about a system they
are designing just to say a few things on the topic of how utterly
insane the current solution is?

Thunderbolt is a largely irrelevant technology from what it seems.

Recent years have seen a proliferation of new technologies but most
people don't even use them:

* DisplayPort, the vast majority of computer users may not ever have
used it.

* USB 3.0, I have two cases that have a front USB 3.0 port, while having
motherboards that do not support them (I'm using eSATA, it is enough for
me) - and another motherboard with 3.0 at the back but no support for a
connector (I mean onboard).

When I look back at my parents, they have not even used a computer. I
grew up with the technology of the 80s / 90s. Now people are going crazy
about 4k displays. My mother uses less than a 37" display. I actually
mean 37cm. For a television, yes that small.

There are people in the world that cannot afford food, but we are
selling 4k displays that no one needs, and technology that goes with it
to support that data that, in the end, therefore, no one needs either.

Huge data, sure, it can use the technology, and maybe that is your
clientele. But that also makes it clear that this is not about regular
users, but probably only about server parks.

So Thunderbolt can connect PCIe prior to booting, causing it to obtain a
number on the PCI bus? See, I don't know the exact functioning of the
technology from reading that Wikipedia page (and I did, thank you).

If it does obtain a number on the PCI bus, it means disconnecting it
might do what? Have these people been honest about what actually happens?

For the most part, the more I learn the more I am astounded as to how
bad this technology is.

Well my apologies for not being as brilliant as I could be. I have been
a loser in life lately.

I would like to apologize to the entire human race ;-). I have let you
down :p ;-). For real.

In a certain sense yes You could say I have.

Or myself, or you, doesn't matter. Anyway.

The number of Thunderbolt devices is abysmally small and it is only
going to be a success relatively speaking due to USB-C, which is also
the reason USB 3 is going to be more of a sane thing in the end.

I do not even need Full HD in my home. I still watch DVDs and many
people don't have BluRay. I am happy with 720p, it is more than what I
need actually for the stuff I do.

If there is no provision to put Thunderbolt devices behind "regular"
PCIe, and there probably won't be, what is going to happen to the
biosdev naming scheme if such a device is removed? Did people think
about that? Do bus numbers stay the same? What then, what else?

Well my apologies for not having in-depth knowledge about these issues.

But I was led to believe biosdev led to stability and I based my
arguments on that, but it is not even stable in my own system.

We were talking specifically about networking here.

I do not know how many hotpluggable devices there are apart from USB,
I'm sorry.

It appears the standard provisions for "BCMA", "CCW" and a few other
things including "hotplug slot index number".

The USB hardware you mention is not going to appear out of nowhere.

Stay focussed here.

SATA and SAS are not networking technologies.

Thunderbolt can sponsor ethernet in its connection
(https://en.wikipedia.org/wiki/Apple_Thunderbolt_Display) -- I do not
know how that works, how should I know.

What happens when you plug this device in and out, even with biosdev? I
don't know.

The way it goes, I would not be surprised if it renumbers all your PCI
numbers.

In that case PCI index numbers are not a good provision, at least not if
they are used in device names. How on earth should I be able to find out
just like that.

Again, if this was the case, you'd be better off keeping some scheme
that identifies that device or that technology.

Don't hold me responsible for the mess you (or other people) have created.

And give our own solution if you want.

Bye.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 12-04-16 14:02:


> Am 12.04.2016 um 14:00 schrieb Xen:
>> Martin Pitt schreef op 12-04-16 12:57:
>>> Xen [2016-04-12  3:37 +0200]:
 The trick to turn it off on the website doesn't work:

 ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
>>>
>>> It does (at least on Debian, Ubuntu, and Fedora), but you need to
>>> rebuild your initrd after doing this.
>>
>> Alright, thanks. That isn't listed on the website. Sorry
> 
> the right way in doubt is to boot with following kernel params which i
> mentioned for sure in that thread and so don't get why "how to disable"
> ist still a topic (yes, they disable both of the 'predictable' pieces)
> 
> net.ifnames=0 biosdevname=0

You don't have to be so nasty you know. There is no right way to do
anything. I prefer not to touch my kernel (boot) configuration for
whatever reason I might have for that. I'm not sure what happens if I
could not depend on the current "grub" installation. Or what happens if
I need to boot from some other place. I prefer for the system to be
stable regardless of the boot loader. For instance, you can imagine
(re)booting into the current system using kexec. I know I am making an
ass of myself. But that is stuff I do. Or could want to do if it
actually worked for me.

Dependency on a boot loader that is in itself one of the most unreliable
pieces of software I have ever come across, is not really my favourite
thing I must say. I'm sorry if that sounds off.

I just wanted an on-disk configuration that is based on the system and
not on the bootloader, and it was possible before, and I didn't realize
why it was not possible now.

Editing /etc/default/grub is not really, you know.

On one occasion I have had a system where I could not use update-grub
because it didn't work, and I maintained a custom grub.cfg. Easy enough
to edit that as well, but Grub is not my piece of cake.

I'm sorry if that makes me sound like some idiot loser. I try to reduce
dependencies in my systems on stuff I find to be unreliable.

So if I can do this using some on-disk configuration file (or even a
symlink) that's better for me. Yes and I KNOW /etc/default/grub is also
on-disk. Don't mince words here, I mean, a regular config file.

That ideally gets used immediately, but whatever.

I just want to thank Martin Pitt for not being an ass about it (that I
might be myself, I don't know).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 12.04.2016 um 14:00 schrieb Xen:

Martin Pitt schreef op 12-04-16 12:57:

Xen [2016-04-12  3:37 +0200]:

The trick to turn it off on the website doesn't work:

ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules


It does (at least on Debian, Ubuntu, and Fedora), but you need to
rebuild your initrd after doing this.


Alright, thanks. That isn't listed on the website. Sorry


the right way in doubt is to boot with following kernel params which i 
mentioned for sure in that thread and so don't get why "how to disable" 
ist still a topic (yes, they disable both of the 'predictable' pieces)


net.ifnames=0 biosdevname=0



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Martin Pitt schreef op 12-04-16 12:57:
> Xen [2016-04-12  3:37 +0200]:
>> The trick to turn it off on the website doesn't work:
>>
>> ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
> 
> It does (at least on Debian, Ubuntu, and Fedora), but you need to
> rebuild your initrd after doing this.

Alright, thanks. That isn't listed on the website. Sorry.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Martin Pitt]

Xen [2016-04-12  3:37 +0200]:
> The trick to turn it off on the website doesn't work:
> 
> ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

It does (at least on Debian, Ubuntu, and Fedora), but you need to
rebuild your initrd after doing this.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Manuel Amador (Rudd-O)]

On 04/12/2016 02:26 AM, Xen wrote:
> Greg KH schreef op 12-04-16 00:14:
>>> Also, since the current scheme puts usb devices in a slightly different
>>> format you can identify them from the name.
>>>
>>> You are right in saying that that would cause a list that changes as it
>>> is getting populated. But onboard/builtin devices should definitely all
>>> be scanned before networking is initialized right?
>> Not true at all, drivers are loaded whenever, at pretty much random
>> times, when ever the hardware is found by the kernel.  It's
>> non-deterministic and you never know when it's done for some busses
>> (like USB).
> That is completely nonsensical because it would imply that some network
> device could be initialized 2 hours after the system had booted.

Greg KH is completely correct -- that can totally happen.

But it's clear that rational, calm, evidence-based arguments aren't
swaying you.

So I'll try asking a question instead:

1. Why don't you follow the documented procedure to disable the feature
you hate?  What's it with posting on the list repeatedly about it?
2. The new netdev naming system has made the lives of many people much
better (me included).  Why should /your/ preference -- which would
instantly make us all worse off -- become the new default, over our
well-served needs?

-- 
Rudd-O
http://rudd-o.com/




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 12.04.2016 um 04:26 schrieb Xen:

Greg KH schreef op 12-04-16 00:14

How you determine if a device is "onboard" or "offboard"?  Are you going
to know when all "onboard" devices are found before you do anything
else?  How?


I don't know, do you know? I am just a nitwit right.

The distinction I made was between USB and non-USB.

If you map the thing onto two separate lists, problem solved.

Regular hardware should not suddenly appear out of nowhere, but I do not
know about that Thunderbolt thing you mentioned


that is nonsense

* USB hardware is often *onboard* like SD-card slots on ProLiant
  machines down to the HP microserver
* touchpad is typically a internal USB device
* hotplug exists for SATA, SAS and many other interfaces

"that Thunderbolt thing you mentioned"? please do your homework
https://en.wikipedia.org/wiki/Thunderbolt_%28interface%29

not that i am a big fan of the "predictable" names but you appear 
talking about things you have not much clue




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Xen schreef op 12-04-16 04:26:

> I didn't even know it was that bad, jeez.
> 
> My apologies.

My sound stopped working as well because it was now a new device ;-)
(different PCI bus number).

The system sees it now as two devices, one of which is not present.

They are the same device of course.

Well, whatever.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Greg KH schreef op 12-04-16 00:14:
> On Mon, Apr 11, 2016 at 11:13:25PM +0200, Xen wrote:
 You can put usb devices at the end of the list.
>>>
>>> Why last?  How do you know they go last when scanning?  How do you know
>>> when / if they will show up?  What about 2 USB devices?  3?
>>
>> To me it seems obvious that you initialize onboard devices before USB
>> devices, so it would not be a "how do you know" because you do it yourself.
> 
> How you determine if a device is "onboard" or "offboard"?  Are you going
> to know when all "onboard" devices are found before you do anything
> else?  How?

I don't know, do you know? I am just a nitwit right.

The distinction I made was between USB and non-USB.

If you map the thing onto two separate lists, problem solved.

Regular hardware should not suddenly appear out of nowhere, but I do not
know about that Thunderbolt thing you mentioned.

That would imply that in the old scheme there were amazing problems just
about anywhere. I do not think this was the case.

"Solves real problems". You still have not identified "real problems"
that plagued more than 1% of the population.


>> Also, since the current scheme puts usb devices in a slightly different
>> format you can identify them from the name.
>>
>> You are right in saying that that would cause a list that changes as it
>> is getting populated. But onboard/builtin devices should definitely all
>> be scanned before networking is initialized right?
> 
> Not true at all, drivers are loaded whenever, at pretty much random
> times, when ever the hardware is found by the kernel.  It's
> non-deterministic and you never know when it's done for some busses
> (like USB).

That is completely nonsensical because it would imply that some network
device could be initialized 2 hours after the system had booted.

Don't make me cry.

Are you just pretending ignorance just so you can make stupid statements
about stuff that has always worked? What are you really trying to do?

I have never had any system where some hardware was suddenly found 3
hours down the line.

"whenever" -- no, not whenever, when the system starts.

Stop being so ridiculous please. This whole scheme is ridiculous. The
fact that my networking scripts will fail the moment I remove an add-on
card that has nothing to do with networking is completely and utterly
and downright ridiculous.

All PCI devices are recognised before networking starts, or networking
could never reliably start. The issue that a networking system would be
started before its required device was found, does not exist in reality,
as far as I can know, and if it did exist in reality, it would be a
terribly bad situation and everyone would be crying about it everywhere.

And I hardly doubt it is going to be "very" nondeterministic, I think if
I create and save kernel logs for my system here, it is going to be the
same each and every time.

Also, on my system the ethernet device driver is loaded within 2.6 seconds:

[2.589977] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded

Two USB devices (both usbsticks I think) within 2.7 seconds.

The renaming happens slightly after:

[2.656676] r8169 :02:00.0 enp2s0: renamed from eth0

An external hub at 2.9:

[2.889998] hub 1-4:1.0: 4 ports detected

And the last USB message occurs at 3.34 although directly after a number
of storage devices are recognised/initialized.

Of course the rationale for the whole system was randomness in device
recognition (particularly if recognition of multiple devices occurs in a
small time frame, I would guess). Nevertheless, apart from audio and
graphics messages occuring at a later time, within 4 seconds everything
that is vital to the operation of the machine is already recognised.

That means that given 'fixed' devices (present at boot) the whole
biosdev networking tree might already be available and not change anymore.

Of course if you start plugging devices that might change. So you keep
the port numbers for USB. I don't know about other technologies.

What's so hard really.


The thing that IS hard is finding out how to disable the thing without
passing kernel parameters. I had succeeded before, but the data on the
website is not correct. So I don't know how to do it.

It is just unacceptable that if you had some kind of static
configuration (of a network device) your configuration would fail and
your internet would fail because you plugged in some device.

And this is the reality today. You (the designers) made things much worse.

Now if you have some important networking setup, but you plug in a
networking card, the entire thing falls down its face. Or any other
card: the entire thing falls down its face.

Unless, I guess, if you say, the motherboard/bios is somehow perfect to
this scheme. Well, mine is not and it is a regular AMD Gigabyte
motherboard from around 2009.

We can see what would happen on my other system (recently purchased, but
might be an older motherboard).

But that might take a 

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Xen schreef op 11-04-16 23:13:

> No. You are causing pain and suffering to millions of people.
> 
> You (...) have not inquired with anyone whether they really wanted this.
> 
> So you push something and then you say "oh, but you can opt out".
> 
> So you place the burden on the user. It doesn't belong there.
> 
> It's the same with email spam marketeers. They send you unsollicited
> spam, and then they say "You only have to press this link to opt out".
> Courts throw these practices out the window, in business it is not legal.
> 
> It doesn't take much effort to think of a better scheme. But you don't
> think along, you only try to prove that my scheme can't work. And it is
> really not hard to imagine something that will work.
> 
> But now I am going to test my interface name stability. See ya.


So I put it to the test.

I remove an addon card that has nothing to do with networking, and my
interface name has changed from enp3s0 to enp2s0, as predicted.

So the system is not stable AND it is not predictable.

FAIL.

THIS IS WORSE THAN BEFORE.

You people (the ones who have designed it) you can really in all
seriousness maintain you have done a good job?

I am sorry I have held back.

You have created a system that is stable across reboots (probably) BUT
now it is unstable with regards to any hardware change to the system.

Yes, blame my motherboard manufacturor.

Well I guess I have already silenced myself here. Sorry about that.

The trick to turn it off on the website doesn't work:

ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

So in order to do the remapping we have access to PCI, which is
unstable, and MAC which prevents redeployable images. We could map the
biosdev to a linear list or set of lists, which would solve most
problems for everyone, except if you use multiple USB devices, so you
just use a different scheme for that. Problem solved right.

Does anyone know how I can disable the renaming in some other way than
using kernel options? The above doesn't work. I cannot find the answer
anywhere.

Thanks.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Mon, Apr 11, 2016 at 11:13:25PM +0200, Xen wrote:
> >> You can put usb devices at the end of the list.
> > 
> > Why last?  How do you know they go last when scanning?  How do you know
> > when / if they will show up?  What about 2 USB devices?  3?
> 
> To me it seems obvious that you initialize onboard devices before USB
> devices, so it would not be a "how do you know" because you do it yourself.

How you determine if a device is "onboard" or "offboard"?  Are you going
to know when all "onboard" devices are found before you do anything
else?  How?

> Also, since the current scheme puts usb devices in a slightly different
> format you can identify them from the name.
> 
> You are right in saying that that would cause a list that changes as it
> is getting populated. But onboard/builtin devices should definitely all
> be scanned before networking is initialized right?

Not true at all, drivers are loaded whenever, at pretty much random
times, when ever the hardware is found by the kernel.  It's
non-deterministic and you never know when it's done for some busses
(like USB).

Best of luck,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Greg KH schreef op 11-04-16 22:21:
> On Mon, Apr 11, 2016 at 08:49:48PM +0200, Xen wrote:
>> It will just not be "predictable" when you remove or add hardware,
>> because that reorders the resulting lists.
>>
>> Ie, if you have:
>>
>> ethernet0
>> ethernet1
>> ethernet2
>>
>> And you add a new device, it might become:
>>
>> ethernet0
>> ethernet1
>> ethernet2  <-- new device
>> ethernet3
>>
>> But is that really an issue?
> 
> Yes, it is, otherwise if it wasn't, this scheme is identical to the "no
> naming scheme at all"

Apparently you just said the current scheme is identical to that as well
(for my system).

I thought the reason for this system was stability across reboots.

If the biosdev system is stable across reboots, this one will be as
well. The old system was not stable across reboots, so what you say is
not true.


>> You can put usb devices at the end of the list.
> 
> Why last?  How do you know they go last when scanning?  How do you know
> when / if they will show up?  What about 2 USB devices?  3?

To me it seems obvious that you initialize onboard devices before USB
devices, so it would not be a "how do you know" because you do it yourself.

Also, since the current scheme puts usb devices in a slightly different
format you can identify them from the name.

You are right in saying that that would cause a list that changes as it
is getting populated. But onboard/builtin devices should definitely all
be scanned before networking is initialized right?

That means that part of the list is going to be stable for networking is
used.

Last, because regular onboard devices do not suddenly evaporate after
having been initalized.

This conceptually separates the list so that usb devices cannot change
the 'hardware' devices or its list (as it is the first part that is
never going to change again during the running of the system).

That is why "last" (makes sense, no?).

So indeed if you had multiple usb devices that you keep plugging and
unplugging, indeed they would not have stable names.

The provision for USB identification depends entirely on port numbers:

"For USB devices the full chain of port numbers of hubs is composed."

That means if you pull out some device and put it in a different port,
its name will change.

Given this fact, the stability you get is minimal at best.

So now is the question, under what scenario are you going to be basing
advanced routing configuration on fixed usb port numbers Wouldn't
that be insane to begin with?

Now you have a certain routing setup but it only works if you use the
same usb ports and hubs for connecting it

Is that a real scenario? No, it isn't. More common would be the scenario
to have ONE usb device that you use in whatever port.

In the current system, it constantly changes name. In my proposed
system, it would probably always have the same name. Because an usb port
number is not meaningful.

So now you have the corner case scenario where someone uses 2 usb
devices of the same kind in fixed port positions and wants to build some
kind of routing on that.

In general you would not do anything of that kind but okay. USB and
"fixed system" is not exactly in agreement with each other. But okay.

Now you have your 2nd USB device plugged in but your first isn't. Second
based on port number / path.

If both were plugged in you would have:

wireless0  <-- first device
wireless1  <-- second device

(Just assuming these are wireless dongles)

Now you only plug the second and it becomes:

wireless1  <-- second device

Now at some point you plug the first, and the name changes.

Dynamically, while having a running system.

In the current system, their names do not change because they are based
on port.

I do not know what the "old" system did. I'm sure this never happened
because people thought about it. I'm sure you can base device names on
something else if that is necessary.

You could even turn it into "wireless-usb-u1u4i6" or something similar.

People do not care about the names of usb devices. Mostly.

They accept that these names might be quite random from their point of view.

So if you must, keep basing your name on that. I mean, what's the issue.

wlp0s29u1u2 is however pretty nondescript. Why not something a tad longer.

Something that does not require knowledge of the scheme to know that "u"
designates port number. In order to divine that this is an usb device.

Nobody who plugs in USB devices is going to want it to conform to
"eth0". That is just nonsense. People don't want that. Every computer
has a built in LAN port (except for some laptops etc). We expect it to
have an easy name. Every laptop has a built-in wlan port. We expect it
to have an easy name. Anything extra -- temporary usb connections and
the like, we don't care as much.

Since these port numbers change, you cannot base any persistent routing
on usb devices anyway. Not anything that cannot be automatically
configured. The only thing that is required is stabilty across the

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Mon, Apr 11, 2016 at 08:49:48PM +0200, Xen wrote:
> It will just not be "predictable" when you remove or add hardware,
> because that reorders the resulting lists.
> 
> Ie, if you have:
> 
> ethernet0
> ethernet1
> ethernet2
> 
> And you add a new device, it might become:
> 
> ethernet0
> ethernet1
> ethernet2  <-- new device
> ethernet3
> 
> But is that really an issue?

Yes, it is, otherwise if it wasn't, this scheme is identical to the "no
naming scheme at all"

> You can put usb devices at the end of the list.

Why last?  How do you know they go last when scanning?  How do you know
when / if they will show up?  What about 2 USB devices?  3?

It looks like you really want the old-style naming scheme, which is
great, you have the ability to roll back to that.  Please do so.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Mon, Apr 11, 2016 at 08:49:48PM +0200, Xen wrote:
> It will just not be "predictable" when you remove or add hardware,
> because that reorders the resulting lists.
> 
> Ie, if you have:
> 
> ethernet0
> ethernet1
> ethernet2
> 
> And you add a new device, it might become:
> 
> ethernet0
> ethernet1
> ethernet2  <-- new device
> ethernet3
> 
> But is that really an issue?

Yes, it is, otherwise if it wasn't, this scheme is identical to the "no
naming scheme at all"

> You can put usb devices at the end of the list.

Why last?  How do you know they go last when scanning?  How do you know
when / if they will show up?  What about 2 USB devices?  3?

It looks like you really want the old-style naming scheme, which is
great, you have the ability to roll back to that.  Please do so.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Greg KH schreef op 11-04-16 01:05:
> On Mon, Apr 11, 2016 at 12:27:24AM +0200, Xen wrote:
>> Michael Biebl schreef op 11-04-16 00:22:
>>> So why don't you implement such a scheme? Talk is cheap
>>
>> Criticising an idea by saying "do it yourself" is even cheaper.
>>
>> MUCH MUCH cheaper.
>>
>> Idiot.
> 
> No he isn't.  The developers here put a lot of thought and energy
> working with numerous hardware requirements an user cases in order to
> come up with the current situation.  It works for almost everyone, which
> is vastly better than the previous scheme of "first driver loaded
> wins!", which barely worked for anyone, and caused so many problems it
> wasn't funny (just ask any of us who have been in support for a distro
> about the problems...)

I am sorry, I had wanted to explain. It is really no ones business why
you are not doing a certain thing.

For all you know someone is not capable of programming. For all you know
someone is not versed in C, or does not have the health to do such a thing.

If you are really that unimaginative to consider that there might
actually be good reasons why someone does not do a certain thing, you
are an idiot.

People like cheap labour.

I will keep it at that for now.


> If you have an alternative proposal, great, it can be fit into the
> existing system (note the heirachy of names that are picked depending on
> just how well your hardware describes itself.)  Please propose that.

I just did.

I proposed transforming the tree-like biosdev names into a linear
display, the way you can traverse a tree and produce a list.

If the biosdev names are a model of the networking hardware, that does
not imply it has to be the presentation.

You can transform the biosdev names (that are now stable, or unique)
into a presentation that agrees with the "old" names:

ethernet0
ethernet1
loopback
wireless0

bridge0

Whatever. Most systems do not have more than 1 or 2 networking devices.
If you have 2 physical nics, you probably won't also have wireless. If
you have wireless + ethernet, you might not have a 2nd wired ethernet.

You can traverse the biosdev tree and produce a list.

That was my proposal.


> If you don't like the current scheme, that's also fine, there is a
> trivial way to "opt-out" of it.
> 
> So I don't understand your complaints, you don't like the current
> scheme, yet you don't have any proposal other than "I liked the original
> way", which you still have access to.  So really, there isn't anything
> to change here that I can see, unless you have a new naming scheme that
> can be implemented as well?

That was what my whole message was about.

However, the biosdev names are not available for mapping.

Only the MAC and PCI are (as far as I know).

The naming scheme is not really important (from the viewpoint of the
creators' requirements) -- only the stability is.

Even if you lose some information when you transform the tree to a list,
or several lists, this does not impact the stability. It might impact
the predictability -- whatever it is worth, but not the stability.

Having names such as "ethernet0" "ethernet1" gives less information, but
a user does not need that information.

If the biosdev "tree" for a system is stable, then so will be a linear
transformation of that (a traversal into a list or several lists).

However this is not trivial for a user to implement because the biosdev
names are already the result of a mapping and cannot be changed.

You can only operate on their source, which is a tad complex for an
ordinary user to do, and would throw away the work the people have done.

So why not:

enp3s0 --> ethernet0
wlXX --> wireless0
lo --> loopback
br0 --> bridge0

and so forth?

It is readable, it is user friendly, if biosdev is stable, so will this
be stable. It has all the benefits of biosdev scheme except for:
predictability.

But is this not actually MORE predictable?

- If the biosdev ordering does not change, neither will this.
- The first ethernet device will again be called ethernet0 on all systems
- The first wireless device will again be called wireless0 on all systems

- You use the work the systemd people have done as a foundation to
create the stability, but you do away with the presentation of it as
something the user needs to see.

So I say simply TRANSFORM THE TREE.

Turn it into lists. What do you lose?

It will just not be "predictable" when you remove or add hardware,
because that reorders the resulting lists.

Ie, if you have:

ethernet0
ethernet1
ethernet2

And you add a new device, it might become:

ethernet0
ethernet1
ethernet2  <-- new device
ethernet3

But is that really an issue?

You can put usb devices at the end of the list.

Regards, Bart.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Mon, Apr 11, 2016 at 12:27:24AM +0200, Xen wrote:
> Michael Biebl schreef op 11-04-16 00:22:
> > So why don't you implement such a scheme? Talk is cheap
> 
> Criticising an idea by saying "do it yourself" is even cheaper.
> 
> MUCH MUCH cheaper.
> 
> Idiot.

No he isn't.  The developers here put a lot of thought and energy
working with numerous hardware requirements an user cases in order to
come up with the current situation.  It works for almost everyone, which
is vastly better than the previous scheme of "first driver loaded
wins!", which barely worked for anyone, and caused so many problems it
wasn't funny (just ask any of us who have been in support for a distro
about the problems...)

If you have an alternative proposal, great, it can be fit into the
existing system (note the heirachy of names that are picked depending on
just how well your hardware describes itself.)  Please propose that.

If you don't like the current scheme, that's also fine, there is a
trivial way to "opt-out" of it.

So I don't understand your complaints, you don't like the current
scheme, yet you don't have any proposal other than "I liked the original
way", which you still have access to.  So really, there isn't anything
to change here that I can see, unless you have a new naming scheme that
can be implemented as well?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Michael Biebl schreef op 11-04-16 00:22:
> So why don't you implement such a scheme? Talk is cheap

Criticising an idea by saying "do it yourself" is even cheaper.

MUCH MUCH cheaper.

Idiot.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Michael Biebl]

So why don't you implement such a scheme? Talk is cheap

2016-04-10 18:22 GMT+02:00 Xen :
> I just want to present my conclusion here succintly.
>
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
>
> Was introduced to safeguard against a rare occasion where an important
> network computer in a critical environment would suffer from the kernel
> anomaly that assigned network interface names may be unreliable.
>
> In any system not configured by the system administrator to cater to
> this issue, even simply forgetting to do it could result in some
> security breach.
>
> This is how I read the issue today. The designers wanted to create
> something that would never fail, and never cause this scenario to happen.
>
> But now all desktop users pay the price of having incomprehensible names
> for their network devices, and all server administrators who like
> writing scripts or defining firewalls have to deal with names that are
> going to change from system to system.
>
> There is a solution to map the original hardware devices (not the new
> names) to more meaningful names by manual choice. However, this is not
> usually implemented and I do not know of any distribution that does this
> by default.
>
> The solution requires the user to either know about the way to find help
> (man systemd.link) or to look it up on the web (and know that systemd
> causes it). Then he or she needs to create multiple files for each
> interface containing either the hardware address (MAC) that is easy to
> find, or the PCI bus address according to udev that is less easy to find.
>
> While many people would probably like a more comprehensible naming
> scheme, the burden is now on each individual user to create it, while a
> consensus on a regular scheme would not be hard to reach.
>
> For instance, calling wired internet devices "ethernet0" while wireless
> ones would be called "wireless0" would not be an odd thing to do at all.
>
> So what I am simply calling for is for distributions to make a choice in
> the names they want, and then to configure it by default.
>
> PCI hardware names can be mapped to predictable names, most likely. MAC
> addresses could equally be used.
>
> The only thing to decide upon is the actual naming scheme. As said,
> "ethernet#" and "wireless#" would be obvious.
>
> It wouldn't take more for a distribution's installer than to find these
> devices and create mapping files based on them.
>
> The configuration with multiple files in /dev/systemd/network is not
> easy, but for an installer that would not be an issue. The configuration
> is not easily discoverable by any user traversing the filesystem, nor is
> it intuitive to use multiple files for a single configuration but a
> likelihood of a user needing to change it, would be very low.
>
> If you want systemd to make sense, you must make it easier for users.
>
> The names I propose would be easy to understand and contain no risk for
> the scenario I described unless hardware is removed from a system (but
> not put back).
>
> And it might not even have that issue.
>
> Comprehensibility increases legibility and it could even reduce the risk
> of some administrator making mistakes.
>
> What it would create on a desktop OS is user-friendly names while having
> scarcely any implication, or not at all, for the risk situation
> described. PCI bus addresses could be used by default, or MAC addresses
> if that was an issue. The kernel-based reordering as described would
> never happen.
>
> And all it requires is for the current system to create a default
> mapping that requires the installer of the system to do some work.
>
> And not much.
>
> So what I vouch for is a default mapping, that is all.
>
> A default mapping to names such as "wireless0" "ethernet0". People could
> also think about renaming "lo" to "loopback".
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

I just want to present my conclusion here succintly.

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Was introduced to safeguard against a rare occasion where an important
network computer in a critical environment would suffer from the kernel
anomaly that assigned network interface names may be unreliable.

In any system not configured by the system administrator to cater to
this issue, even simply forgetting to do it could result in some
security breach.

This is how I read the issue today. The designers wanted to create
something that would never fail, and never cause this scenario to happen.

But now all desktop users pay the price of having incomprehensible names
for their network devices, and all server administrators who like
writing scripts or defining firewalls have to deal with names that are
going to change from system to system.

There is a solution to map the original hardware devices (not the new
names) to more meaningful names by manual choice. However, this is not
usually implemented and I do not know of any distribution that does this
by default.

The solution requires the user to either know about the way to find help
(man systemd.link) or to look it up on the web (and know that systemd
causes it). Then he or she needs to create multiple files for each
interface containing either the hardware address (MAC) that is easy to
find, or the PCI bus address according to udev that is less easy to find.

While many people would probably like a more comprehensible naming
scheme, the burden is now on each individual user to create it, while a
consensus on a regular scheme would not be hard to reach.

For instance, calling wired internet devices "ethernet0" while wireless
ones would be called "wireless0" would not be an odd thing to do at all.

So what I am simply calling for is for distributions to make a choice in
the names they want, and then to configure it by default.

PCI hardware names can be mapped to predictable names, most likely. MAC
addresses could equally be used.

The only thing to decide upon is the actual naming scheme. As said,
"ethernet#" and "wireless#" would be obvious.

It wouldn't take more for a distribution's installer than to find these
devices and create mapping files based on them.

The configuration with multiple files in /dev/systemd/network is not
easy, but for an installer that would not be an issue. The configuration
is not easily discoverable by any user traversing the filesystem, nor is
it intuitive to use multiple files for a single configuration but a
likelihood of a user needing to change it, would be very low.

If you want systemd to make sense, you must make it easier for users.

The names I propose would be easy to understand and contain no risk for
the scenario I described unless hardware is removed from a system (but
not put back).

And it might not even have that issue.

Comprehensibility increases legibility and it could even reduce the risk
of some administrator making mistakes.

What it would create on a desktop OS is user-friendly names while having
scarcely any implication, or not at all, for the risk situation
described. PCI bus addresses could be used by default, or MAC addresses
if that was an issue. The kernel-based reordering as described would
never happen.

And all it requires is for the current system to create a default
mapping that requires the installer of the system to do some work.

And not much.

So what I vouch for is a default mapping, that is all.

A default mapping to names such as "wireless0" "ethernet0". People could
also think about renaming "lo" to "loopback".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel