NetBSD/sys/lkm/net/ethfoo
cube a1ec763832 It's not safe to save the sysctlnode pointer returned by sysctl_createv.
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>
2004-05-13 07:20:47 +00:00
..
ethfoo It's not safe to save the sysctlnode pointer returned by sysctl_createv. 2004-05-13 07:20:47 +00:00
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.