On 12/01/2009 11:59 AM, Narendra K wrote:
>>
>> ... I think the UI suggested here is really bad, as is the process behind
>> it. Adding a "pick your network device name" step anywhere in anaconda, even
>> in kickstart, is a bad plan. A better plan would be something like:
>>
>> 1) make kickstart accept various different names by using libnetdevname or
>> something similar
>> 2) make libnetdevname capable of telling us a reasonable name for an interface
>> for user display (i.e. smbios name with spaces instead of _ or somesuch)
>> 3) display and log those names (and /possibly/ the real interface name) where
>> appropriate, which might include something like a "details" section describing
>> a particular interface.
>>
>
> Libnetdevname is needed when we have to map pathnames like
> /dev/netdev/by-chassis-label/Embedded_NIC_1 to ethN names. Since we do
> not have these pathnames, libnetdevname is useless here.Biosdevname
> can suggest names to anaconda which can be shown to the users.
Sure, we don't have those because udev doesn't have that logic. But the idea
behind libnetdevname can still be applied without that, though it makes the
library /somewhat/ more complex. There's nothing about the translation of "Embedded_NIC_1" to "if_index 0" that can't be entirely done in userland,
is there?
>> You mean the kernel name here, not the "OS" name. And in general, changing
>> the kernel names isn't something we want. That's why we went down the whole
>> aliasing route in the first place!
>
> The idea of multiple names for network interface devices, which allows
> the ethN names to remain unaltered, was not accepted. An installer based
> fix was suggested. Hence this proposal.
I don't understand why the response to "we won't do this in the kernel" is
"pick an entirely different model" rather than "move more of the logic to
the library". I think the model we had talked about with kernel aliasing
will still work, even though the implementation isn't as clean from any of
our points of view - libnetdevname simply has to do all the alias translation
itself, and applications supporting aliases have to use it instead of simply
consulting the udev database[1]. But that doesn't mean we can't use essentially
the same usage model and UI we'd talked about before.
I think any UI that has the user selecting which sort of thing they'd like
to use is bad. I think the right answer is really:
1) provide a library which can:
a) identify a kernel interface name for a given alias
b) provide a list of aliases for a given kernel interface name
c) tell us which alias is "descriptive", which in dell's
case means the SMBIOS name
2) provide a command line tool suitable for use in scripting to:
a) tell us the kernel name for a given alias
b) list aliases for a given kernel interface name
c) tell us which kernel name is "descriptive"
3) modify kickstart handlers to allow users to specify whichever kernel name
or alias is they want, and simply error if it's not a name the library
can resolve
4) modify anaconda's UI to display the "descriptive" name most of the time,
and possibly add some "more details" sorts of UI elements to say "by the
way, that devices is named eth0 in the kernel and is port 3 on
/sys/devices/pci0000:00/blah (i.e. list the aliases)
5) make other tools, such as ifup and NetworkManager, use the "descriptive" name
where appropriate.
[1]: in reality, we could also provide a udev rule that calls into a
small application which asks the library for a list of aliases for
$device, and create udev db files that way. I don't care, but that might
be stepping on Kay's toes a bit more than we'd prefer.
--
Peter
First things first -- but not necessarily in that order.
-- The Doctor
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
