FreeLists / openbeosnetteam / [openbeosnetteam] Re: BIND port

["Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>]

Hi,

> > the BIND port (9.2.3) is nearly finished. For complete BONE 
> > compatibility we need all *_r() functions which depend on some pthread 
> functions. I hope they are not too difficult to port.
> 
> Can't we use BeOS Thead Local Storage (TLS) for that, instead on having 
> to port/rely on pthread support.
> And I'm not saying that because I find pthread API ugly compared to 
> BeOS one... ;-)

Those pthread functions are for accessing the TLS and they should be rather 
easy to port (*crossing fingers*).

I want to get BIND _without_ touching _any_ file except for the headers that 
are generated by configure and our Jamfile. It is good that the complete BIND 
build without the *_r() functions only spits out some warnings (mostly wrong 
printf() parameter specification: %d where it should have been %ld).
This has the advantage that updating to a new BIND version is as simple as 
copying all files into the appropriate folders and maybe making one or two 
modifications to the headers that configure generates. I marked all 
modifications to the headers with
// OpenBeOS
to make merging the configuration headers simple.

> > Please tell me before you change our posix network headers because I 
> > will replace many of them with the new BIND headers (in my local 
> repository this is already done). I would not like to mess around with 
> CVS merging failures.
> 
> You need to fix many POSIX network headers because of BIND v9.2.3 !?

Well, there are about six new headers and five modified ones. It exports more 
functions and the inet_aton, etc. functions all have a double-underscore (__) 
prefix which libnet.so does not have.

> > Is it okay if libnet.so stays with the old BIND version? I do not 
> > know how else we can export the needed fuctions. It is a bit hacky, but 
> if it works why change it... 
> 
> Until we reach R1, we can always change whatever we want to make stuffs 
> better named and/or placed, simpler, easier to maintains, etc.
> After it will be far harder.
> Nobody except us and maybe some anonymous adventurers are using our 
> current libnet.so implementation, so we can break it.

Yes, but even after R1 we will not have to change libnet.so. By the time of R2 
it will probably be completely removed. So, we should try to get the code in 
select.c and socket.c working and leave the rest as it is. Those two files are 
needed by libsocket.so, too (but I moved copies of them into the libsocket 
folder because those hacks from libnet.so are not needed and libsocket.so 
should be really clean).

> Can't we update the whole old BIND version we have instead? I really 
> don't like this dual code design introduce for BONE compatibility, when 
> the difference are very small (but hard to automaticly detect, I 
> agree!).

We could, but I would rather put libnet.so on hold. Apart from very old BeOS 
apps (Net+ ;) that do not have a BONE version nothing needs it.
The new posix network headers are making R5 compatibility really tough. All 
inet_XXX functions are not compatible (I #ifdef'd the #defines for the 
__-prefix out if BUILDING_R5_LIBNET is defined), but who knows what else is 
wrong? We can do that later when BONE compatibility works.

> > with BONE compatibility there is not much use for a clean libnet.so 
> > and old R5 apps, anyway.
> 
> Well, except that *our* libnet.so was not supposed to be *only* for old 
> R5 apps at first.

That is no problem. All our apps (arp, ifconfig, etc.) should work fine with 
libsocket.so and libbind.so.

Bye,
Waldemar