Peter Memishian wrote:
> If we move the event to ipif_down_tail, for a network interface that has
> multiple logical interfaces instantiated then doing an unplumb will generate
> an NE_DOWN for each logical interface.
First, that's the behavior I'd expect. Second, that happens regardless of
whether the event is done in ipif_down() or ipif_down_tail(); they are
always called as a pair.
That isn't how we've defined the event NE_DOWN - it should only be
generated when there are no ipif's in the up state. Although, so long
as a "this ipif was done" state comes through to ipif_down_tail(),
ill_ipif_up_count should still only be 0 once if you unplumb an interface
with 2 or more logical interfaces that are up, right?
What about the case when ipif_down() returns EINPROGRESS?
What are the circumstances in which ipif_down_tail() then gets called?
The pair of events, NE_UP/NE_DOWN, are meant to be boundaries
for when you should see packet events associated with a network
interface. We haven't designed it such that NE_UP/NE_DOWN are
associated with logical interfaces.
> In addition, ipif_down_tail() has no knowledge about whether or not the
> interface was previously up and is now going down - that knowledge
> only exists in ipif_down().
That's a bug which I'm about to fix -- see 6452343.
In general, it seems odd to me to have the pfhook be in a different
location from the routing socket message for the same event.
There are many parts of our IP stack that can seem odd to
the casual observer :-)
But as I mentioned, the initial goal was to put the hooks near
changes to ill_ipif_up_count as it changing to 1 and 0 are of
what is interest to me.
Any chance of you posting a webrev (on grommit?) for this?
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
