From owner-freebsd-questions  Tue Apr 30 13:34:30 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id NAA04762
          for questions-outgoing; Tue, 30 Apr 1996 13:34:30 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA04736
          Tue, 30 Apr 1996 13:34:21 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA07719; Tue, 30 Apr 1996 13:27:35 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199604302027.NAA07719@phaeton.artisoft.com>
Subject: Re: Fix for missing _iso_ntoa?
To: wollman@lcs.mit.edu (Garrett Wollman)
Date: Tue, 30 Apr 1996 13:27:35 -0700 (MST)
Cc: ilko@oclc.org, freebsd-questions@FreeBSD.org, current@FreeBSD.org
In-Reply-To: <9604301824.AA22862@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Apr 30, 96 02:24:50 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-questions@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> > I checked the archive and found out that _iso_ntoa no longer
> > exists in stable but was unable to find out how to
> > fix this problem.
> 
> Ummm, it no longer exists in -current.  It is supposed to exist in
> -stable.  Perhaps you have spammed your -stable C library with a
> -current one.

Garrett: what would it take to unify the address manipulation model
to a set of common routines?

INET has:

     int
     inet_aton(char *cp, struct in_addr *pin)

     unsigned long
     inet_addr(char *cp)

     unsigned long
     inet_network(char *cp)

     char *
     inet_ntoa(struct in_addr in)

     struct in_addr
     inet_makeaddr(int net, int lna)

     unsigned long
     inet_lnaof(struct in_addr in)

     unsigned long
     inet_netof(struct in_addr in)

and ISO has

     struct iso_addr *
     iso_addr(const char *addr)

     char *
     iso_ntoa(struct iso_addr *isoa)

And XNS has

     struct ns_addr
     ns_addr(const char *name)

     char *
     ns_ntoa(struct ns_addr addr)

And IPX has

     ...

Any chance of evovling a common API model that takes an AF_XXX
argument and wrappers the rest of it?

I'd be happy to work on the libc dlopen() routines, but you're
the networkign guru.

Backward compatability could be handled by:

static inline
char *
inet_ntoa( struct in_addr in)
{
	return( xxx_ntoa( AF_INET, (caddr_t)in));
}

...etc. in the header files for the protocol family.

Internally, there would be a family cache, which would reflect
the contents of a file (in /var/config/networks?) of a format
like:

	#
	# address handling objects to be mapped by libc
	#
	# AF_XXX	value		resolver object

	AF_INET		2		/usr/lib/af_inet.so
	AF_NS		6		/usr/lib/af_ns.so
	AF_ISO		7		/usr/lib/af_iso.so
	AF_IPX		23		/usr/lib/af_ipx.so

Which would allow (almost) drop-in support of new address families.

Maybe /usr/lib/af/* instead, with:
	2.inet.so
	6.ns.so
	7.iso.so
	23.ipx.so

To make it truly drop-in-able?


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.