> 1. Let's say i want to implement a new network interface, say ng0.
>    The device is architecture independent, and should be usable no
>    matter what machine you have.  What do I need to add [...] to make
>    the kernel configure the device on boot?  [...pseudo-device, no
>    real hardware behind it...]

I added a pseudo-interface myself not so very long ago.

Near as I can figure, when you "defpseudo yourdevname" in the relevant
files file, config adds it to the pdevinit[] array in ioconf.c, which
causes your attach routine to get called at boot time.  It then has to
call if_attach() to make the interface "exist".

If you want I'll be glad to send you a copy of my pseudo-interface
driver.

> Also the device's network IP/network address will not be known until
> later in the session.

Nothing difficult about that; all network interfaces work that way,
unless they're used by the boot process (eg, network-remote root).

> 2. If an interface is configured an open/up after bootup, will
>    any/all protocol stacks automatically use it to send/receive data?

Whether a protocol stack is willing to send on an interface depends on
the stack.  Generally, if the interface has an address in the right
address family, the corresponding stack is willing to use it.

For receiving, your driver will have to recognize, somehow, that an
incoming packet should be handed to a particular stack somehow.  (For
Ethernet, for example, the drivers check the Ethernet type field.  The
code for this has been abstracted out into common routines, since there
are so many Ethernet drivers, but conceptually it's part of the driver,
since the means by which packets are recognized as belonging to IPv4,
or IPv6, or XNS, or what-have-you, is media-specific: Ethernet does it
one way, PPP another, token ring another, etc, etc.)

> What about address translation and routing - what kind of
> configuration is needed for these?

"It depends."  Some have no need for them.  SLIP, for example, has
neither: packets are sent to whoever's on the other end of the wire, if
anyone, and it's up to that host to deal with the packet.  Ethernet
uses ARP for IPv4, as another example; again, ARP is so common that
it's been abstracted out of the various drivers, but in a sense it
belongs there.

As for routing in the sense of "netstat -rn", that's up to the protocol
stacks to deal with.  The routing framework is fairly general, but the
network interface drivers generally don't have occasion to care about
it; their work is lower-level than that.  Of course, if you're dealing
with something like ATM or a complicated multiple-ring token-ring mess,
the driver may have some routing-type work to do....

> 3. This one is more about documentation than anything else: is there
>    a file or series of files that clearly and concisely explain
>    exactly what each source file in the distribution does?

As far as I know there is not.  You're right, it would be good to have.

I'll be happy to correspond further about this if you're interested.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B