itojun@iijlab.net writes:

> >>	it won't break any of existing communications.  we need to inform
> >>	inpcb to obtain fresh route so that they are happy across interface
> >>	removal.
> >>
> >>	inp_route caches the previously-used outgoing route for an inpcb.
> >>	if interface gets deleted, each of inpcb will need to refresh
> >>	cached route.  For example:
> >>	- you have two interfaces (ne0 and tlp0)
> >I think Bill is talking about the case where you have only one card,
> >and he wants _some_ kind of route to stay around, so apps don't get an
> >ENETUNREACH and give up. Say, switching a single-cardbus-slot laptop
> >(without builtin ethernet) from PCMCIA Ethernet to PCMCIA wireless, or
> >vice-versa. Apps that retransmit while there's no interface are in
> >trouble.  (Bill--is that right?)
> 
> 	I'm a bit confused.  When I emailed about bsdi-wildboar/freebsd-PAO/
> 	netbsd pcmcia models, someone told me that "interface and routes goes
> 	away, daemons and programs should live with it" is the right thing
> 	to do.  "Retainning routes even if interface is not there" is not
> 	consistent with it...

To do this correctly requires reworking of the abstractions inside the
kernel.  No one, I think, is currently considering doing this :)

Basically to do this correctly you have to debind the interface logical
state from the physical device.

Once this is done you can e.g., have daemons or whatever that will
either delete or retain the logical state.  If the logical state is
retained it could then be reattached to a newly inserted device.  

Having this type of abstraction would enable us to do other cools things 
too.  The problem is we need to think about this if we do it and do it
well.  With the right abstractions it would be easy to imagine binding
some logical interface to another logical interface e.g.,
ppp0 <-> ether0 <-> ep0.

Chris.