Travis Geiselbrecht, the developer of NewOS, writes in his web site: “Haven’t updated this list in a while, but there’s a lot of progress being made. Over the last couple of months we’ve implemented a rudimentary network stack, full dynamic lib support, and work has been started on a real native filesystem. Also a full-fledged IDE driver is in the work. Thanks to all the people that have helped me out.” Download the latest version of this young operating system, in a source form here.
NewOS Now Includes a Network Stack
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
to ask “how do I make a floppy out of this?”
Nice work, NewOS team
If you can’t even figure out how to make a floppy there’s no point in bothering. I say this because once NewOS is booted there’s nothing you can do with it unless you’re a kernel hacker.
Does this mean that OBOS will be using these new features, or do they only use a part of the NewOS kernel?
Since OBOS is using NewOS kernel, and the NewOS kernel now has a network stack, does this mean that OBOS does? I thought that they were implementing the Network stack in userland?
There has been alot of internal debate in the OBOS team about where networking should be implemented (kernel or user land), and the final decision for the first release of OpenBeOS is that it will be in userland, just as it is in R5 (netserver). One of the main reasons for this decision is that it will allow the networking team to test the networking code on BeOS R5 (by simply replacing the R5 netserver with the OBOS netserver). So the NewOS kernel networking stack will not be used at this time. It should be noted that it is likely that release 2 of OBOS will transfer networking to the kernel (as much of the current code is being written with this move in mind). But even at that point it is more likely that they will use the networking stack they develop and simply (well it’s not simple, but you know what I mean) move it into the kernel.
Yes they are busy with a userland stack. They wanted to get started with something, and start learning a lot. They are trying to make things so that they can always move stuff to the kernel later. Their code is not based on Travis’. And they are moving pretty fast too!
I wonder what that native filesystem is. Is that a generic layer on which all filesystems work or something, or is it a real filesystem ala ext2, bfs, fat etc???
A word of advice to the BeOS network stack hackers. Put it in the kernel for goodness sakes. I’ve done stacks both ways, and the kernel implementation always wins hands down. With a userland implementation, your performance will suffer from the kernel <–> user switching, and kernel socket handles generally work better when they look like file handles. Also the networking protocols can be very timing dependent and performance will suffer as a result.
P
Re read the bits;
“the main reasons for this decision is that it will allow the networking team to test the networking code on BeOS R5”
and…
“It should be noted that it is likely that release 2 of OBOS will transfer networking to the kernel”
With a userland implementation, your performance will suffer from the kernel <–> user switching
only if you have a slow context switch. if your context switch time is minimal (L4, gemini) then the flexibility you gain from a userland stack far outweighs the small performance hit.
it must be noted that in x86 I/O instructions are priviliged, so that requires a kernel stub which increases the CX time by an order of magnitude. but in a decent architecture…
As others pointed out, the OBOS network team is developing a userland stack. We are *NOT* aiming to be the fastest stack around, but we do intend to be the most (or one of the most) flexible ones 9and with a nice API too). David Reid is doing a hell of a job and we already can send/receive udp packets. I guess we will have something others can actually use sooner than later. Also I would like to point out that David did some work in the NewOS stack, but I am not sure if it was ever commited to the source tree.
Also, as pointed out by others, we will probaboy use our stack instead of NewOS’ one when OBOS becomes something tangible (i.e. the average geek will be able to actually make something usefull with it).
Concerning the filesystem, Travis is creating a simple filesystem at first with basic functionality. As soon the vnode layer is in place (it will evolve while the native FS is developed) we (the OpenBFS team) will be porting OpenBFS to NewOS.
I wonder how easy it is to seperate Travis’s networking stack from future kernel progressions so that you may implement your own. I hope this doesn’t lead to problems down the road because philosophies about the 2.0 releases are interfering with the pre-alpha stages. It seems the previous fork, aka the BlueOS team, can’t even drop some html code to show their progress, which isn’t a good sign.. so you’re currently the best hope for the future. Just curious.
I am not the right person to answer that, but as I understand it when NewOS is a bit more mature it will fork so OBOS can take it to a different direction other than the one Travis is going to.
Anyway, there will be work involved if we really decide to rip the current net stack in NewOS to include our own, but this is not something that can’t be done.
-Bruno
The BlueOS team is still active, but you are right, we didn’t find time to update the website. It’s a good sign in fact, C/C++ code is more usefull than HTML files…no?
However, it will change soon, a ‘website team’ exists now.
The new website was postponed weeks after weeks but I promise you that you will see big changes soon.
“It seems the previous fork, aka the BlueOS team”, you forgot that BlueOS was started BEFORE OpenBeOS…
Do you want news ? Ok, just one about the UI, now we can draw UI elements like BButton, BCheckBox, BBox, BStringView.
Wait the screenshots and binaries.
I am not a programmer by any stretch of the imagination, but wouldn’t it make more sense to use the kernel networking stack implementation (for new programs, and for speed), and have a userland passthrough for the older programs that need to use userland networking?
Seems to me that it could be a best of both worlds solution – still maintaining R5 compatibility, but at the same time providing new and better(?) functionality.
Dunno. Just my .02
Actually if the userland and kernel implementations have both the same Interface (BSD sockets, for instance), programs really do not care if it is a userland or kernel implementation. There is no need for a “userland passthrough”.
-Bruno
I really appreciate having that “Restart Networking” button around.
With the current OBOS plan, you’ll still be able to restart networking/net_server if it crashes or hangs.
I’m curious about still being able to restart networking if it were moved into the kernel for OBOS R2. Anyone?
I’m sure the current developers are as aware of this as anyone, but P_developer is right about file descriptors. That’s a serious problem in BeOS up to 5.0, and putting the network in the kernel was supposed to fix it. There may be other ways.
I would have liked to see message ports integrated into that system too. The point is to have all kinds of “slow” I/O in the same domain for the purpose of some kind of dispatching function, like select(). That particular function could be supported even better (more broadly) with an event system like VMS’.
It should be possible to restart networking if it’s in the kernel, but you can’t just kill the net_server if it hangs.
My take on that is that BeOS is not intended to be server system – I’m willing to take a 10% performance hit from a userland network stack if I get the flexability and stability advantages it has over kernelspace networking.
Well, the point is that the restart networking thing in net-server was a hack to workaround the fact that the R5 net-server is as buggy as it can be. You should not need to restart networking.
You don’t need a kernel implementation to be able to have sockets == fds. In fact we are considering doing it in our userland network stack and the obvious reason would be to have something like a /dev/net/socket device.
-Bruno
stew:
> It should be possible to restart networking if it’s in
> the kernel, but you can’t just kill the net_server if it
> hangs.
Hmm… If networking does eventually make it into the kernel, I’m not sure if there even would *be* a net_server anymore… Recall, with BONE there was no net_server.
the main reason for kernel networking code is for application elegance. Having a socket look like any other file and using the select call makes for fairly clean event loops when mixing descriptors that all represent streams (e.g. file, comms/printer port, pipe, socket and so forth). YOu shpould at least make the socket plumbing part of the kernel even if you push the implementation up to userland. Also there is another benefit in that if a socket is synonomous with files, you can also pass it as a handle to your create process function or whatever you use.
In WIndows you have to go through great hoops to manage sockets as one can’t guarantee that a socket == fd, and you can’t use the select() call on other things either. This was ok when TCP/IP was originally grafted into windows, but has become somewhat of a headache later on.
For your interest, the original Trumpet Winsock (1.0-2.0) was written as a 16 bit DLL which happens to be shared across all tasks. There were major headaches preventing applications stomping on other’s sockets, but generally it worked ok. The real bottleneck was the 16 bit code and the DPMI interrupt thunking to get to the network drivers. It did fairly well though and was the fastest on the block until someone hacked a version of BSD as a VxD driver. Not sure what became of that, but curiously it disappeared and MS’s kernel implementation appeared – not sure if they are the same.
Version 3.0 was the same except it had a 32 bit dll which thunked to the 16 bit layer.
Version 4.0-5.0 moved the network code into the kernel and I got a speed improvement of over 2 times. The limitation is now the speed of the NDIS drivers. It has a 32 bit DLL as it’s native layer to the driver with a 16 bit DLL thunking to the 32 bit one. This version appears to be a good deal faster than the MS stack on Windows NT it seems. THe socket handles are still not file handles though as this would result in some extra glue code into the file subsystem and is very OS dependent.
The only downside I had with the kernel implementation was that I couldn’t do userland things like send windows messages and access the comms functions. This meant that these functions had to be wedged in as userland stuff and the headaches associated with keeping the two synchronized.
Petros has a very similar stack (there is some slight forking), but has full integration as one would expect.
P
>You should not need to restart networking.
No, you shouldn’t. But on MANY occasions, I’ve sworn and thrown things at my Windows machine during the tens of 5 minute reboots while I made the smallest change to networking. I’m no networking expert, and it took me several tries to get my router and IP addresses, etc to work. Having a ‘Restart Networking’ button was a godsend in BeOS.
I’m gonna have rebooting nightmares tonight…arrrrgghhh. “Please insert your Windows 98 Setup Disk”
Thanks P!
Change a driver or make a change to your nertwork settings and… “Please insert the very disc you don’t have in your CD-ROM drive at this exact instant (and maybe don’t have access to)… or else I will go totally bonkers and make your life a living hell.”
“Windows 98… it’s the little things that drive you crazy.”
Jared
the stack does not have to be in userland to have the settings restarted by the press of a button (ie *BSD, Linux do not need a reboot)
P_Developer it is not really true that Windows has poor support for async/waitable sockets. Windows has FANTASTIC support for async sockets but it’s not by using the select() or poll() calls, on Windows you use WaitForMultipleObjects() or if you have a GUI MsgWaitForMultipleObjects() which is even more flexible than select() on fds. You can wait on most primitives exported by the kernel such as mutexes, threads and more. Since the Windows NT family kernels export a general event object they are far more flexible than the comparable file descriptor methods. QNX has something similair although not as competent and BeOS as absolutly crappy support for the similair functionality and I don’t need to point out that asynchronous IO has better performance than the threaded variant.
If you are serious about doing a open BeOS variant you should add support for async IO as soon as possible and it would be good if the BLooper/BHandler was replaced with something based on the Reactor pattern.
– Trollish