| 1 |
On 5 August 2013, at 18:28, Alan McKinnon wrote: |
| 2 |
> ... |
| 3 |
> So why change this? Because you can't rely on ethX always being the same |
| 4 |
> physical hardware. On a firewall or router, you absolutely need to rely |
| 5 |
> on this. The udev scheme works around this by letting you specify exact |
| 6 |
> rules that will always do what you want. |
| 7 |
> |
| 8 |
> Why was this changed rammed down your throat? Well, that is political. |
| 9 |
> |
| 10 |
> The udev maintainers (along with systemd) work for Red Hat. RH's market |
| 11 |
> is almost totally servers, and big multi-nic ones at that. They really |
| 12 |
> need consistent names, doubly so if the host is a virtualization host. |
| 13 |
> |
| 14 |
> The catch: RH (or more exactly the udev maintainer employed by RH) |
| 15 |
> probably couldn't give a toss what you think or want, and went ahead and |
| 16 |
> fixed their problem expecting you to "deal with it or shove off" |
| 17 |
|
| 18 |
|
| 19 |
I believe this all stems from the rejection of BIOS dev names by Linus &/or the kernel folks. |
| 20 |
|
| 21 |
This would have allowed the kernel to determine which interfaces were eth0 / eth1 from the BIOS / firmware of next gen server machines. |
| 22 |
|
| 23 |
An open "standard" to present this information through the firmware was agreed between at least Dell and one other major server vendor (HP springs to mind). |
| 24 |
|
| 25 |
The patches were rejected by the kernel folks because they risked renaming the interfaces on the small number of machines already in service with this firmware facility. |
| 26 |
|
| 27 |
I believe the response was "do it in userspace, go talk to the udev guys", and the rest is history. |
| 28 |
|
| 29 |
Stroller. |
Archives