OSDev.org

Hi Dudes,

i have just read thru all your postings and asked myself why you all are sitting alone in the darkness doing an OS of your self.

Right now I'm planning to find someone who really is interested in spending money on the development of a brand new OS.

As far i have an own Idea of an Operating System too, which in some kind of ways is a bit similar to the Ideas you Couples have.

I could try to tell something about my Concept, it would be nice if some of you is going to add a few comments to my ideas.

First of all my OS should be fully object oriented. There should be an modular application model which gives users the possebility to construct there own applikations thru adding modules into an applikation container.

Each of these Modules should bring there own XML DTD and write the Output of the modules into the dokuments.

Every Document will have there own DTD after you did chose the needed modules and saved the application structur into an XML Document.

Documents are not to be saved as closed documents, but instead as Object Cointainers, which you are able to open in the Hostapplication, with which you did create the Document or instead you are able to open the Document as a kind of folder where you see the objects the document consists off and can chose to edit a single object just with the modules needed for working on the object.

Thru the Group and Usermanagement of the OS it will be easy to make different instances of an document, wo every group, based on the rights management is able to see different versions of an document. Customers have different instances of an document than people in the Adminstration or buisness Group of an company.

Every Modul has to be scriptable too, so it is possible to make webapplikations with the power of standard desktop applikations.

The GUI has to be controllable thru XML, XSLT and SVG so every OS Distributor is able to build special OS Versions, so it fits to the needs of there Customers, like Banks, Privats, Furniture Companys or what else.

It will be like, when you will see an Computer which GUI you are not able to recognize it will be the OS I've invented.

The Drivermodel of my OS should be based on introspection, so there is no need anylonger for writing special drivers for the OS, the OS will on its own find out how to use the Hardware (This is the Point, where i'm not really knowing if its possible).

It should be easy be possible to do a network wide resource sharing, so you can easy build up cluster systems without extra software. Other People in the same company could just give some of there Memory and Prozessortime just for computing my own threats faster. In the meanwhile i could just work on and do something else.

Every single Module of the OS should run in its own protected memory space, so if one of the modules in an applikation fails, not the hole applikation is closed, but just the module is thrown out of the memory again and is been reloaded. Because of every computing step is recorded in another part of the memory and after a short while on harddisk, there will not be a big loss of working steps.

The Filesystem has to be selfoptimizing, so in idle time the Computer starts to reorganize the files on the harddrive, so defragmentation or things like that will not be necessary anymore. I became thinking about that, because of someday we will have 3 Terrabyte Harddrives and noone ever will be able to reorganize these drives, unless it will take a year of time doing it )

The Virtual Harddrive Management i became thinking of should just make things possible to give multiple clients a kind of network drive without having a server. Documents will still be writting to clients harddrives but will be provided to the other clients as if there where saved on a network wide server drive. But still both things will be possible (Servers and Clients VDrives)

Because the OS is bases on Layers it is possible to change the driver model without reinstalling the GUI or other things.

Because of the modularity there is no need for an software developer to reimplement code for saving filedataformats like PNG, GIF SVG or what else, because every application will be able to write these formats, when the dataformat modul is saved in the OS Environment.

The Integrated Authoring System allows Users to work on objects of an single documents at the same time, based on the rightsmanagement. In some cases multiple instances of an document are created imediatly.

I'm stopping up now, for the first.

My desition is to wait for building an real company up for developing this thing. One person on its own is making to many errors and the development takes many many years. so in the meanwhile the hole world is changing, so its just better to work all together.

But I'm not the best coder in the world.

Have it nice!

Hermes

Talk about aiming high!

At least you realise it will be hard work. Most of the ideas you mentioned are similar to existing ones. I think some Mac Apps save in 'containers' similar to what your suggesting but its down to the app to implement it. I like your ideas just one thing. How can the OS teach itself to use the hardware. Ok, it can find out what and where the hardware is from PnP, plug'n'play and PCI stuff but learning how to use it is completely different

How are you going to do it?

Pete

Hi Pete,

maybe you should look at this link. Its not direkly what i mean, but maybe i have to change my ways a bit.

http://www.nondot.org/sabre/os/articles ... nterfaces/

Please look at the UDI Driver Model from the SCO. Its quiet interesting.

Too i would like to use Reiser4 as Filesystem, maybe.

;O)

Hermes

Oh, you mean being able to support drivers from other OSes or standards. Yeh that's easy by comparison. Are you aiming for a server OS or desktop. In my opinion for a server OS you're better off having the drivers compiled in with the kernel. Not in the kernel by linked with the kernel.

MY OS PLAN

Name : Cimicis (latin for 'of bugs' )
Target : x86
User : server

Key Ideas
-Task switching is based on network events. i.e. If a request comes in on port 80 (HTTP) then the web server gets the highest priority until the request is finished at which point it will have lowest priority.

-Drivers will be modular (i.e. have set functions to provide to the kernel) but they will be linked with the kernel at compile time for speed.

-All tasks (programs) are started at boot. After that they can fork to handle multiple requests but new programs can't be started.

