site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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? 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. 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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? 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. This email sent to site_archiver@lists.apple.com