[openbeosnetteam] Re: DNS bug

Hi,

> > Was our aim to have BONE compatibility? 
> 
> Well, at OBOS project start, it was not clearly stated, and most of the 
> time a R2 feature.
> But since Zeta show up, making BONE public, I guess we have now too 
> much BONE-based app out to afford to not support them in OBOS R1.
> So, yes, BONE compatibility could be considered a new task for R1.
> I'll add it to web site soon.

I would not have exptected something else.

> > Today I surfed around with Net+ (using our netstack and ppp, or 
> > course ;).
> > Also, I could check out some sources via cvs.
> 
> Congratulations!!!

Thank you.

> I guess it's time to move this team overall progress indicator on web 
> site a little toward Alpha middle phase!

Let's move this bar up to beta in the next two months. :)

> > Vision did not work because it wants to have BONE. The problem with 
> > BONE is that its SOCK_STREAM, etc values conflict with the net_stack 
> values.
> 
> Yep. I tried to sum up the net_server, BONE and our stack differences 
> and compatibility issues in current/docs/develop/net/
> r5_compatibility.html page, but surely I forgot about some of them or 
> I'm wrong about some others.

Yes, that is really useful.
But Vision did not work because of a bug in our select() emulation. When it is 
turned off it works okay.
I also think that either bind(), accept(), or listen() (maybe all of them) are 
not working properly because I could not download files using ftp (only 
browsing the ftp server via Net+).

> > It seems that we must add our own libsocket.so and libbind.so for 
> > BONE compatibility. I think libbind.so could be a link to our 
> libnet.so. 
> 
> I think it should work, but it rely on the runtime linker not checking 
> the real library filename. I dunno if it'll be still the case with OBOS 
> runtime linker. Axel, does it check the real image filename match the 
> lib name supplied in app ELF header, or he doesn't care (which is great 
> but not much secure) and simply follow symlink?

I think we can forget that. All of those libs are needed (see below (after you 
enumerate the libs)). :(

> > libsocket.so would have to adjust the socket type value. I could need 
> > a helping hand.
> 
> I should be able to do that. Creating a new folder in src/kits/network/
> libsocket feel easy enough to me as a comeback!

Please don't. I did that already. It is all in my private repository waiting to 
be commited.

> libnet.so
> libnetapi.so
> libsocket.so
> libbind.so
> libbnetapi.so
> 
> The last 3 are for BONE compatibility, but if we can come with lesser 
> real libraries, and symlink them for BONE compatibility, it'll reduce 
> the code to maintains. I already see in the future that one can be 
> confused discovering we have in current/src/kits/network a libnet, a 
> libnetapi (already confusing name!), a libsocket, a libbind and a 
> libbnetapi (best confusing library name already in the BeOS dev 
> community!!!) library.

What does libbnetapi.so do? Is it libnetapi.so ported to BONE? Can we not drop 
that? :)
The problem is that libnet.so relies on R5 values for SOCK_XXX, but BONE (why 
the heck did they do that!?!?) replaced SOCK_DGRAM with SOCK_STREAM and the 
other way around. In socket.c we check if these values are less than ten which 
is (was) our SOCK_DGRAM. This hack does not work with BONE compatibility. Our 
libsocket.so must have its own socket() implementation.
Unfortunately, I had to use the SOCK_XXX hack to get the old BIND working in 
our libnet.so because it must somehow tell socket() that it wants a SOCK_DGRAM, 
but it cannot do that with the BONE values which conflict with R5 (socket() 
would think we want DGRAM although we passed STREAM).
So, after the check against [type < 10 && family != AF_INET] I put
else if(type == SOCK_STREAM) // SOCK_STREAM = 11
    type = SOCK_NATIVE_STREAM; // NATIVE_STREAM = BONE_STREAM
else if(type == SOCK_DGRAM) // SOCK_DGRAM = 10
    type = SOCK_NATIVE_DGRAM;
The native values had to be defined in socket.h, too. The emulation and native 
values for SOCK_XXX are only enabled if
BUILDING_R5_LIBNET is defined. Otherwise SOCK_STREAM is the same as in BONE.
You see, this is a _huge_ mess, but I do not want to put too much work into the 
R5 part if we can get BONE compatibility done instead.

> If we could find a cleaner way to provide BONE compatibility, I'll be 
> happy...

Surely Be thought about it and they did not come up with a better solution. If 
they at least had the correct values for SOCK_XXX it would save us some work. 
Do you think YellowTab would correct that? (of course not :)

Bye,
Waldemar

Other related posts: