Date: Sat, 23 Aug 1997 17:40:43 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: julian@whistle.com (Julian Elischer) Cc: wollman@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: promblems with non IP protocols Message-ID: <199708240040.RAA05148@phaeton.artisoft.com> In-Reply-To: <33FE24CA.52BFA1D7@whistle.com> from "Julian Elischer" at Aug 22, 97 04:46:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 1/ I prefer if it is a dynamic thing and
> not dependent on a "#ifdef NETATALK" in the kernel.
> Is this reasonable?
> (I'd like to work towards loadable protocols)
I was looking at this as well, recently, mostly because of the
ISO stuff going away.
I think there are several problems which need to be solved in
this area; changing over to a registration mechanism for address
families (in the kernel) is only part of it.
There also needs to be a set of interfaces for glueing address
family manipulation functions into libc, as well.
My personal preference would be to provide an interface for
listing the available address families that are currently
registered at any one time.
Then libc would use this to load things like "/usr/lib/af_inet.so";
only it would be "sprintf(loadname,"/usr/lib/af_%s.so", itername);"
to build it from an iterated name. Or Strcat or pointer-add it.
Whatever.
The general address manipulation functions would then change to
take a family parameter:
net_aton, net_addr, net_network, net_ntoa, net_makeaddr, net_lnaof,
net_netof, etc.
Backward compatability would be provided via #defines:
#define inet_ntoa(in) net_ntoa("inet",in)
...
Maybe using inline functions so the compiler can still be anal
for those people with compiler fixations:
static __inline char *inet_ntoa( struct in_addr in) {
return( net_ntoa( "inet", (void *)&in);
}
> 2/ If it's loadable, and a pointer to a method, then WHERE is the
> method stored, so that it can be found? there are several options.
[ ... ]
> ii) add and entry to the ifaddr struct.
> there is already the protocol dependent rtrequest.
> adding a protocol dependent address handler
> (can do compares, and other operations, given the
> appropriate args) doesn't seem like too much of a leap.
I vote for this one. The reason I vote for this one instead of
a hybrid or an AF_XXX index is that:
1) With dynamic loading of AF_XXX, an array index is out,
unless the array is constantly being realloc'ed (ugh..
in the kernel?).
2) It allows you to have a single address family that can
inherit multiple policies by having multiple reference
structures, and little else in the way of changes. So
you could have an "AF_INET" with the default policy and
an "AF_INETA" with a modified policy to support classes
of service.
3) I think it's cleaner. Yeah, that's an esthetic issue. 8-).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708240040.RAA05148>