[openbeosnetteam] Re: DNS bug

> How far away is our API from BONE? Not only since BONE is now official 
> with the release of Zeta, I think it would also be nice for the actual 
> users not to have to separate between three different networking 
> solutions on the application level.

That's what I would prefer, too. Our native API should be the same as BONE.

> So if achieving BONE compatibility is just a matter of some minor 
> constant and structure changes, I would try to go for it (not as 
> another compatibility layer, but as the native interface to our kit). I 
> wouldn't mind libsocket.so and libbind.so to be just dummies to our 
> libnet.so, though.

Our constants would have to be adapted to BONE, but [libnet.so: socket.c] we 
have routines for settings R5 compatibility mode which depends on the current 
constants (SOCK_DGRAM, etc. are using values >10). So, libnet.so would have to 
be rewritten to R5-only mode. Our native interface (the same as BONE) would 
live in libsocket.so.

Now, the problem is: where do we put the DNS code? Duplicating it (for every 
lib) would not be a good idea. Be decided to put it into libbind.so. I prefer 
this approach because we could get native BIND support and use the normal 
configure script to build the library version. We have to add libbind.so for 
BONE compatibility anyway.

Thus, libnet.so and libsocket.so would link against libbind.so for DNS 
functions. Will there be linking conflicts if libbind.so links against 
libsocket.so for socket functions (apps linking against libnet would load 
libsocket indirectly, but both of them export socket(), sendto(), recfrom(), 
etc.)? In BONE libbind.so links against libnet.so (which means it should not 
result in conflicts), but I think this is bad because native (and BONE) apps 
would load all three (!) libs which makes them load slower than R5-apps and it 
needs more resources.

In brief, it will not be as easy as I thought (using dummies), but libsocket.so 
would be a very small lib exporting only the most needed functions. Our code 
would become much more readable (only a few functions, separated libs, less 
hacks for compatibility). We could try to compile the current BIND version 
(9.2.x) which has support for multi-threading (surely no locking issues) and we 
would get fixes for free.

Shall I give it a try? But I do not have much time in the next five weeks, so 
this will probably have to wait.

Bye,
Waldemar

Other related posts: