[openbeosnetteam] Re: Random muslings
- From: "Jean Schwerer" <j-schwerer@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Mon, 5 Nov 2001 01:13:18 +0100
Hi all,
>Hi all. I've bowed my head in shame a few weeks ago, and what can I say,
>BeOS is like a drug which (once addicted) is a habit hard to break. Elate
>isn't as much fun as I thought it would be, and I'm slowly becoming aware
>that there may be a possibility that I'll come crawling back to the lovin'
>OpenBeOS arms (if you'll take me back :-)
hehe. Nice to see you back :-)
>What does the OpenBeOS networking team need to implement?
>
>1) The Network Kit front end.
>This is the API presented to the user. User applications use the interface
>by referencing BeAPI header files and Posix header files. The network team
>needs to re-implement the following frontend (from the BeBook):
> a)- BNetAddress class (convert net addresses to generic internal
>type) - easy
> b)- BNetBuffer class (allocate buffer and append/delete data) - easy
> c)- BNetDebug class (debug info) - piece of cake
> d)- BNetEndpoint (object oriented socket - wrapper for socket calls)
>- slightly moderate
All this is quite easy. It can be built using Nettle's source code, which can
be found on bebits.
Basically all it needs is adding BArchivable methods (plus a couple
constructors and methods) to
each class. I have begun work on this but I must admit I've been waaaaay tooooo
slooowwww
on this ^_^ I only worked on BNetAddress so far :-(
> e)- network sockets - moderate to time consuming (the meat of the
>kit).
> - socket()
> - bind()
> - getsockname()
> - getpeername()
> - recvfrom()
> - sendto()
> - send()
> - recv()
> - listen()
> - accept()
> - connect()
> - closesocket()
> - shutdown()
> - setsockopt()
> - select()
> f)- BSD network database interface - easy
> - gethostbyname()
> - gethostbyaddr()
> - getservbyname()
> - herror()
> - inet_addr()
> - inet_ntoa()
> - gethostname()
> - getusername()
> - getpassword()
> g)- Network settings - easy
> - findnetsettings()
> - setnetsettings()
>
> Thats all we need to be source compatible.
> h) - additions to the API (wish list)
>
> From the OSI layered model point of view, the front end could
>corrolate to the Transport and Session layers.
>
>2) The Network Kit back end
>This is the actual net_server which interfaces with the kernel/hardware.
>From the OSI perspective, it provides the functionality of the Data-Link and
>Network layers. The average developer writing a network application
>considers the back end to be a black box. Until I finish reading the
>FreeBSD design book, I cannot comment on the structure of the black box.
>
>Marcus Overhaggen from the Media Kit team did an excellent job of
>demonstrating how to convert the B header files into a dummy C program with
>pluggin functions - empty pluggin functions for now (a single debug printf()
>to show status), but functions which will be filled in as the team
>progresses. Marcus honestly believes that binary compatibility is possible,
>and so far he can get 3rd party apps to link without errors (of course, they
>dont run yet). I think that a couple of members of the Networking team (a
>couple and no more) can attempt the same with the above front end. This
>will show progress to the rest of the OpenBeOS teams, and will allow the
>very first files to be checked into CVS.
I personnally like Erik Jakowatz's approach :o) I hadn't understood clearly
what Erik had done
until he sent me an email last week explaining how he did achieve a wrapper
library. His approach
enables binary compatibility even while working on the library.
Basically Erik makes a wrapper library (let's call it "WLib") that will export
the same symbols as
the original library (let's call it BAPILib). He then moves BAPILib to another
location (so that the
system won't want to call it but will call WLib instead) and opens it from WLib.
From there, here is what we can do:
When WLib is called, it calls BAPILib to achieve the result if the call has not
been rewritten yet.
It can even output some debug info before and after calling BAPILib.
If the call has already been rewritten, well then WLib does the job itself
without calling BAPILib
:o)
That way at a given instant you always keep full binary compatibility and
replace calls one after
the other, until the whole library is done.
Although Erik didn't use the tool Marcus suggested (stubgen), nothing prevents
us from using it
as well (hehe ^_^), as stubgen only creates empty cpp files from Be headers.
This can be used
as the first step for the wrapper.
So it all turns down to:
- Using nm a first time to give a quick look to which symbols are exported by a
library.
- Identify which BeOS header files correspond to those symbols
- Run stubgen on those header files
- Run nm again to identify which symbols are missing and add them
- From the resulting cpp file, call the original library
- Move the original library out of the way, test and debug the wrapper to make
sure it works
- When the wrapper is made to work, implement the calls
You will find the mail explaining the binary compatibility process there (as
Erik explained it):
http://www.profuzion.org/en/openbeos_net_team/binary_comp.html
I also put the Wish List online (as Emmanuel put together what had been said):
http://www.profuzion.org/en/openbeos_net_team/wish_list.html
And the layout (as Dmitri drawed it):
http://www.profuzion.org/en/openbeos_net_team/netlayer_layout.html
Comments on any of the above are very welcome!
>As far as everyone else is
>concerned, the black box can be a rip off of the FreeBSD networking
>implementation (hey, nothing to be ashamed of, its one of the best in the
>industry),
... and it's already used nearly everywhere ;o)
>and all they really want is source level (100% possible) and even
>better, binary compatibility (possible).
>
>Anyway, I'm prepared to take the challenge of preparing the header/pluggin
>files. Is that OK with you Jean (glorious team leader)?
Sure :^)
Please make sure you check Erik's work an tell us what you think about it
first, I think it's really
worth it. You'll find everuthing about it at the URL above.
Jean
Other related posts:
