On Tue, Feb 16, 2010 at 12:04:07AM +0100, Marco d'Itri wrote:
> On Feb 15, Josh Triplett <[email protected]> wrote:
>
> > to achieve the same effect. However, it seems worth documenting this in
> > the "Network Interfaces" section of README.Debian as the suggested
> > approach to avoid the renaming. Suggested text:
> Fair enough, I will add something.
Thanks!
> > I think that would help; however, I also wonder if some approach might
> > exist to figure out when renaming will do more harm than good, to handle
> > this more automatically.
> Many smart people considered this issue multiple times but did not find
> any good solution. While a breakthrough is obviously possibile, I am not
> optimistic.
Fair enough.
> > Does any means exist to give an interface multiple names and have them
> > all work?
> No. If you really want to know why implementing this would not really be
> such a great idea you can find a long thread about it in the
> linux-hotplug list archive of about six months ago.
"Network Device Naming mechanism and policy"?
I certainly found the idea of having dummy /dev devices that do nothing
other than provide names rather ridiculous. I've read a decent chunk of
the thread, but I didn't see anything obvious suggesting why it would
prove bad to have *real* /dev devices, though, and that seems like a
really good idea. A net device equivalent to the symlinks in
/dev/disk/by-uuid/ seems like it would solve the problem perfectly.
Without asking you to do any implementation in this area, might I ask
you if the concept of a real /dev/eth0 that actually allows
configuration of eth0 seems excessively insane? It doesn't seem
fundamentally that hard to implement. (Famous last words... :) ) The
/dev/eth* devices could simply support the same SIOC{G,S}IF* ioctls,
minus the ifr_name. Similarly, patches to support that model in tools
(using a filename instead of an ifr_name) don't seem that hard either.
Of course, even without doing that, network-device-using programs like
ifupdown could potentially handle it themselves. get-mac-address.sh
comes to mind.
- Josh Triplett
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/20100216193436.gf19...@feather
