1 2 next »

1. Consistent network interface names
2. Longterm kernels

Kernel Log: Consistent names for network interfaces

by Thorsten Leemhuis

Future distributions will use a consistent, predictable scheme to name network interfaces, using names such as "em1" and "pci2#1" instead of "eth0" and "eth1" to provide more transparency for server administrators. As various new kernels have recently been introduced, the Kernel Log will provide an overview of the most important Stable and Longterm kernel series.

For years, Matt Domsch has advocated solutions which provide reliable and predictable network port names – in systems with multiple network sockets, the driver loading sequence and hardware response times influence whether a certain port will be called eth0 or eth1. Now, the Dell technology strategist and DKMS contributor seems to have taken a big step towards his goal. On his blog, Domsch, who also contributes to the Fedora project, explains that Fedora 15 – expected in May – will use a device naming scheme that he helped develop, in which udev accesses "biosdevname", a program mainly developed by Dell employees, to allocate network device names. The developer says that other distributions are also likely to adopt this solution.

This naming scheme will make udev allocate the device name "em1" to the motherboard's first network port, "em" being short for "embedded"; network cards will be named according to the pattern "pci<slot>#<port>" (such as pci2#1), which should always make the ports on a network card accessible under the same name as long as the card, or a substitute, is inserted in the same slot. The sub-functions of network cards that can be partitioned (NPAR) and the sub-functions of cards with SR-IOV virtualisation support are given an added underscore and a number. As before, vlan functions are separated by a dot, and aliases by a colon.

When allocating names, biosdevname accesses the information available in PCI firmware specification 3.1; if this information is unavailable, it will try to retrieve values using smbios. This is designed to match the numbers behind the "em" with those printed on the housing or board – and considerably help network admins with their cabling, especially on servers with a large number of network sockets. If biosdevname can't retrieve any information this way, the program uses the PCI IRQ routing table and will allocate the numbers according to the card's position in the device hierarchy. Biosdevname doesn't handle USB network interfaces, which will continue to be given such names as "eth0".

Kernel version status

As expected, the developers have only made minor and relatively few changes to the Linux main development branch since the second release candidate of 2.6.38 became available last week – 2.6.38-rc3 is expected to arrive any day now. As previously mentioned in the latest regular Kernel Log, the developers made available kernel versions 2.6.32.28 and 2.6.36.3. These are versions from two of the six currently actively maintained kernel series which offer end-user kernels that are based on versions from the main development branch maintained by Linus Torvalds. Among these is the Stable kernel maintained by Greg Kroah-Hartman. The maintainer has recently said that he now intends to focus predominantly on the most recent mainline version – this would currently be kernel version 2.6.37, released at the beginning of the year; a kernel version 2.6.37.1 is, therefore, likely to become available in the coming days or weeks. The developer plans to discontinue the maintenance of the previous version after a short transition period; Stable kernel 2.6.36.3 is, therefore, likely to be one of the last kernel version in Stable series 36.

Next: Longterm kernels

1 2 next »