[ECOS] gethostbyname

[ECOS] gethostbyname

[Dan Conti]

Hi,

i wrote a simple dns client for eCos and was looking at adding it into
the kernel and, naturally, populating gethostbyname() (i haven't
implemented reverse lookups and dont need to, so gethostbyaddr() isn't
useful for me).

i haven't been able to find an example of how gethostbyname() is
implemented. specifically, is it possible to implement without dynamic
memory, and can i assume endhostent() will be explicitely called? i'm
not too familiar with convention on these items. is gethostbyname() a
kernel fun in *bsd? i couldn't find it when i looked. pointers
appreciated :)

-Dan

--
Dan Conti             e danc@iobjects.com
Software Engineer     p    (425) 289 0326

Re: [ECOS] gethostbyname

[Andrew Lunn]

On Mon, Aug 13, 2001 at 04:11:18PM -0700, Dan Conti wrote:

Hi Dan

I've done the same, implement a DNS client for eCos. Im currently
waiting for Management to sign a copywrite release so it can be
contributed to eCos.

> i wrote a simple dns client for eCos and was looking at adding it into
> the kernel and, naturally, populating gethostbyname() 

Its not part of the kernel, its part of the network stack. You should
place it into packages/net/tcpip/current/src/lib/
 
> i haven't been able to find an example of how gethostbyname() is
> implemented. specifically, is it possible to implement without dynamic
> memory.

I looked at the resolver library that comes with bind. I then decided
it was too complex for what i needed and did it a completly different
way. Yes, you need some sort of dynamic memory. To make this work
correctly in a multi threaded enviroment i used malloc and the per
thread data index pool to hold the information that each threads
need. Each call to gethostbyname frees the results from the previous
call and then creates the state for the current call. This fits the
BSD symantics

> and can i assume endhostent() will be explicitely called?

Nope. I've seen very few real programs call that. If you port
something from Unix its unlikly to call this function. Something you
hard craft yourself may. 

> i'm
> not too familiar with convention on these items. is gethostbyname() a
> kernel fun in *bsd? i couldn't find it when i looked. pointers
> appreciated :)

No, its in libc. All the major Open Source Unix systems use the
resolve library from bind. 

        Andrew

Re: [ECOS] gethostbyname

[Jonathan Larmour]

Andrew Lunn wrote:
> 
> On Mon, Aug 13, 2001 at 04:11:18PM -0700, Dan Conti wrote:
> > i wrote a simple dns client for eCos and was looking at adding it into
> > the kernel and, naturally, populating gethostbyname()
> 
> Its not part of the kernel, its part of the network stack. You should
> place it into packages/net/tcpip/current/src/lib/

Actually, it shouldn't use any private interfaces - only public ones, so it
should live in its own package. That way different network stacks (e.g. the
mini one RedBoot uses) can use it.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] gethostbyname

[Andrew Lunn]

> Actually, it shouldn't use any private interfaces - only public ones, so it
> should live in its own package. That way different network stacks (e.g. the
> mini one RedBoot uses) can use it.

Hummm. Does redboot provide BSD sockets? A kernel so i can use mutex,
per thread data? I think not. 

Quite a few of the functions inside the lib directory do not use
private interface. getserbyname, gethost, all the bootp stuff since it
uses ioctl, the tftp server and client code, inet_addr etc. Why is
this not in a generic package?

        Andrew

Re: [ECOS] gethostbyname

[Jonathan Larmour]

Andrew Lunn wrote:
> 
> > Actually, it shouldn't use any private interfaces - only public ones, so it
> > should live in its own package. That way different network stacks (e.g. the
> > mini one RedBoot uses) can use it.
> 
> Hummm. Does redboot provide BSD sockets?

Not with exactly the same API, but we can make it work. It's only UDP - you
can make a socket and use a recvfrom and sendto.

> A kernel so i can use mutex,
> per thread data? I think not.