-User interface is unimportant. There will a debug CLI for admins but everything must be setup in config files.

-The memory manager will know at boot how many tasks there are and will allocate all the memory. Then all mallocs and frees will be based on that heap by clib functions. If one server is known to need more memory than another it can be specified in some config file so that it won't run out.


These are just initial ideas, what do you guys think. I'm still not sure on the line where things start to be loaded at runtime instead of in-built

Pete

Are you going to implement multithreading? That's a pretty useful model for server applications, especially when combined with I/O completion ports.

For example, to serve a web page:

• Have a fixed number of threads, e.g. one per CPU
• Create an I/O completion port and have all threads wait on it
• Start an I/O operation for a client, i.e. write to socket
• When that write finishes, the kernel writes to the IOCP and wakes one thread
• That thread does what it needs to do and starts another I/O operation; and so on

This way, there is only ever one thread per CPU running, so no unnecessary thread switching.

-Task switching is based on network events. i.e. If a request comes in on port 80 (HTTP) then the web server gets the highest priority until the request is finished at which point it will have lowest priority.

How would you do this with one CPU and a number of processes? Giving all processes highest priority doesn't sound like any sort of real preference. Also, did you have your eye on keepalive HTTP and things like that, connections that persist for a reasonable time?

-Drivers will be modular (i.e. have set functions to provide to the kernel) but they will be linked with the kernel at compile time for speed.

If you make the dynamic linker link fully (no PIC or jump table) you would not experience any delay from dynamic linking. Even still, I can agree with you on linking statically in a server-only OS, but only for some modules. Some servers support hotplugging drives, processors and similar things. How would you support those, if you cannot load in new drivers? (think new processor type, new kind of harddisk)

-All tasks (programs) are started at boot. After that they can fork to handle multiple requests but new programs can't be started.

Now this seems to me like a bad idea, even for a server. This would make autoupgrading servers completely impossible (think apt-get).

Still, on the other hand... it has some very nice implications:
- Somehow unhackable, unless explicitly available: you cannot open a new bash or whatever, it's not there so it will not be
- Static thread / process tables can be in ROM (embedded servers)

-The memory manager will know at boot how many tasks there are and will allocate all the memory. Then all mallocs and frees will be based on that heap by clib functions. If one server is known to need more memory than another it can be specified in some config file so that it won't run out.

Servers (and other programs) have dynamic memory requirements, making those allocations static again is going to get a lot of servers going down on you at the gain of extremely minor bits of speed. If the server has a static memory usage, it will never call upon those resize and realloc functions, and if it has a dynamic memory usage, it will require those functions. Therefore, it either isn't delayed or it requires the functions, so you have no gain leaving them out. Then again, swapping isn't as bad as some people think it is. Having 3x your real memory at a minor speed impact is a good win for just about all instances, and in those where it isn't necessary it doesn't cost you any.

Example on my thoughts (really plain):
HTTP server taking 8M when idle, 48M when active
FTP server taking 8M when idle, 48M when active
SMTP server taking 8M when idle, 48M when active

now, doing such a static memory allocation would get 48M reserved to the SMTP server, even though it might only get 1 mail per hour. Also, it requires the server to have 144M of application memory, which is a big requirement.
Doing it with dynamic allocation would allocate 8M to each, and in case of swapping added, only 48M would actively be needed in a not-really-loaded server.

To begin with I don't plan on implementing multi-CPU support. As I want to eventually use it on my spare PC as a server and that PC's single processor.

How would you do this with one CPU and a number of processes? Giving all processes highest priority doesn't sound like any sort of real preference. Also, did you have your eye on keepalive HTTP and things like that, connections that persist for a reasonable time?

The processes won't all have highest priority. When a request from the network occurs the following will happen:-

[0] All servers are dormant (NO CPU time) and have one 'master' thread each. Each server is set up with the required network ports
[0] NIC Driver ISR catches bytes
[0] Network Protocol Object interprets packet
[0] Server assigned to that port is woken up ('master' thread).
[0] The server's master thread forks to provide a thread to handle the request.
[0] The master thread gives up its CPU-time and goes back to dormant.
[0] The sub thread handles the request then ends.
[0] Back to square one.

As you can see this will act in a cooperative multitasking style unless there are more than one requests at one given time. If that happens then the multitasking becomes preemptive to allow both requests CPU time. This method eliminates the need for the server app to listen on a port which means it needs no time. As such there isn't a high priority status its just that enless there is aa request the task wont run. For the equivelent of CRON jobs then I might make it that you can associate the app with any event rather than just network activity. So you'd associate another server app with a certain time period managed by either the RTC or PIC driver.

Regarding the driver loading process etc. I've just had the idea that maybe the binary distro of the OS could have the kernel linked into one library and then distribute the driver object files so the user just has to link several files.

Somehow unhackable, unless explicitly available: you cannot open a new bash or whatever, it's not there so it will not be

That's the idea but following on from the device events thing I could set it that a certain local keyboard key combination would stop all servers and loaded a single tasking CLI for debuging purposes.

