Implementing new protocols (was Re: Question on KPI / NKE : sys/select.h : struct selinfo ?)
Implementing new protocols (was Re: Question on KPI / NKE : sys/select.h : struct selinfo ?)
- Subject: Implementing new protocols (was Re: Question on KPI / NKE : sys/select.h : struct selinfo ?)
- From: Pekka Nikander <email@hidden>
- Date: Mon, 9 May 2005 16:10:31 +0300
There are no plans at this time for net_add_domain and net_add_proto.
We are interested in hearing about what you might need such
functionality for.
lets say that i needed to provide a new protocol family for something
like ATM?
We are aware that the socket layer provides a nice framework for
interaction between a protocol implemented in the kernel and an
application in user space. .... We did look at the problem a number of
times and ran in to some fundamental issues with third parties
extending the stack to support additional protocols.
There are a number of problems with extending the stack to support a
new protocol family. One problem is that there are only 255 possible
address families in a sockaddr. These leaves us with 255 possible
protocol families that have a corresponding address family. If you
pick one of the approximately 220 unused protocol families, there is
no guarantee that it won't be used by someone else.
One possibility would be to assign the PF/AF number dynamically via an
API.
Maybe there could be a KPI similar to net_add_domain but that would
dynamically
allocate the AF_ number? The kext could then communicate this to a
library
that could then use it internally? The apps would use the library and
not
be exposed to the fact that the AF_ number might be different?
Besides, what if you don't want to create a new domain but, e.g., just a
new version of an existing protocol? For example, I've been trying to
extend PF_KEY to support BEET (draft-nikander-esp-beet-mode-01.txt).
Then you are likely to just use the same protocol etc. numbers.
In addition to the limited number of useful protocol families, there's
an issue of definitions for the various socket options, address
structure, and protocols. If two third parties attempt to implement
the same protocol, they may actually layout their data structures
differently. This means that a developer attempting to use a third
party protocol will have to compile their code for a specific
implementation of another third party's protocol (such as ATM).
If the two independent implementations are assigned different AF_
numbers,
that should not really be a problem.
There is also the issue of third party drivers and third party
protocol families.
There are new protocols above IP. SCTP was already mentioned.
HIP (Host Identity Protocol) is another example. Integrating
protocols such as those into the current kernel (as kexts) is
quite painful. If you are interested in hearing about the
exact issues, I'd be more than happy to help.
--Pekka Nikander
_______________________________________________
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