Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> writes:
> Comments and constructive feedback will be appreciated..

This isn't really constructive criticism, but I still think it's true:

What you've proposed doing here is "weird" and broken.

I said weird, because the whole notion of "remove a device, but have
the kernel pretend some aspects of the device are still there," is
just plain weird.  If a device is gone, it should be gone completely
from the kernel.  Further, i'd say that you really do want to
propagate all of the results that follow from that out to user-land.
For instance, when a device goes away, you really do need to delete
routes that go through it, for (what I think are 8-) a couple of
reasons: (1) so applications don't end up waiting a long time trying
to talk through an interface that doesn't exist, and (2) so that other
applications can do the right thing with, e.g. potentially finding
another default route, if you just yanked the default route.  There's
also the issue that you shouldn't be wasting any memory or other
resources on a device that's not there.

I said broken because, basically, you're faced with two choices:

* do a lot of work which causes interface detachment to work in the
way that's best described as "right."

* do a bunch of work (though less) which adds a bunch of code and
interfaces, which aren't really related to doing the job right but
which allow you to avoid the harder work of doing it right.

You may get something that's working, for some value of working, but
it's still fundamentally broken.


I recognize that it may be a bunch more work to do it right.  I
thought that much work had already been done towards that goal.  It
seems wasteful and ... less than optimal to throw that away and move
forward on a plan that seems, at least to me, to provide fundamentally
incorrect operation.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.