13

I notice that depending on the brand of the network card, interface names differ (driver dependent I suppose).

  • Why does *BSD uses driver specific names for network interfaces?
  • Does it mean there is no abstraction layer describing "a generic network interface" in the kernel, so each driver would be internally addressed via its own API?
  • (how) does it affect subsystems like link aggregation, traffic shaping, QoS (ALTQ), filtering and others?

Precisely, it looks like under pfSense, I cannot use ALTQ with a link aggregation (LAG) virtual interface.

Is this a BSD internal limitation due to the lack of an appropriate abstraction layer?

Improve this question

4 Answers 4

Reset to default
7

Why does *BSD uses driver specific names for network interfaces?

It's just a historical choice. The letters in the name come from the driver that talks to the card, so they will be the same for two separate interfaces if they happen to use the same driver.

It does have one practical benefit: on BSD, the network drivers have their own manual pages in section 4. So, dc(4) tells you about the DEC 21143 driver, which would control the dc0 network adapter.

You see this in other parts of BSD Unix as well, such as hard disks.

Is this a BSD internal limitation due to the lack of an appropriate abstraction layer?

No.

For what it's worth, Linux is heading down a similar path. The days of simple naming rules for Ethernet adapters are disappearing, as networking gets more complicated.

Improve this answer
4
  • Thank you. Do you know why I cannot use ALTQ with a link aggregation then?
    – Totor
    Commented May 7, 2014 at 12:53
  • One question per question, please. Let's focus this one on BSD device naming.
    – Warren Young
    Commented May 7, 2014 at 16:19
  • I wouldn't call the new udev network device naming a similar path to BSD. As far as I know the default way is to use some sort of bus path to identify the devices, not the driver name with a random numbering scheme.
    – Pavel Šimerda
    Commented May 8, 2014 at 13:25
  • @PavelŠimerda: I just meant that Linux systems that use this scheme no longer use eth0 thru ethINFINITY. You will no longer be able to just type ifconfig eth0 and expect that you'll be looking at the first Ethernet interface, which makes such Linux systems functionally similar from a user interface standpoint to FreeBSD, where you need either a priori knowledge of the names of the interfaces on the system, or you need to get a list with an unqualified ifconfig command first. The underlying kernel mechanisms are of course completely different.
    – Warren Young
    Commented May 8, 2014 at 23:07
5

The choice of using generic or driver-specific names has nothing to do with any driver limitation.

It's mostly a cosmetic choice. Using generic names has the advantage of hiding information that is almost always irrelevant — a network interface is a network interface, no matter who made it. The capabilities of a device depend on the exact model and on its configuration, not on which driver is in use. The advantage of specific names is for the administrator: if an error message mentions eth0 (ok, so which one is 0 and which one is 1), it's less informative than if it mentions wlan0 (ah, that's the wifi interface) or bcm0 (ah, that's the Broadcom interface).

On FreeBSD, network setup operations work by calling ioctl on a Unix socket. This ioctl is processed by the generic networking code and trickles down to the relevant driver if the ioctl calls for this.

I don't know how ALTQ interacts with link aggregation. Make sure to use a recent version of FreeBSD, as this used to not work but now does.

Improve this answer
3

It makes it easier to tell which network card you are talking to.

If you have an Intel (igb0) and an Realtek (rl0) nic, you can now tell them apart immediately.

Also, different drivers support different features. Some drivers support polling and some do not. Some support LRO, TSO and RSS etc. It is easier to track which support which when they are not all just named eth.

eth might make sense if you had a lot of other types of networking interfaces, but you rarely do.

Improve this answer
1
1

Why does *BSD uses driver specific names for network interfaces?

To make things simple. If you look to an interface named bge0 and take a look at the manuals or use your mnemonic link system you will quickly remember that this driver is a Broadcom Gigabit Etherhet. This document is also usefull.

Does it mean there is no abstraction layer describing "a generic network interface" in the kernel, so each driver would be internally addressed via its own API?

The rule here is:

  • Use the driver´s name to create a device name;
  • Use the lowest PCI id to create the number right after the device name;

No abstraction layer needed. That simple.

(how) does it affect subsystems like link aggregation, traffic shaping, QoS (ALTQ), filtering and others?

Interface names should not interfere on traffic shapping.

Precisely, it looks like under pfSense, I cannot use ALTQ with a link aggregation (LAG) virtual interface.

Today it should work:

Is this a BSD internal limitation due to the lack of an appropriate abstraction layer?

It´s not that there isn´t an appropriate layer to handle this. It´s because you could use other resources to handle those names like creating interface names(/etc/rc.conf), or changing it´s pci id on the motherboard setup. And as said by others on this question, even Linux is going to this path with biosdevname.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .