[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 that this was reality at this point in time or that the
current situation actually agrees with what you say, in other words,
whether we have that system you describe at all.

> 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.)

Apparently not. The kernel document I referenced does not use "events"
to poll for hardware.

So that is not the only way AT ALL how it "can work properly" events and
polling is like the opposite of each other.

I think diving into some source code would quickly solve this issue, but
now people are having me prove that the sun is indeed rather hot before
they'll accept it of me.

Events are some external thing. It is responding to something external.
Device discovery is not an event-based function. Devices do not announce
their presence using events because events are only bound to devices
(IRQs) after the device has been discovered. Get it? It is the device
driver that needs to bind the IRQ to it (in the software).

But I'm gonna quit this, this is just nonsense, have it your way.


> good luck!

What, solving your puzzles?