[openbeosnetteam] Re: Me as well...

Quoth "David Reid":
>
>Changes Required
>- fd == pipe == socket needs to be implemented correctly.  We should be able
>to call select on an fd, pipe or socket, set timeouts on pipes and sockets
>(don't make sense on fd's do they? ) and so on...  This brings us much
>closer to being able to port and run all sorts of cool stuff.  Also it
>dramatically simplifies a lot of posix type stuff.

I think POSIX compliance would be a really good thing.  Hell, even NT did it. :)

>- allow sockets to be shared across teams/processes and allow them to be
>inherited after fork
>- add support for shutdown

Forgive me for looking like a fool, but what are teams, and shutdown? :)
(I have done socket code on unix before, just don't recognize the terms,
haven't done anything to rough.)

>Would be Nice To Haves
>
>- IPv6

I'm definitely interested in this, as well as a few other IP specs such as
bridging and tunneling using a few different methods(especially IPSec!).
I think BeOS already did NAT?

><I did warn you!>

Nothing wrong with some real conversation going on here. :)

>Can I ask, how committed are we to binary compatability, as this stuff
>really needs to be ripped out and rewritten, which would blow away any
>chance of binary compatibility.  It should be possible to support "recompile
>and run" without much heartache...

Now, I don't have a lot of experience with deep OS stuff, but wouldn't it be
possible to have a set of 'emulation' libraries or something, which could be
written on top of our OpenBeOS library in order to provide binary compatibility,
but still let us advance R1 in small ways?
(I'm from NetBSD, where there exists COMPAT_LINUX and COMPAT_FREEBSD and such,
which allow me to run binaries from linux/freebsd as long as the required 
libraries
are in a directory tree in a specific place blah blah blah.  It's nice in a 
*lot*
of situations.)

Other related posts: