Subject: Re: SIOCSIFADDR & co (whoops)
To: None <>
From: None <>
List: tech-kern
Date: 02/01/2000 16:24:24
['D' is next to 'S' on the keyboard. Ctrl-D deletes a character. Ctr-S
On 26 Jan, Bill Studenmund wrote:
> One reason to not do it higher up is: SIOCSIFADDR. :-)

Actually this is the one I was thinking of when I thought the idea up.

> Guess what happens when it tries to add an atalk address on the eon
> interface, which is an ISO-over-IP tunnel. :-)

I knew that I hadn't thought enough when I thought, if you know what I

This does raise something else that I had noticed at the same time, but
I will start by explaining why I still think my idea is better (IMHO ;-)

The problem with using a subroutine is that it merely saves the
programmer from having to cut and paste. The device drivers do not get a
higher level of service from the rest of the kernel, when it seems that
this ought to be possible. I cannot think of one good reason why an
ethernet driver should care about IP. 

There is no reason why the support offered by the kernel to network
device drivers needs to be based on BFI. The kernel should already know
which devices are ethernets, and there is no reason why this sort of
knowledge can be made more general. 

One possibilty is that SIOCSIFADDR is only passed on to network drivers
that aren't ethernets. Another option is that all network device drivers
have a category that governs which sort of protocols can be used. Such
categories as ether and atm already exist. A category of say
'netspecific' could be used for devices that can explictly list the
protocols that the device supports.

Thinking on the fly here, what about something like

	if_allow_protocol (ifp, AF_INET)

and then ether_ifattach() can call as many of these as required.

I am quite aware that I know very little about NetBSD networking
internals. I hope you are too.

Lloyd Parkes, Network Manager, School of Earth Sciences
Victoria University of Wellington