RE Memory Manager point taken. I'm just trying to find a way to minimise the syscall memory allocation overhead calls. What ideas do you have to reduce the time required to alloc/free memory?

Hope I've cleared somethings up

Pete

Pete wrote:What ideas do you have to reduce the time required to alloc/free memory?

Do it less often.

provide the serverprocess a malloc library, that manages the heap and calls "mo'memory" only, if the heap runs out of space.

Didn't really think a new thread was needed for this:-

Cimicis Server Operating System Web Site Up
http://therx.sf.net/

The only real information is the developers' manual under documentation. For anyone whose interested in the project this is where all code, images, concepts will be released. Do not expect a release soon. ATM I'm concentrating on making my ideas clear in the docs. And most of the code I'm writing is being tested under Windows.

Pete

here's my idea of an OS.

objectives: clean, well-defined, component-oriented, portable, universal.

process model: all interaction of processes with os and each other is to be done thru interface method calls (like COM/DCOM). dynamically-loadable in-process shared libraries will be used (also thru interfaces) for efficient functionality reuse without context switching.

kernel is only required to do, in addition to essential kernel tasks (process, memory management etc), call dispatching. it does its job and gets out of the picture.

hardware drivers are just privileged processes that get to work with hardware. they also communicate with higher-level services (GUI, FSs, network protocols etc) via method calls.

the process model spec will say nothing about how actual kernel or traditional services (GUI, FSs etc) will be implemented - that will need a separate design for each. so an actual operating system will be assembled from components - kernel, drivers, services, applications - be it a desktop system for a naive user or a server sitting in a rack.

implementation plan:
-first, proof of concept. a hybrid simulated environment - user processes in an artificial simulated instruction set (sample apps in asm or some simple compiled language), kernel services and some components in C++. this is to avoid dealing with hardware and to be able to run it easily from any existing OS (possibly even in a useful fashion).
-once design has been finalized and proven, kernel and drivers for actual hardware will be implemented.

i am planning to do it alone, at least first stage. but criticizm, suggestions, comments and offers of participation are welcome.

Icefox wrote: Well, I'm a relative newbie on the actual implementation side of things (plus I haven't had time and motivation co-inciding for a while), but I have a few higher-level ideas that hopefully will be interesting.

First off, I thought the concept of "filters" might be useful. Many UNIX programs can be chained together with pipes, so that the output of program X gets fed into the input of program Y. Well, it might be a good idea to formalize and expand on this idea. So you have a bunch of filter applets, each taking a certain number of input streams and producing another number of output streams. So these could be used for such things as compression, spell-checking, all that fun stuff. But since they can do more than one input and output at once, they're more flexible, for instance you might want to use one as an automatic sound-mixer. And they'd all be arrangable in a nice drag-n-drop interface with pop-up config boxes, instead of remembering zillions of command-line switches.

I have a few other thoughts, but I gotta run, so I'll post 'em later.

Well I'm not sure if this is the same idea but I know that Mac OS X 10.3 (Panther) has a "Services" menu within most apps allowing you to use the functionality of other apps such as Safari or Mail within another. I don't know if I'm explaining this right. There was an article on the whole thing in a Macworld magasine I had purchased.

Well, aren't we shooting high?

I'm aiming right at my feet so that I don't get disappointed when I can't impliment something. My OS is a FAT12 16-bit real-mode single-tasking hunk of performance. Instead of moving as much as possible out of the kernel, I'm puting it all into the kernel. As long as I keep it organized and don't go overboard, it keeps everything running smoothly.

Modules (I prefer to call them 'plugins' in my OS) are simple little features that you can plug in only if you need them. The directory structure is something like this:

/fd
|->/system
| /plugins
| audio.plg
|->/programs
|->/files
| myfile.bin

Sure it's a bit simple and there isn't many features, but it takes no time to load. My goal for the OS is to be able to seriously use it, and develop it from inside it's self.

I think the most important things are speed, a compatible api and an allaround clean feeling.
I also think it's a good idea to reuse as much code as possible and since my os will be under the GPL I can reuse drivers and source that is also GPLed for my own purposes.

my future os:

"FireOS" //has this name been taken yet?
_________

coded in c++

BeOS style kernel, app_server, media_server etc........

reiser fs //maybe modified? I want to stay compatible.

Qt or html for gui apps.

Linux cli apps should compile with little or no changes.

Anyone can just use xml/html to create a simple gui for
linux cmd line programs.

The driver model should follow linux's
as closely as possible.

dir trees on different devices should be accessed in the following manner:

hda1:// hda2:// dvd:// cda://

BUT you can get all of the info about the device (maybe in files like "proc" or in a control panel) with:

hda1:\\ hda2:\\ dvd:\\ cda:\\

The network would be mounted as a device as well:

smb:// and smb:\\

all devices would be mounted the moment the kernel knew about it.

you could also have a file extension search. Say you want to see all of the *.doc files in hda1?

hda1:doc:// or *.app files, hda1:app://

or both:

hda1:doc:app://

FireOS will be geared towards home and small office users.

oh, dude, common. OS design isn't limited to the way you will name your system directories ...