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.