You don't need per thread data for RedBoot - those would just be configured
out.
 
> Quite a few of the functions inside the lib directory do not use
> private interface. getserbyname, gethost, all the bootp stuff since it
> uses ioctl, the tftp server and client code, inet_addr etc. Why is
> this not in a generic package?

Inertia?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] gethostbyname

[Andrew Lunn]

> > > and can i assume endhostent() will be explicitely called?
> > 
> > Nope. I've seen very few real programs call that. If you port
> > something from Unix its unlikly to call this function. Something you
> > hard craft yourself may. 
> 
> So if you call gethostbyname() only once then you have leaked memory?
> eww.

Well, yes and no. stricktly speaking yes. The result from
gethostbyname is always be valid until the program exits or endhostent
is called. Since this is an embedded system, the program never calls
exit. Since i don't implement endhostent, you cannot tell the DNS
client you have finished with it, so its legaly still valid.

What i don't know is what is the symantics of endhostent() in a multi
threaded enviroment? It would be a bad idea for it to release all
memory since some other thread may still be using there state
information from the last gethostbyname it called. In my opinion, its
safer not to implement this function until someone actually needs it
:-)

> On a related note, when do you think your management team will ok
> releasing your client? I'd be more interested in multiple people
> using (and in turn testing) a single client than deploying mine only
> to find it doesn't work with xyz dns server.

Hard to say. This is probably the first time they have been asked to
release something into the OS world. It may take a while to perswaid
them.

My testing has only been with a Solaris server running Bind. Testing
on other server, and big endian targets would be very interesting.

        Andrew

RE: [ECOS] gethostbyname

[Dan Conti]

> From: Andrew Lunn [ mailto:andrew.lunn@ascom.ch ]
> Subject: Re: [ECOS] gethostbyname
> 
> 
> On Mon, Aug 13, 2001 at 04:11:18PM -0700, Dan Conti wrote:
> 
> Hi Dan
> 
> I've done the same, implement a DNS client for eCos. Im currently
> waiting for Management to sign a copywrite release so it can be
> contributed to eCos.
> 
> > i wrote a simple dns client for eCos and was looking at 
> adding it into
> > the kernel and, naturally, populating gethostbyname() 
> 
> Its not part of the kernel, its part of the network stack. You should
> place it into packages/net/tcpip/current/src/lib/

Ahh that is what i meant. For me, anything under 'packages/' is the
'kernel'. Yes i have gracelessly inserted it into tcpip/current/src/lib.
  
> > i haven't been able to find an example of how gethostbyname() is
> > implemented. specifically, is it possible to implement 
> without dynamic
> > memory.
> 
> I looked at the resolver library that comes with bind. I then decided
> it was too complex for what i needed and did it a completly different
> way. Yes, you need some sort of dynamic memory. To make this work
> correctly in a multi threaded enviroment i used malloc and the per
> thread data index pool to hold the information that each threads
> need. Each call to gethostbyname frees the results from the previous
> call and then creates the state for the current call. This fits the
> BSD symantics
> 
> > and can i assume endhostent() will be explicitely called?
> 
> Nope. I've seen very few real programs call that. If you port
> something from Unix its unlikly to call this function. Something you
> hard craft yourself may. 

So if you call gethostbyname() only once then you have leaked memory?
eww.
 
> > i'm
> > not too familiar with convention on these items. is 
> gethostbyname() a
> > kernel fun in *bsd? i couldn't find it when i looked. pointers
> > appreciated :)
> 
> No, its in libc. All the major Open Source Unix systems use the
> resolve library from bind. 

Thanks for the info. I might dodge plugging it into the standard
interface just because it looks like a low return on a lot of extra
work. On a related note, when do you think your management team will ok
releasing your client? I'd be more interested in multiple people using
(and in turn testing) a single client than deploying mine only to find
it doesn't work with xyz dns server.

Thanks again,
-Dan

> 
>         Andrew
>