In message <12794.1102399275@munnari.OZ.AU>,Robert Elz writes:
>    Date:        Mon, 06 Dec 2004 12:59:52 -0800
>    From:        Jonathan Stone <jonathan@dsg.stanford.edu>
>    Message-ID:  <E1CbPxY-0008BX-00@smeg.dsg.stanford.edu>
>
>  | I really don't see any compelling case to make if_strip clonable.  Or
>  | to have it in a GENERIC kernel anymore. Is anyone even _using_ strip
>  | with metricom radios?
>
>I'd have no objection to deleting it (at least from GENERIC, if not
>from NetBSD completely) - but if not deleted, then clonable is better
>than as it was - even if this one is one where no-one is ever
>realistically going to want more than one.   

strip(4) only works with older metricom radios with older firmware,
and to other radios running a strip(4) driver: which means NetBSD or
Linux 2.2. (Stuart Cheshire may have drivers for other OSes.)

The radios are sequenced direct-spectrum. The physics of radio Tx
versus Rx energy means you *really* don't want more than one of these
sequenced spread-spectrum radios per host.  I vaguely recall adding
support for two radios only to support an inactive standby; which was
solely as a workaround for firmware crashes that required a hard
powercycle to cure.


>The strip interface in
>generic kernels is the greatest obstruction to dhclient that exists,
>and dhclient is way more useful.   At least being clonable it shouldn't
>appear in the existing interface list until someone creates one, which
>is almost as good as not existing at all.

Really? I have no trouble at all with, but I fire up dhclient on a
specific, named interface.  But if strip(4) is a problem, I'd far
rather leave the working source as-is, until someone can test Peter's
proposed changes. Once cloning strip(4) works, I don't care either way.