(On raspberry pi zero w, kernel 4.14y) It seems the wireless adapter chip isn't a device in the /dev fs, but is the name of something that 'ifconfig' knows about. I understand that this is an artifact from Berkley Sockets.

It is hardware, I assume it must be mentioned in the device tree -- to cause some driver to be loaded, but it must not create an entry in /dev (devfs).

Where/how does Sockets find this device that is not a device?

  • Please unclose this question. As edited it is pretty clear – Ribo Dec 16 '18 at 20:49

In Linux, network interfaces don't have a device node in /dev at all.

If you need the list of usable network interfaces e.g. in a script, look into /sys/class/net/ directory; you'll see one symbolic link per interface. Each network interface that has a driver loaded will be listed.

Programmatically, you can use the if_nameindex() syscall: see this answer on Stack Overflow.

Also, note that /dev is the device filesystem.

The device-tree has a specific different meaning: it is a machine-readable description of a system's hardware composition. It is used on systems that don't have Plug-and-Play capable hardware buses, or otherwise have hardware that cannot be automatically discovered. As an example, Linux on ARM SoCs like Raspberry Pi uses a device tree.

The boot sequence of a RasPi is quite interesting: see this question on RasPi.SE.

In short, at boot time, under control of the /boot/start.elf file, the GPU loads the appropriate /boot/*.dtb and /boot/overlay/*.dtbo files before the main ARM CPU is started. The *.dtb file is the compiled device tree in binary format. It describes the hardware that can be found on each specific RasPi model, and is produced from a device tree source file (.dts`) which is just text, formatted in a specific way.

The kernel's live image of the device-tree can be seen in: /sys/firmware/devicetree/base Per Ciro Santilli, it can be displayed in .dts format by:

sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base

You can find the specification of the device tree file format here. The specification is intended to be OS-independent. You may also need the Device Tree Reference as clarification to some details.

So, the answer to your original question is like this:

  • the Berkeley Sockets API gets the network interface from the kernel
  • the kernel gets the essential hardware information from the device tree file
  • the device tree file is loaded by the GPU with /boot/start.elf according to configuration in /boot/config.txt
  • the device tree file was originally created according to the hardware specifications of each RasPi model and compiled to the appropriate binary format.

The device tree scanning code is mostly concerned about finding a valid driver for each piece of hardware. It won't much care about each device's purpose: that's the driver's job.

The driver uses the appropriate *_register_driver() kernel function to document its own existence, takes the appropriate part of the device tree information to find the actual hardware, and then uses other functions to register that hardware as being under its control. Once the driver has initialized the hardware, it uses the kernel's register_netdev() function to register itself as a new network interface, which, among other things, will make the Sockets API (which is just another interface of the kernel, not an independent entity as such) aware that the network interface exists.

The driver is likely to register itself for other things too: it will list a number of ethtool operations it supports for link status monitoring, traffic statistics and other low-level functions, and a driver for a wireless NIC will also use register_wiphy() to declare itself as a wireless network interface with specific Wi-Fi capabilities.

The Linux TCP/IP stack has many interfaces: the Berkeley Sockets API is the side of it that will be the most familiar to application programmers. The netdev API is essentially the other, driver-facing side of the same coin.

  • Ah good, 'ls -l /sys/class/net; (on a system with a working wlan0) shows the sym link: wlan0 -> ../../devices/platform/soc/20300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0 which tells me the device is connected through the SDIO (mmc) controller on the SOC. – Ribo Nov 25 '18 at 0:21
  • So how does Sockets find out about network interfaces from the kernel? Does something scan the device-tree for devices with some 'net' property or label? And I need to find out how start.elf selects the appropriate .dtb file from those on /boot – Ribo Nov 25 '18 at 15:01

wlan0 is an interface created by interfaces, in /etc/network/. The device itself is a contruct of the firmware that is loaded, for said interface. I say this because wlan0 is not the location of the actual hardware. It is a software constructed interface, to provide a way for the OS to talk to the hardware through the firmware definition of the actual device. Because you can change the firmware in order to modify the way the actual hardware behaves, add/remove functions change frequencies and such.

O and ifup and ifdown are basicly the on off switches HeHehe...

See: https://manpages.debian.org/stretch/ifupdown/interfaces.5.en.html

  • This sounds like a good lead. /etc/network/interfaces contains config files that I write to say how it should setup the devices, named eth0 or wlan0 or something. How does the system know that there is an eth0 and that there is not a wlan2? --- What code knows that there is a device out there to be wlan0? – Ribo Nov 25 '18 at 0:28
  • @Ribo The library of the controler where the device is attached, reports to the kernal that, hay a device with this id is presant. The kernal then looks for a firmware file that fits that device's description. Then the devices drivers are loaded. Then the device is brought up, and is seen as a interface. Say, wlan0 or whatever. – Michael Prokopec Nov 25 '18 at 0:38
  • In this case the wifi chip is connected by an SDIO interface -- meaning it is a device connected to an SDcard host (I didn't know before that SDcard hosts could connect to things other than SD memory cards, but they can.) So something must be going wrong there. – Ribo Nov 25 '18 at 1:31
  • 1
    What do you mean by a 'firmware file'? I think of firmware in the original sense of read-only memory with microcode. Do you mean the device table files? .dtb and overlay/.dtbo? – Ribo Nov 25 '18 at 1:34
  • I updated my answer to hopefully clarify this. – telcoM Nov 25 '18 at 11:20

-Yeah! is a device, the wireless card device, like the normal network device eth0, only this points / refers to the wireless device ...

  • I meant the question more precisely, is it a device in the sense of the /dev device tree. There is hardware, but Linux may not create a device structure for it. – Ribo Nov 24 '18 at 23:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.