[...]

>Given what i'm proposing, plus appropriate support for userland events
>on card insertion/ejection and carrier detect and carrier loss, I
>think you can implement just about any policy you want in userland.

I'm talking about what happens when  there's tsill no userland
event support.


>Is there really a meaningful difference between
>
>	ep0 with parameter set A at home
>	ep0 with parameter set B at work.
>
>and 
>
>	ep0 with parameter set A at home
>	ep1 with parameter set B at work.
>
>if at most one card is ever inserted at any given instant?


Yes, there is.  If interface state is sticky *and* sticks to MAC
address, I do the static configuration `right', and I have ep0 and
ep1, ep0 gets the IP address, netmask, arp state for home, and ep1
gets the IP address, netmask, arp state &c for work.

Your way, I only ever have ep0. I can only identify one parameter set
with that interface. So *every* time I move (home to work, or work to
home), I *have* to change the `parameter set'. Every time. In which
case, what's the point keeping any state with the interface struct?

Which leads right back to doing the config dynamically: if you only
have one card and roam around with it, you pretty much *have* to do
that. Again, there's no point keeping interface state around if
you just have to change it on attachment.  

BTW, I agree that what constitutes ``attachment'' need not be the same
as popping a card in and out. But card-popping is what the Mosquitonet
design used, and it works damn well.  I can think of one case, even
for wireless, where card-popping is a better signal than media sense:
when you roam with wavelan from one campus to another, and the two
wireless domains use different 16-bit magic cookies.
Provided you can throw two wireless cards at the problem :-).


(BTW, the mosquitonet people really do end up with multiple instances
attached.)