Re: multiple plumbers for interface type
Re: multiple plumbers for interface type
- Subject: Re: multiple plumbers for interface type
- From: Josh Graessley <email@hidden>
- Date: Wed, 7 Feb 2007 11:53:56 -0800
At the bottom layer, lies the interface. In an ideal world, the
interface knows nothing about the higher level protocols (inet,
inet6, AppleTalk, NetBIOS, whatever).
In the middle, we have the plumbers. Plumbers don't do anything more
than handle packets for a specific protocol on a specific type of
interface. They have a plumb interface that is called when the
protocol wants to attach to the right interface. They set up
callbacks for handing packets and ioctls among other things. There is
an ethernet ip plumber. It handles ARP and it strips the ethernet
header off of the packet before injecting the IP packet in to the stack.
Traveling further up the stack, we have protocols like IP. When the
plumber has done all it needs to do with a packet, it calls a
protocol inject function. This passes the packet to IP. At this
point, IP doesn't have to care about the details of the interface the
IP packet came from.
If a INET_FAMILY_TUN plumber already exists and there is some sort of
standard that TUN interface plumbers have agreed upon, it should be
possible to implement your own TUN interface any interoperate with
the TUN plumber someone else wrote.
Another example would be ATM. The system does not ship with ATM
support. Someone could write ATM support when they create an ATM
driver. This driver would have to register a plumber. If two ATM
drivers from different vendors were installed, only one of them would
get to register the IP over ATM plumber. In theory, this could work
just fine. The plumber is responsible for attaching the protocol to
the interface and handling the packets. As long as both drivers
interpreted the attach protocol parameters the same and passed
packets in the same state to the plumber, it shouldn't matter which
plumber wins.
Reality is rarely so rosy. One workaround would be to use a different
interface family for your interface. That way, you can register a
plumber and not be as worried about conflicts. Unfortunately, there
is no way to guarantee you are getting a unique interface family value.
-josh
On Feb 7, 2007, at 10:12 AM, Brian Wotring wrote:
The NKE docs, in the section "Network Interfaces and Protocol
Plumbers" states the following note:
"Since more than one developer might attempt to register plumbers for
a given interface type, your KEXT should be prepared to handle such a
situation. If the demux descriptors are standard, it should be
possible for your KEXT to work with a third-party plumber."
Can someone expand on this for me to shed light on what "working" with
third party plumbers actually means? Specifically, is it possible to
have multiple plumbers for a specific interface type and if so, how is
this supposed to work?
I have run into a problem with calling proto_plumb_handler() for
IFNET_FAMILY_TUN, when an existing TUN NKE already exists.
-brian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden