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] Configuring ethernet link fails with No such device

[Stefan Agner]

[added Tom Gundersen as he seemed to have worked on udev's net link
built-in]

On 2016-04-12 08:44, David Miller wrote:
> From: Bob Ham 
> Date: Tue, 12 Apr 2016 09:58:12 +0100
> 
>> On Mon, 2016-04-11 at 15:46 -0700, Stefan Agner wrote:
>>
>>> Or in other words: Is this a Kernel or systemd issue?
>>
>> From what I recall, both; an issue with the FEC driver, and issues in
>> systemd/udevd's handling of link-level settings.
> 
> This is my impression of the situation as well.

The execution order looks as follows for the FEC driver (taken from a
recent kernel with some additional printks, serial console):

...
[1.157086] fec_probe
...
[1.190350] fec_enet_mii_init
[1.205446] libphy: fec_enet_mii_bus: probed
[1.217849] fec 400d1000.ethernet eth0: registered PHC device 0
...
[   10.751060] dev_ethtool, rc -19 => (ETHTOOL_GSET) Too early...
[   11.262333] fec_enet_open
[   11.479928] fec_enet_mii_probe => Or/and too late...

Looking at the journal:
...
Apr 13 01:02:49 colibri-vf systemd[1]: Started udev Coldplug all
Devices.
...
Apr 13 01:02:50 colibri-vf kernel: mdev_ethtool, rc -19
...
Apr 13 01:02:50 colibri-vf systemd-udevd[197]: Could not set speed or
duplex of eth0 to 0 Mbps (half): No such device
...
Apr 13 01:02:51 colibri-vf kernel: fec_enet_open
...
Apr 13 01:02:51 colibri-vf kernel: fec_enet_mii_probe

The service "udev Coldplug all Devices" essentially executes:
udevadm trigger --type=subsystems --action=add ; udevadm trigger
--type=devices --action=add

I guess the "add" udev event is generated due to the fact that the
device has successfully been probed. If the kernel is allowed to
initialize the PHY as late as at open time, systemd should configure the
link at a point after link up... Do you agree on that?

Afact there is no udev event on link up, hence this would not be a mere
udev rule change...?

So I think the issue is either a systemd/udev issue or a FEC driver
issue. And the solution is one of this two options:
- Move (all the) PHY probes at driver probe time, then the PHY will be
probed when udev processes the add event
- Or move systemd/networkd/udev link processing, set the link settings
only after the device has been opened (link up).

Florian brought up a good point in another answer:
> Part of the reason for doing that, is that probing for the PHY during
> the driver's probe function could leave you with unused HW that is
> powered on for no good reason. Until we get into ndo_open, we have no
> clue if the interface is going to be used or not, so it is better to
> move part of the HW initialization as late as possible in the process.

Therefor I think only option 2 is actually viable.

--
Stefan






___
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] centos-ci

[Lennart Poettering]

On Tue, 12.04.16 14:57, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

> >Right now the CI systems we use are all based on Ubuntu, which is
> >kinda weird, as most of the systemd core developers actually work for
> >RH and run Fedora locally... ;-)
> 
> I see but It's should not matter which company you work for or which
> distribution upstream developers favor otherwise you end up risking bias-ing
> the product on those favored downstream distribution or the (current)
> employment which is one of the root cause for the existing fragmentation in
> the first place.

we just want to test things on both major flavours of linux
distros. debian/ubuntu-style distros are nicely covered, and we'll
also have redhat/fedora-style distros covered with the rhel thing now.

With systemd we support quite a number of distros, and if we cover
those two flavours, then we should be in a pretty good state.

> And based on your response I have to ask, is someone higher up the Red hat
> ladder yanking your chain and thus the project loosing it's independence in
> the process or has your and other systemd's core developers view on the
> matter being independent changed?

Seriously, Johann? 

The rhel-ci people offered us to use their spare machines, that's
all. And Daniel took them up on it, and is now working on getting this
hooked up.

You completely misunderstand how Red Hat works...

In reality, I sometimes wished RH would provide us with more of
infrastructure services for systemd development. In fact though, we
pretty much never used any RH infrastructure. It's all github, fdo,
semaphore and the Ubuntu-ci stuff run by Canonical. In fact, Canonical
contributed more infrastructure to systemd development so far than RH
did.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Configuring ethernet link fails with No such device

[David Miller]

From: Bob Ham 
Date: Tue, 12 Apr 2016 09:58:12 +0100

> On Mon, 2016-04-11 at 15:46 -0700, Stefan Agner wrote:
> 
>> Or in other words: Is this a Kernel or systemd issue?
> 
> From what I recall, both; an issue with the FEC driver, and issues in
> systemd/udevd's handling of link-level settings.

This is my impression of the situation as well.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] centos-ci

[Jóhann B . Guðmundsson]

On 04/12/2016 02:43 PM, Lennart Poettering wrote:

