a1ec763832
It should only be used by the calling function to create further nodes in the same function, and of course to save the MIB number, which is what is done now. Correct a stupid bug in the ethernet address parsing code. <ashamed face> |
||
---|---|---|
.. | ||
ethfoo | ||
setaddr | ||
Makefile | ||
README |
$NetBSD: README,v 1.1 2003/11/24 21:58:45 cube Exp $ ethfoo is meant to be an example of a few features of the NetBSD kernel. The module, once loaded, emulates one or several Ethernet devices, each one having its own Ethernet address. You can do most of what can be done with a real Ethernet device, but no packet can be received. On the network layer, ethfoo is a convenient skeleton for an Ethernet device driver, and demonstrates how an interface should be attached and manipulated inside the kernel. It also implements a cloning interface, making it possible for the administrator to create and destroy ethfoo interfaces at will, using the 'create' keyword of ifconfig: # ifconfig ethfoo15 create # ifconfig ethfoo15 inet 192.168.23.45 # ifconfig ethfoo15 destroy ethfoo is also a demonstration of what can be done with autoconf(9) from a Loadable Kernel Module. It uses Jason R. Thorpe's idea of adding a pseudo-device to the autoconf tables to avoid any attachment troubles, as seen in sys/dev/ata/ata_raid.c. A cfdriver structure and a cfdata structure are registered to the system at load time, making it possible to creates instances of the pseudo- device when the administrator uses the ifconfig create command. When a new ethfoo device is attached, the usual standard autoconf routines are called: match() and attach(). Since we registered the cf structures, we don't have to care about allocating structures such as the softc, it has already been done by the kernel. At that point it would even be possible to pass more parameters to the new device, using the custom argument through a ethfoo_attach_args structure. It could be useful to pass an Ethernet address, for example. ethfoo is not supposed to be anything more than an example of how to write a simple but complete LKM, though it can be good to have a fake Ethernet device when using software such as FlexLM. It would be a good idea to pull up parts of ethfoo into tun(4), to make it possible to read and write packets through a character device. It is also possible to extend ethfoo in that direction using MOD_DEV instead of MOD_MISC.