From owner-freebsd-hackers  Sat Aug 23 17:49:12 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA25085
          for hackers-outgoing; Sat, 23 Aug 1997 17:49:12 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA25075;
          Sat, 23 Aug 1997 17:49:09 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA05148; Sat, 23 Aug 1997 17:40:44 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199708240040.RAA05148@phaeton.artisoft.com>
Subject: Re: promblems with non IP protocols
To: julian@whistle.com (Julian Elischer)
Date: Sat, 23 Aug 1997 17:40:43 -0700 (MST)
Cc: wollman@FreeBSD.ORG, hackers@FreeBSD.ORG
In-Reply-To: <33FE24CA.52BFA1D7@whistle.com> from "Julian Elischer" at Aug 22, 97 04:46:18 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 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.