On Tue, 12.04.16 11:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:


Anyone know that centos is not running the latest version(s) of systemd
required for the upstream bug tracker so one has to ask what notification
spam is this
"Can one of the admins verify this patch?"

Daniel is working on adding a CI infrastructure that allows us
building things on a RHEL-based system for each PR. This is work in
progress, and the spamming of the PRs with the mentioned line an
unfortunate mistake.

We have no intention to support upstream systemd on such old RHELs,
but the test systems are hacked enough with never packages to allow us
test things on Red-Hat-based systems.

Right now the CI systems we use are all based on Ubuntu, which is
kinda weird, as most of the systemd core developers actually work for
RH and run Fedora locally... ;-)


I see but It's should not matter which company you work for or which 
distribution upstream developers favor otherwise you end up risking 
bias-ing the product on those favored downstream distribution or the 
(current) employment which is one of the root cause for the existing 
fragmentation in the first place.


And based on your response I have to ask, is someone higher up the Red 
hat ladder yanking your chain and thus the project loosing it's 
independence in the process or has your and other systemd's core 
developers view on the matter being independent changed?


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

Re: [systemd-devel] centos-ci

[Lennart Poettering]

On Tue, 12.04.16 11:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

> Anyone know that centos is not running the latest version(s) of systemd
> required for the upstream bug tracker so one has to ask what notification
> spam is this
> "Can one of the admins verify this patch?"

Daniel is working on adding a CI infrastructure that allows us
building things on a RHEL-based system for each PR. This is work in
progress, and the spamming of the PRs with the mentioned line an
unfortunate mistake.

We have no intention to support upstream systemd on such old RHELs,
but the test systems are hacked enough with never packages to allow us
test things on Red-Hat-based systems.

Right now the CI systems we use are all based on Ubuntu, which is
kinda weird, as most of the systemd core developers actually work for
RH and run Fedora locally... ;-)

Lennart

-- 
Lennart Poettering, Red Hat
___
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

[systemd-devel] centos-ci

[Jóhann B . Guðmundsson]

Anyone know that centos is not running the latest version(s) of systemd 
required for the upstream bug tracker so one has to ask what 
notification spam is this

"Can one of the admins verify this patch?"

JBG
___
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] Configuring ethernet link fails with No such device

[Bob Ham]

On Mon, 2016-04-11 at 15:46 -0700, Stefan Agner wrote:

> The FEC driver (fec_main.c) does not initialize phy_dev until the
> device
> has been opened, and therefor the callback
> fec_enet_(get|set)_settings
> returns -19.

I saw the same problem with the FEC driver.  From what I recall, it
became clear that there was a problem with the driver returning from
the eth device initialisation before the PHY was initialised, which
apparently is Bad and Wrong.

> Or in other words: Is this a Kernel or systemd issue?

From what I recall, both; an issue with the FEC driver, and issues in
systemd/udevd's handling of link-level settings.

-- 
Bob Ham 
Software Engineer


Open First 
Collabora is hiring!
Please check out our latest opportunities here:
http://bit.ly/Collabora-Careers




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

Re: [systemd-devel] Configuring ethernet link fails with No such device

[Stefan Agner]

On 2016-04-11 18:29, David Miller wrote:
> From: Stefan Agner 
> Date: Mon, 11 Apr 2016 15:46:08 -0700
> 
>> What is the expectation/definition when link configuration should be
>> possible? Only after the network device got opened or before?
> 
> Only after it is open.  Drivers almost always have the entire chip in
> powerdown state when it is not open, so we wouldn't be able to
> properly do link settings even if we wanted to when the device is
> closed.

I see. Afact it is a udev rule which triggers the built-in link setup
code:
https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/rules/80-net-setup-link.rules

The udev rule is triggering on action add (=> probe on driver level). At
least on the device I tested, it seems that there is no event on open...
Any other ideas what could be used as trigger to configure the link?

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

Re: [systemd-devel] Callback or Event Notification from journald in case of crash

[Mantas Mikulėnas]

On Wed, Apr 6, 2016 at 7:04 AM, P.R.Dinesh  wrote:

> I am using systemd, journald and systemd-coredump in my system.  When a
> process crashes the systemd-coredump util handles the core dump and logs a
> message in the journal with MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1
>
> Now I want to add a routine which will do post crash activities, For eg.,
> blinking a fault led in the system.
>
> I think we can poll the journal for the crash message, but is there any
> other optimal way to register for a callback from journal which will be
> triggered whenever a message of particular MESSAGE_ID is received.
>

Well, you can use sd_journal_get_fd()+poll() instead of periodic checking,
but other than that, there aren't any sort of callbacks yet – you'll have
to filter out messages on your side.

Though I wonder if systemd-journal-remote could help here? If there are
multiple clients, doing the filtering in sd-journal-remote would probably
be more efficient than in each client...

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