In a nutshell, I have a C++ class whose instances each encapsulate a
network interface of interest. Each has a member that holds its
associated ifnet*. My plan is to put the dlil_attach_interface_filter()
and dlil_detach_filter() calls in the constructor and destructor of
these interface objects.
In looking at the code in xnu it seems that there is a refcount that
will prevent the system from freeing an interface with such an attached
filter. And my hope it that this will make it OK for me to hold onto
the ifnet* for as long as that filter is in place. Can anyone confirm
this?
No. The refcount doesn't count the filters, but count the protocols. If an interface is detached, the detach function of your filter is called, and then interface detachment continues. You have no way to prevent that from a filter.
My second question is how to create these objects safely in the first
place. Again, cribbing from xnu I've come up with a loop like this:
struct ifnet *ifp;
// read through list of devices and build a list of adapters that
we care about
for (ifp = ifnet.tqh_first; ifp; ifp = ifp->if_link.tqe_next) {
... new InterfaceObject( ... ifp ...);
}
During this section of code I have the network funnel. If I understand
correctly, that protects me from any other running thread (even on MP
systems). Again, can someone confirm?
I think walking the list of ifnet is unfortunately the only way to discover the all ifnet. However, if you do an allocation like new InterfaceObject, you can loose the funnel, and potentially the list can be updated by an other code.
My real worry is about my own thread's behavior. I understand that
kernel threads can block and if they do then I loose and regain the
funnel. But since I can avoid making calls that block I can handle
that. But what about preemption? If my thread runs out of its time
quantum might it get preempted (and again loose and regain the funnel)?
And if that happens, couldn't the interface list change while I'm
iterating over it?
That's possible.
And lastly, whatever the solution to that is ("kernel threads can't be
preempted" or "use splnet() / splx()", or something else), what about
paths into my NKE that are really user threads that have called into
the kernel (through the network stack)? (Can that happen or is
everything in the kernel run on a kernel thread with the "call" handled
via a kernel thread blocking on a queue?) If it can happen, do I need
to consider such threads as different from native kernel threads as far
as preemption in my NKE goes?
I hate to ask so many questions but I do want to get this right. Any
hints would be appreciated.
Thanks,
Mike
_______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.