| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
The Kernel Group is responsible for the design and implementation of a Kernel for JOS.
This working group is part of the ArchitectureGroup
Ray's Orange Book Summary
Yes, of course! A fully featured OS, but still simple and usable. Let's try to make JOS simple but powerful - we don't need an other oversized, slow and buggy OS as we have in "ยง$"$ ... (you know, which "OS" I mean ;-)
there's a working group called DistributedGroup here at JOS, that is thinking about ways of distributing processes (and Agents?) across a network of workstations. I new to JOS, but I think the idea is good. Maybe you could get a glimpse at the DistributionProposal to see if there's a way to integrate these ideas in the kernel. --CarstenEckelmann, 30-May-98
echo blah > ram:file.txt
Not only created a file in the ramdisk, it created the ramdisk if it wasn't there. Dos ALMOST had that idea, but instead of "com1:", "con:", and "nul:", it let them bleed into the file namespace instead of the device namespace (which it already had for "a:", "b:", "c:", "d:"...) With a little ingenuity, we can go "dir prn:" to get a list of files waiting in the printer queue, and could even "del prn:thatfile.ps" right out if we wanted to cancel it. (Needless to say, this makes programming the GUI part of it almost trivial).
I think it's a very powerful idea, properly applied, and makes adding new devices very easy. Just agree on a standard name for your driver to register the device under, then give it just enough of an interface to the file system to control it. (Imagine "dir sound:" returning files "input" and "output", and you just write raw data to "output" to have it play, and multiple opens return different streams which automatically overlay the tracks... Read data from "input" to get raw digitized data. Different filenames could have different filters (output.au, output.wav)) Just do a DIR to see what's supported... Of course we'd need a "SYSTEM:" we could dir to see what devices were available...
Maybe I'm dreaming...
RobLandley 7/10/98
I see most of you writing your separators as ":"... why not use the URI model? This would be in-line with Java and the Distributed etc. model that has brought us together... :) it will also mean a lot more to a lot more people as they have already used it, regardles of OS. Another small point, is that its clearer than ":" and is tranparent in relation to other java "path" structures. (e.g. JDBC, HTTP etc.)
-- BrillPappin
anyways.. im pretty new to kernal stuff, I've browsed a book about QNX system architecture and really like it's micro-kernal thing... It's extremeley extensible and scalable.. I'd like to see some code, and maybe get a better understanding of this thing is going to work.. any pages I should look at that might answer various questions?
How much code is finished, and does it do anything.. and what sort of file system do you guys plan to use natively.... what sort of multi-threading/multi-user support is going to be built in... and is this going to be written in c/c++ like I think Sun's JavaOS was, and just have built in Java support.. or is it all going to be written in Java from the Kernal on up to everything..
I know a lot of these questions are not totally kernal questison.. but bare with me... Is the GUI going to be built on top of a shell, or is the GUI going to be run on top of an interface that any OS coudl support, or is the GUI going to be built into kernal so it always has a GUI and a shell is extra (like Windows)... So Id like to help out with this any way I could.. lemme know how..
-- JamundFerguson 25-JAN-99
I'm very much in favor of QNX, too. They are going open source pretty soon (register yourself at get.qnx.com if you're interested). However, I think I remember they won't open up all of QNX; I haven't understood yet which part will remain closed.
They are even developing a Java VM!
I think we could create something bootable very quickly by using QNX. It probably won't be really free in the GPL sense, but personally, I'm not so dogmatic in this question... something is free if I don't have to pay for it, end of story. We can always replace kernel and JVM later. That's the good thing about Java after all.
Jamund: IMO the kernel should not contain any UI. Both shell and GUI are Java programs that are loaded by the kernel.
--StefanReich, 26-APR-00 (oh what a hopelessly late reply =8)
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|