On Friday 2009-12-18 14:19, Narendra_K@xxxxxxxx wrote:
>>
>> Anyway: I think it is good to give interfaces a stable name by the
>> installer of the distribution. Isnt that what ifrename is used
>> for?
>>
>> I am not sure what the patch is supposed to do?
>
>The installer solution involved renaming the network interface names
>from ethN to something else based on the naming convention that the user
>specified. For example, if the user chose "smbios names" as the the
>naming convention then all ethN would be renamed to Embedded_NIC_N.
>ifconfig would show Embedded_NIC_N instead of ethN.
>
>I suppose the ifrename would rename network interfaces from ethN to ethN
>and that would cause issues.
What issues?
>The current proposal aims at providing non
>ethN aliases like Embedded_NIC_N which would be mapped to an ethN name
>by the proposed library (such as libnetdevname) which can then be used
>for further operations.
What is wrong with just renaming the actual interface? In fact you
could use udev itself for just that. /lib/udev/write_net_rules,
and instead of continuing to use the name the kernel set aside,
let it call out to smbios and voilà, your
/etc/udev/rules.d/70-persistent-net.rules would then show something
like:
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:20:18:8c:ce:70",
NAME="PCI_NIC_0"
That is not hard, and has the nice side effect of propagating through
all possible programs, because it is the actual interface name rather
than some alias for which you would need a library first.
In short, I would see PCI_NIC_0 in iptraf. Today.
>The SMBIOS tables provide these names and as the
>BIOS would name the integrated port 1 of the system Embedded_NIC_1
>always, irrespective of how the OS names it (i.e eth0 or eth1). This
>brings in determinism into the way interfaces are referred to.
>Current installer implementations do provide a way for persistency by
>associating MAC addressees, but they do not have a way to assure
>expected naming.
Mapping MACs to interface names is a sort of determinism -- it
remains the same over time.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
