lkml.org 
[lkml]   [2009]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Network Device Naming mechanism and policy
    From
    From: Matt Domsch <Matt_Domsch@dell.com>
    Date: Tue, 24 Mar 2009 10:46:17 -0500

    > Problem: Users expect on-motherboard NICs to be named eth0..ethN.
    > This can be difficult to achieve.

    I learned a long time ago that eth0 et al. have zero meaning.

    If the system firmware folks gave us topology information with respect
    to these things, we could export something that tools such as
    NetworkManager, iproute2, etc. could use.

    For example, if we were told that PCI device "domain:bus:dev:fn" has
    string label "Onboard Ethernet 0" then we could present that to the
    user.

    Changing how the actual network device name is determined is going to
    have zero traction.

    So, please, put mapping tables into the ACPI or similar and then
    programs can go:

    for_each_network_device(name) {
    fd = open(name);
    label = get_system_label(fd, name);
    present_to_user(label, name);
    }

    This "get_system_label()" thing can be an ethtool ioctl, some
    rtnetlink call, or similar. In the kernel, a generic routine would
    exist for major bus types to make the mapping translation, and drivers
    would call these.

    For PCI it might take the PCI device pointer and try to fish
    out a string from the ACPI layer.

    For OpenFirmware we might just simply give the full device path,
    or a matching device alias name.

    That's the only model which allows a smooth transition and
    no major infrastructure changes.

    I guess it's easier to spew about MAC addresses and other
    irrelevant topics than try to solve this problem properly. :-)


    \
     
     \ /
      Last update: 2009-03-25 00:01    [W:0.023 / U:0.336 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site