¿Por qué * BSD usa nombres específicos del controlador para las interfaces de red? ¿Implica limitaciones?

12

Noto que dependiendo de la marca de la tarjeta de red, los nombres de las interfaces difieren (supongo que depende del controlador).

¿Por qué * BSD usa nombres específicos del controlador para las interfaces de red?
¿Significa que no hay una capa de abstracción que describa "una interfaz de red genérica" en el núcleo, por lo que cada controlador se abordaría internamente a través de su propia API?
(¿cómo) afecta a los subsistemas como la agregación de enlaces, la conformación del tráfico, QoS ( ALTQ ), el filtrado y otros?

Precisamente, parece que bajo pfSense, no puedo usar ALTQ con una interfaz virtual de agregación de enlaces (LAG).

¿Es esta una limitación interna de BSD debido a la falta de una capa de abstracción adecuada?

— Totor
fuente

7

¿Por qué * BSD usa nombres específicos del controlador para las interfaces de red?

Es solo una elección histórica. Las letras en el nombre provienen del controlador que habla con la tarjeta, por lo que serán las mismas para dos interfaces separadas si utilizan el mismo controlador.

Tiene un beneficio práctico: en BSD, los controladores de red tienen sus propias páginas de manual en la sección 4. Entonces, dc(4)le informa sobre el controlador DEC 21143, que controlaría el dc0adaptador de red.

También puede ver esto en otras partes de BSD Unix, como los discos duros.

¿Es esta una limitación interna de BSD debido a la falta de una capa de abstracción adecuada?

No.

Por lo que vale, Linux se dirige por un camino similar . Los días de reglas de nomenclatura simples para los adaptadores Ethernet están desapareciendo, a medida que las redes se vuelven más complicadas.

— Warren Young
fuente

Gracias. ¿Sabes por qué no puedo usar ALTQ con una agregación de enlaces entonces?

— Totor

Una pregunta por pregunta, por favor. Vamos a centrarnos en la denominación de dispositivos BSD.

— Warren Young

No llamaría al nuevo dispositivo de red udev nombrando una ruta similar a BSD. Hasta donde sé, la forma predeterminada es usar algún tipo de ruta de bus para identificar los dispositivos, no el nombre del controlador con un esquema de numeración aleatoria.

— Pavel Šimerda

@ PavelŠimerda: Sólo quería decir que los sistemas Linux que utilizan este esquema de utilización ya no eth0a través ethINFINITY. Ya no podrá escribir ifconfig eth0y esperar que verá la primera interfaz Ethernet, lo que hace que dichos sistemas Linux sean funcionalmente similares desde el punto de vista de la interfaz de usuario a FreeBSD, donde necesita un conocimiento a priori de los nombres de interfaces en el sistema, o ifconfigprimero necesita obtener una lista con un comando no calificado . Los mecanismos subyacentes del núcleo son, por supuesto, completamente diferentes.

— Warren Young

5

La elección de usar nombres genéricos o específicos del controlador no tiene nada que ver con ninguna limitación del controlador.

Es sobre todo una elección cosmética. El uso de nombres genéricos tiene la ventaja de ocultar información que casi siempre es irrelevante: una interfaz de red es una interfaz de red, sin importar quién la haya creado. Las capacidades de un dispositivo dependen del modelo exacto y de su configuración, no de qué controlador está en uso. La ventaja de los nombres específicos es para el administrador: si un mensaje de error menciona eth0(ok, cuál es 0 y cuál es 1), es menos informativo que si menciona wlan0(ah, esa es la interfaz wifi) o bcm0(ah, eso es la interfaz Broadcom).

En FreeBSD, las operaciones de configuración de red funcionan llamando ioctla un socket Unix. Este ioctl es procesado por el código de red genérico y se filtra al controlador correspondiente si el ioctl lo requiere.

No sé cómo ALTQ interactúa con la agregación de enlaces. Asegúrese de usar una versión reciente de FreeBSD, ya que esto no funcionaba, pero ahora sí .

— Gilles 'SO- deja de ser malvado'
fuente

3

Hace que sea más fácil saber con qué tarjeta de red está hablando.

Si tiene un Intel (igb0) y un Realtek (rl0) nic, ahora puede distinguirlos de inmediato.

Además, los diferentes controladores admiten diferentes características. Algunos controladores son compatibles pollingy otros no. Algo de apoyo LRO, TSOy RSSetc. Es más fácil realizar un seguimiento de los que el apoyo que, cuando no todos son simplemente nombrados eth.

eth podría tener sentido si tuviera muchos otros tipos de interfaces de red, pero rara vez lo hace.

— Allan Jude
fuente

+1, porque sé quién eres. :) Gracias por el podcast !

— Warren Young

1

¿Por qué * BSD usa nombres específicos del controlador para las interfaces de red?

Para simplificar las cosas. Si busca una interfaz llamada bge0y echa un vistazo a los manuales o utiliza su sistema de enlace mnemónico , recordará rápidamente que este controlador es un Broadcom Gigabit Etherhet . Este documento también es útil.

¿Significa que no hay una capa de abstracción que describa "una interfaz de red genérica" en el núcleo, por lo que cada controlador se abordaría internamente a través de su propia API?

La regla aquí es:

Use el nombre del conductor para crear un nombre de dispositivo;
Use la identificación PCI más baja para crear el número justo después del nombre del dispositivo;

No se necesita capa de abstracción. Así de simple

(¿cómo) afecta a los subsistemas como la agregación de enlaces, la conformación del tráfico, QoS (ALTQ), el filtrado y otros?

Los nombres de interfaz no deben interferir en la configuración del tráfico.

Precisamente, parece que bajo pfSense, no puedo usar ALTQ con una interfaz virtual de agregación de enlaces (LAG).

Hoy debería funcionar:

¿Es esta una limitación interna de BSD debido a la falta de una capa de abstracción adecuada?

No es que no haya una capa adecuada para manejar esto. Se debe a que podría usar otros recursos para manejar esos nombres, como crear nombres de interfaz ( /etc/rc.conf) o cambiar su ID de pci en la configuración de la placa base. Y como han dicho otros sobre esta pregunta, incluso Linux va a tomar este camino biosdevname.