BRiX - Operating System

Is the OS orthogonally persistent? (As EROS-os [www.eros-os.org])
Or should each piece of code and object know how to serialize itself to disk?

What is the safe language to be used? Where can I find its specifications?

Perhaps using a language variant of a safe language such as Python, or some Lisp variant can save you a lot of language design and free you up to work on the OS?

I've been planning to embark on a similar (almost identical, actually) OS myself, as soon as I had the time, and so I was considering implementing some safe bytecode that I can later compile many safe languages to.

Just to make sure I understand your idea is similar to mine, does all of the code execute in Privelege Level 0, or does the code still have to employ expensive RingLevel switches?

As for achieving performance (removing runtime checks), without losing safety, there's another related idea of logic-languages, that allow you to prove the safety of your code with logical primitives in the language, so that you have logical proof alongside the code, that the compiler can verify. This does not encounter the Halting Problem because the compiler isn't proving anything, just verifying _your_ proof of safety is correct. It is also fast, because at runtime, none of the tests have to run. Most of all, it is safe, because the code was logically proven correct.

P.S: IMO, you should probably mention the proof by author of EROS OS (Shapiro), of the property of confinement, because it also has a profound effect on the security of your system, as it seems to me to be such a capability system.

> Is the OS orthogonally persistent? Or should each piece of code and object know how to serialize itself to disk?

It is both orthogonally persistent and file based.


> What is the safe language to be used? Where can I find its specifications?

Crush.
http://brix-os.sf.net/?p0=info&p1=crush
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/brix-os/crush/


> Perhaps using a language variant of a safe language such as Python, or some Lisp variant can save you a lot of language design and free you up to work on the OS?

I have pretty much finished designing Crush and already have a working compiler.
It will take another week or two of active coding before Crush is complete but
right now it works and compiles basic code.


> Just to make sure I understand your idea is similar to mine, does all of the code execute in Privelege Level 0, or does the code still have to employ expensive RingLevel switches?

PL0 only.

What do you mean by file-based?

Objects are stored as files instead of mapping memory over the disk. When an object is loaded the system uses a template to build an internal representation of the object. The persistence mechanism uses the template to convert the object back into a file.

The use of files prevents the 4gig (32bit address space) disk problem and the templates handle all the conversion so object code doesn't need to know how to handle files.

I think there are simpler ways to get around the 4GB memory space problem.
Using a safe language easily allows you to implement 64-bit offsets, while automatically repaging things for 64-bit addresses to be accesible.
Even using a non-safe language in EROS, they get around the problem by letting user processes set their own page tables.
Its probably a lot simpler and more powerful to implement Orthogonal Persistency as it was thought of in EROS [www.eros-os.org], or in Vapour [vapour.sourceforge.net], because it allows you checkpointing (the ability to always fall back to older checkpoints in case of problems), historical records (The abilty to go back to any point in time in 5-minute resolutions, for long whiles) and allows for smarter and simpler caching techniques/etc.
The main problem with being 'file based', is that if code has to _name_ the files to access them, rather than simply refer to them with normal references, you get a global-namespace, which is a serious problem. If objects are just referenced, and not named, then the 'files' are an implementation detail hidden from all code, which is probably just implementation clutter.

Pointer swizzling is too slow and one day you would install your new 20 million TB hard drive and be forced to recompile all your apps using 128bit offsets. And BRiX doesn't have processes so who will setup the page tables?

Checkpointing is for operating systems with flaws. But BRiX increments the object's version for each automated save and can roll back to older versions.

Files are referenced with a numeric identifier, no directory structure. Only user files such as documents have names and they are stored in the search engine's database which is only used by the user.

A numeric identifier is still a global namespace (unless its somehow local to an object?).
A global namespace is problematic in terms of security.

Your files are limited in size, just like memory space is limited in size. Whatever offset size you use in files, simply use that in virtual memory.
This way is much simpler to use and moves more abstraction into the lower levels, allowing the higher level applications to not worry about data organizatoin or persistence at all.

As for "who pages", that can be the VM that implements dereferncing anyhow.

As for checkpointing being needed in defective systems - that's simply not true.
Or rather, all systems are defective: In cases of hardware failures or simple power outages, you want to roll back to the last stable checkpoints.
Rolling back only in specific file objects, you may get an incoherent state where objects are not taken from the exact same time.

As for organizing things in "files" and not in virtual memory, it may also complicate things like holding references to objects (instead of holding a simple language reference, you have to hold a file reference, and an in-file reference). This limits abstraction and may make a lot of code file-aware, and less abstract.

If the ID is part of a global namespace then so is a pointer. The safe language does not allow IDs to be generated so its impossible for a piece of code to open a file without being passed the ID.

I can upgrade the filesystem without recompiling all my code, unlike pointer swizzling. The files are handled by the lower levels. The 'apps' don't know how to deal with files, persistence is handled by the OS. File organization is done by adding the file ID to the database and associating metadata (title, keywords, etc) with it. System files and other stuff the user could care less about are not in the database.

"who pages"?

The internal state of the computer is not persistent in brix so power failures won't hurt it. The user interface is persistent so your windows will reopen in the same state (the entire state, not just the window you left them. Other services that associate the state with a file are also persistent.

The file reference looks like a pointer to the programmer and is handled transparently by the language. Your approach would force all pointers to use pointer swizzling and slow the system down. My approach uses fast platform specific pointers for all internal operations and slower persistent pointers for the data saved to disk.