X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C7195E.D51272EC@onstor-exch02.onstor.net>; Wed, 6 Dec 2006 09:49:09 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: A summary of my previous work porting our SSC applications to NETBSD
Date: Wed, 6 Dec 2006 09:49:08 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E019F55B2@onstor-exch02.onstor.net>
In-Reply-To: <20061205184149.79b1c90f@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: A summary of my previous work porting our SSC applications to NETBSD
thread-index: AccY4BRkdqNrSuJBTc61wKkjmdTT1QAfWsaA
From: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>,
	"Larry Scheer" <larry.scheer@onstor.com>
Cc: "Tim Gardner" <tim.gardner@onstor.com>,
	"Jay Michlin" <jay.michlin@onstor.com>,
	"Jonathan Goldick" <jonathan.goldick@onstor.com>,
	"Brian DeForest" <brian.deforest@onstor.com>

The code which calls this function messes with the internals of the
library so it needs direct access to the library mutex for the
protection. As far as I can tell, the code implemented some extension to
the library, which required access to the library internals, which may
or may not be available in netbsd and/or linux. It is not trying to fix
the reentrancy problems. This is one of the places that needs to be
revisited when upgrading the OS.=20

> -----Original Message-----
> From: Andrew Sharp [mailto:andy.sharp@onstor.com]=20
> Sent: Tuesday, December 05, 2006 6:42 PM
> To: Larry Scheer
> Cc: Tim Gardner; Jay Michlin; Maxim Kozlovsky; Jonathan=20
> Goldick; Brian DeForest
> Subject: Re: A summary of my previous work porting our SSC=20
> applications to NETBSD
>=20
> On Tue, 5 Dec 2006 18:20:31 -0800 "Larry Scheer"
> <larry.scheer@onstor.com> wrote:
>=20
>=20
> > The following is a summary of what I found while building our SSC
> > applications:
> >=20
> > The function gethostnamadr_mutex_lock (and unlock.) was one of the=20
> > unresolved functions referenced in our code. This is used in the=20
> > following libraries which are used in many places in the SSC:
> > 		lib/libcluster.so
> > 		libnfxnis.so
> > 		lib/librmc.so
> >=20
> > Gethostnamadr_mutex_lock/unlock appears to be code Onstor=20
> created and=20
> > added to gethostnamaddr in the OpenBSD distribution.=20
> Fortunately our=20
> > changes appear to be contained in blocks defined by=20
> ONSTOR_CHANGE. The=20
> > function gethostnamadr isn't in NetBSD. They use gethnamaddr which=20
> > provides similar functionality. I found definitions for=20
> this function=20
> > in usr/include/resolv.h and=20
> src/lib/libc/net/gethostnamadr.c inside a=20
> > block starting: #if defined(ONSTOR_CHANGE).
>=20
> Does anybody have any idea why we created such a function? =20
> Or should I say 'why on earth?'  The only thing I can think=20
> of is that this function in the C library had local static=20
> data that can be stepped on by overlapping callers and hence=20
> not MP safe.  Any bug like that has long since been fixed in=20
> the glibc, or, a reentrant version of the function has been added.
>=20
> The function name gethostnamadr is not a standard sockets API=20
> function name I'm familiar with.  Long time socket API=20
> function gethostbyname() has a reentrant (MP safe) version=20
> now in glibc by the name of
> gethostbyname_r() and of course the gnu extension gethostbyname2_r().
>=20
