Connecting to the Kernel
We’ll start looking at the structure of network drivers by dissecting
the snull source. Keeping the source code for several drivers
handy might help you follow the discussion. Personally, I suggest
loopback.c
, plip.c
, and 3c509.c
, in order of
increasing complexity. Keeping skeleton.c
handy
might help as well, although this sample driver doesn’t actually run.
All these files live in drivers/net
, within the
kernel source tree.
Module Loading
When a driver module is loaded into a running kernel, it requests resources and offers facilities; there’s nothing new in that. And there’s also nothing new in the way resources are requested. The driver should probe for its device and its hardware location (I/O ports and IRQ line)--but without registering them--as described in Section 9.2 in Chapter 9. The way a network driver is registered by its init_module function is different from char and block drivers. Instead of asking for a major number, the driver inserts a data structure for each newly detected interface into a global list of network devices.
Each interface is described by a struct device
item. The
structures for sn0
and sn1
, the two snull interfaces,
are declared like this:
char snull_names[16]; /* two eight-byte buffers */ struct device snull_devs[2] = { { snull_names, /* name--set at load time */ 0, 0, 0, 0, /* shmem addresses */ 0x000, /* ioport */ 0, /* irq line */ 0, 0, 0, /* various flags: init to 0 */ NULL, /* next ptr */ snull_init, /* init ...
Get Linux Device Drivers now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.