FWIS3

NO, I don't design OSs, I don't have the knowledge or experience to do so.

Just speculating after the recent "to the death" arguments Zee, GJ and I have been having (at one point chairs started flying and the Thougth Police had to intervene as y'all might remember).

Ok. let's say we have a modern commodity CPU (yes I mean Intel).

Now that thing has a 4 level ring architecture.

So, let's say we we're writing the OS to end all OSs, compatible with everything that runs on Intel and through raw processor Power, able to run Non-Intel stuff as well through built-in emulator layers (a la QEMU/SIMH).

How to do that?

Back in the 90s some kid (a 16 Year old Canadian High School Student) came up with the idea of making an OS that would be fully compatible with Windows and could be compatible with everything else and called it "Freedows OS" it never got anywhere. Apparently, not only the project was extremely ambitious, there was also lots of political infighting. and the project members splited into competing projects and later all of them were canceled, the SourceForge Site still exists though. A much less ambitious project called ReactOS started independently about the same time and has been in development since 1998, they have a working version of a Windows "Quasy Compatible" OS that is open source, still in the alpha stage though.

The part that I found interesting was that the Freedows folks intended to use a kernel model suggested by Stanford University: The Cache Kernel, so what is my world changing idea?

Let's make the OS to end all OSs.

The Cache Kernel runs on Ring 0
The Device Drivers run on RIng 1 (an Idea stolen from IBM's OS/2)
The Application Kernels (Linux, ReactOS, "Kernelized" QEMU, BSD variants, etc) run on RIng 2
The Applications run on RIng 3.

There! my job is done, I am now officially as smart as that Boss that Zee had that claimed he "designed products".

yeah, nothing to post on Banana Republic Newsflash and I already did everything I wanted to do with my cheap Chinese Android Phone

Edited for Spelling

[serious]

This sounds like Xen, except Xen instead uses one of the virtualized domains to provide device drivers. Typically that would be a Linux kernel, sometimes NetBSD, and IIRC it does run in ring 1. (Though the other kernels do as well, I think.)

Also, your OS has already been done, using Xen: https://wiki.qubes-os.org/wiki

Though Qubes is more of a paranoid desktop OS, single-user and with an isolation based security model. (Like Android, kind of.) Also it can run Windows programs thanks to Xen and hardware virtualization. Personally I think it's utterly the wrong approach to desktop security, but the people at Invisible Things Labs know a lot more about this stuff than me, so...

[/serious]

The big issue IMHO with the windows O/S is that they are trying to make the GUI part of the O/S itself.
I have no real idea why as it goes against much of what an O/S is meant to be.
Small, tight, efficient, secure and easily maintained.

I suspect this is the case because MS started with a pretend O/S to begin with.
By that I mean, MS-DOS really wasn't an O/S
Neither was DR-DOS or the operating system these were based on, CP/M

The name itself should lead to that conclusion alone: Control Program/Monitor.
CP/M was what I would call a functioning program dispatcher.
It could load a program from disk then execute it and provide some hardware independence by using a BIOS.

There is no ability to run code securely or concurrently. It was a single program execution platform and when it transferred control to the application, that app had full control of anything it wanted to.
That's not an O/S.

r.e. Freedows, Alliance, ReactO/S even Linux, they are partial O/S's.
IOW, they are half way to having the features of an O/S but likewise they have veered to never being a proper O/S.

Oddly the Freedows people used a model that may have worked but sometimes things just mess up.
Where they went wrong IMHO is that they tried to make a real O/S but make it compatible to Windows.
Just think about that from the above description. Windows isn't a real O/S so making it compatible is just going to kill the concept of the underlying O/S you are developing. Now maybe I've read too much into that and am ignorant in what they actually tried to do, but I base my opinion on the time they spent developing and got nowhere. Wasted effort.

Starting from first principles, lets look at what an O/S actually is.
To do that we go back to CP/M to see why it's not.
CP/M could dispatch programs and provide basic I/O interfaces to give hardware independence.
It wasn't an O/S because it provided no ability to run multiple programs and thus obviously to run them securely so they don't interfere with each other. Nor did it have security even for the single app. Once running the app could do anything.

How would an O/S handle this situation differently?
1) It would provide layers security to prevent an app from having higher access than it was meant to. That means restricting address and I/O
2) It would need to be able to run multiple apps of (1) simultaneously.
3) It would need to be small and efficient to allow as many apps as possible to run.
4) It needs to be almost bullet proof. Basically, secure.

Notice that there is not that much difference between CP/M and a real O/S but those differences amount to something huge.
CP/M was small and tight. It allowed 1 app to run unsecured while a real O/S would allow many apps to run securely.
That small change makes all the difference.

So how do we get from a program dispatcher to an O/S?
Well, you just need to understand the fundamental difference between an program dispatcher and an O/S:

A program dispatcher, is an address and I/O space server, nothing more
An O/S is a virtual space server, nothing more.

If you keep that in mind and never break from the above, you will write an O/S that will be stable, small and secure...unless you are really really retarded and I can't see how it could be messed up but, retards can be so damned innovative.
You can do that in 100 rings, or 1 ring.
Only the difficulty in implementation changes and, sorting out address space and ,I/O space infractions, can be done on any system with a little cheap hardware. That is really CPU design 101, its that basic.

Gullible Jones wrote:[serious]

This sounds like Xen, except Xen instead uses one of the virtualized domains to provide device drivers. Typically that would be a Linux kernel, sometimes NetBSD, and IIRC it does run in ring 1. (Though the other kernels do as well, I think.)

Also, your OS has already been done, using Xen: https://wiki.qubes-os.org/wiki

Though Qubes is more of a paranoid desktop OS, single-user and with an isolation based security model. (Like Android, kind of.) Also it can run Windows programs thanks to Xen and hardware virtualization. Personally I think it's utterly the wrong approach to desktop security, but the people at Invisible Things Labs know a lot more about this stuff than me, so...

[/serious]

According to This, there are debates on whether Xen is a Exokernel or not, the general idea is that in an Exokernel the userspace programs could access the hardware device drivers directly. Also, according to this Xen uses Ring 0 and 3 only, just like Linux or Windows. (Apparently Vmware doesn't, the Hypervisor runs on Ring 0, the guest OS runs on RIng 1 and of course the Applications go on Ring 3)

What I am proposing however, is not a Hypervisor. What I am saying is: use the Cache kernel for kernel functions, and use guest kernels (not hardware emulation except for NON-Intel Stuff of course. There, you have no choice, hence QEMU or SIMH) to run on top of the Cache Kernel. like Colinux

What I figure is that the Win32/64 API is close to becoming stagnant, if Microsoft has it way, it will push developer to the new "Metro" type APIs, that would be a good opportunity to use all of the known (Documented and otherwise) WIN32/64 system calls and implement them on a guest kernel. ReactOS and WIne have done TONS of legwork on that regard. If the API becomes stagnant, maybe they can catch up enough to allow the vast majority of applications to run with no compatibility problems.

Why do I think that? A few weeks ago I installed Teamviewer on Ubuntu. Guess how it was implemented? as Win32 Application running on top of Wine. THAT's how Teamviewer offers it's Linux version.

Qubes, being based Xen seems to approach the problem in a different manner I think.

Edited for Spelling (TWICE!)

FZR1KG wrote:If you keep that in mind and never break from the above, you will write an O/S that will be stable, small and secure...unless you are really really retarded and I can't see how it could be messed up but, retards can be so damned innovative.
You can do that in 100 rings, or 1 ring.
Only the difficulty in implementation changes and, sorting out address space and ,I/O space infractions, can be done on any system with a little cheap hardware. That is really CPU design 101, its that basic.

Now you know the reason why I don't design OSs, just use them.

For all I know, the Cache Kernel thing is BS, I've never heard of an implementation.

From what I understand, SInce MicroKernels proved disappointingly slow and memory hungry, we have either Monolithic Kernels (that happen to be Modular) or Hybrids between Monolithic Kernels and MicroKernels

You of course know the excuse used by M$ to move the GUI into Kernel Space right? (which they did when NT 4.0 came out), "Performance"

Well, one of my things was to say, if it takes you longer than a year to develop an O/S from scratch, you've already complicated it.

Well, yeah, most OS implementations tend to become unwieldy monsters because they're designed as you imply, a huge pot where functionality is thrown at.

I just think you're better off with small, simple, tight and efficient.
Think of O/S design in the way CPU design is.
There are two schools of thought on that, more really but it can be broken down to its simplest by CISC vs RISC
CISC strives to give the instructions set everything it can. If tehy could I'm sure they would implement high level language opcodes and execute C++ directly. That's too complex a problem even for the Complex Instruction Set Computer. I threw that in so others might have a hope following this thread.

The diametric opposite of that is the RISC (Reduced Instruction Set Computer) because the developers of CPU's realised that most CISC instructions used in a program are rather simple things such as moves, add's, jumps calls etc.
So they decided that the answer to making better CPU's better is to make those instructions execute really fast and the CISC instructions can then be made by simulating them with the really fast subset. Pretty good in both theory and practice really. Well, for a time anyway since memory access times always lagged behind CPU execution times, memory became a bottle neck. This was largely overcome with multiple layers of cache so we get a pretty good product with a simple core that's easy to develop and expand. Plus it's possible to simulate almost at full speed the CISC CPU's.

The same thing can be said about O/S design.
We can either build CIOSC (Complex Instruction O/S Computer) types such as Windows, the Mac, Linux or we can move to a RIOSC (Reduced Instruction O/S Computer). These are terms I made up, for no other reason other than I have as of today made it really cool and trendy to talk about O/S's using these two acronyms and gives me and others who do, much desired street cred in the O/S community.

The premise being that the RIOSC systems can implement many other O/S's and run them concurrently and almost the same speed while also allowing a platform to develop new GUI's and systems that run apps without the additional layer of Windows, Linux etc. Switching from one O/S to another would be like switching to another window now on the Windows O/S and it would also provide a means for the two to communicate via the new O/S they both share.

Mind you, it's been a long time since I was doing anything with O/S's, about the early/mid 80s.
And this technology changes so fast.
So I guess I might have to pull out some 50's or 60's text books to catch up with what they are up to now. lol

FZ, what you're describing sounds to me a lot like RTOS stuff. Lynxworks, PikeOS, that sort of thing. Also maybe seL4? But sadly these are all hugely expensive. (Except for seL4, but I'm not sure if anything useful runs on that; I'll have to do some DuckDuckGoing.)

I could be misinterpreting things though. I'm very much a Linux geek, and while Linux has a lot of shortcomings my time using it has influenced my thinking on OSes quite a bit.

OT: whenever I hear about logical partitioning, I think of the Joe Haldeman short story "None So Blind," which was published ~20 years ago. IMO it should be required reading material at some point in college, just for its social relevance in this age.

Yes, what Zee is describing is what a kernel is supposed to be like, thread scheduling, message passing, memory management etc. everything else is supposed to go elsewhere. That's how I've heard that RTOSs work and given Zee's background in hardware it's natural that what he tends to lean towards stuff like that. And, as he says, it's nothing new.

Hell, that was what MicroKernels were supposed to be about, what this mythical beast called the Cache Kernel is supposed to improve.

Carnegie Mellon's MACH 3.0 kernel was supposed to be like that and supposedly FSF's GNU/Hurd it's supposed to be like that as well.

Why did MicroKernels gave such disappointing results? NO idea. But the general intent always sounded pretty good. And supposedly L4 is an implementation of a MicroKernel that behaves more like it was expected.

That's the general idea. what I copied from the Freedows thing was the idea that "application kernels" would be in place to provide compatibility with all the stuff that exists. "native" stuff would be running on a different "application kernel" on top of the Cache kernel, on top of that "application kernel" there would be all the userland stuff that would be used to manage the system. "native" (ie new) applications would run on another copy of that "application kernel". And all of that requires that this "Cache Kernel" be what Zee proposes: "small, simple, tight and efficient." the idea of taking advantage of the hardware ring architecture is to help isolate the stuff that misbehaves (particularly the current stuff that everyone wants and its written the way we know it is) from crashing the system.

So basically we have this "Cache Kernel" that ONLY does what a kernel is supposed to do, on top of that there would be "application kernels" (say a linux kernel modified the way the Colinux kernel is, not to touch the hardware directly, but THROUGH the underlying cache kernel) and there would be any number of those running simultaneously, as many as the user wants or as the hardware is able to handle.

It does sound a lot like Hypervisor on top of an RTOS, the difference is that there would not need to emulate hardware, except for the non-intel stuff.

Gullible Jones wrote:FZ, what you're describing sounds to me a lot like RTOS stuff. Lynxworks, PikeOS, that sort of thing. Also maybe seL4? But sadly these are all hugely expensive. (Except for seL4, but I'm not sure if anything useful runs on that; I'll have to do some DuckDuckGoing.)

I could be misinterpreting things though. I'm very much a Linux geek, and while Linux has a lot of shortcomings my time using it has influenced my thinking on OSes quite a bit.

OT: whenever I hear about logical partitioning, I think of the Joe Haldeman short story "None So Blind," which was published ~20 years ago. IMO it should be required reading material at some point in college, just for its social relevance in this age.

It can be designed to run as a RTOS but it's not really limited to just that role.
IOW it's design doesn't exclude it from that role, unlike Windows which would.

BTW, RTOS's aren't expensive or complex. They are simply far more interrupt driven than a standard O/S which tends to use predominately time slicing. Though both can be done and are needed, or the O/S becomes a mess. But, technically you could design an event only driven O/S but it's probably a bad idea.

e.g. The code I have written to control the cards I designed could almost be classed as an RTOS with it's programs predefined.
So I can't load new ones without burning EEPROM's. It however supports multiple threads, is time sliced and interrupt driven.
Depends on your definition really.
Just remember, RTOS doesn't mean everything is done in real time, it just means that it does each job before the allocated time assigned to it has expired. IOW, all you are doing is guaranteeing that a particular program will be serviced at it's minimum speed or faster.
That could be once a day or twice per microsecond.
In my case I have 10uS, 100uS, 1mS, 10mS, 100mS and 1S routines as well as the main loop.
The 10uS is the core of the timing system and sets routines setup timers for the rest of the times etc.
The UHF signals are decoded by interrupts triggered on edges. I have other ISR running as well.
If anyone fails the system crashes. The main loop is reserved for non critical functions like processing the state machines, refreshing the I/O for them etc.

In any case, what I'm proposing is a minimalist system that offer's virtual processing at the core of the design.
I'd just like to add at this point that virtual processing is not difficult or even slow. It just has to be thought about at the design stage.
If it's not thought about, then it becomes messy, slow, complex and unreliable.
Bit like building a house. If you build a solid foundation that allows you to go three stories high but only build one, it's easy to go up to three.
Building a foundation that just scrapes in to pass regulations for a single story isn't going to be easy to make into a double nor will it be cheap or quick to implement.
The cost difference at the start is almost negligible but at the end is phenomenal.

Remember what I wrote right at the start, simple, fast and reliable. They are the goals.
Everything else gets placed on top where it should be.

Now if you wanted to get fancy, instead of just visualising memory and I/O space, you can also virtualise the CPU.
Again, not that difficult to do but that will slow your processing down unless you introduce native mode and non native mode.
Then native mode applications go at full speed while non native get slowed down a bit. Not too much mind you I probably wouldn't play the latest 3D games on it though given the graphics processing now it probably wouldn't affect it too much anyway.
What it would do is allow any CPU manufacturer to put in their CPU into an O/S box and go from there very simply.
Not happy with Intel, pop in a Motorola CPU.
This would also require actual work on the hardware side too and, I wouldn't recommend it because it would involve getting a bunch of hardware manufactures to agree to making a standard CPU layout and memory addressing protocols etc. We may as well try to solve the problems in the Middle East or get rid of the 2A here. It would be about the same level. Nice to dream about though.

Sigma_Orionis wrote:Yes, what Zee is describing is what a kernel is supposed to be like, thread scheduling, message passing, memory management etc. everything else is supposed to go elsewhere. That's how I've heard that RTOSs work and given Zee's background in hardware it's natural that what he tends to lean towards stuff like that. And, as he says, it's nothing new.

Hell, that was what MicroKernels were supposed to be about, what this mythical beast called the Cache Kernel is supposed to improve.

That's the general idea. what I copied from the Freedows thing was the idea that "application kernels" would be in place to provide compatibility with all the stuff that exists. "native" stuff would be running on a different "application kernel" on top of the Cache kernel, on top of that "application kernel" there would be all the userland stuff that would be used to manage the system. "native" (ie new) applications would run on another copy of that "application kernel". And all of that requires that this "Cache Kernel" be what Zee proposes: "small, simple, tight and efficient." the idea of taking advantage of the hardware ring architecture is to help isolate the stuff that misbehaves (particularly the current stuff that everyone wants and its written the way we know it is) from crashing the system.

So basically we have this "Cache Kernel" that ONLY does what a kernel is supposed to do, on top of that there would be "application kernels" (say a linux kernel modified the way the Colinux kernel is, not to touch the hardware directly, but THROUGH the underlying cache kernel) and there would be any number of those running simultaneously, as many as the user wants or as the hardware is able to handle.

It does sound a lot like Hypervisor on top of an RTOS, the difference is that there would not need to emulate hardware, except for the non-intel stuff.

It kind of is. As I pointed out to GJ, just because the system lends itself to being a RTOS doesn't mean it has to be.
Though I certainly would make it that at levels 1 and 2.

As for difficulty, it's not that hard. it really isn't.
You are not designing a replacement O/S for Windows or Linux.
What you are doing is writing n O/S that opens a virtual computer to run those O/S's.
So now those O/S's are removed from level 0.
That instantly makes your platform more stable when running say Windows and Linux or any various versions of each.

What you have to deal with however is the hardware that interfaces to these. IOW, you are designing a virtual PC for them to run on.
The only thing you have to do is make sure all your systems are re-entrant. That was a big killer for DOS for multitasking.
The O/S you are writing then takes care of the actual communication to the said hardware via the level 1 drivers.

Yup, that's the general idea, and yes: all of the "application kernels" or "virtual computers" as you say would have to be re-entrant.

Oh yes, I remember the attempts at doing Multitasking in DOS, they ALL sucked, period

Now, let's suppose you want to run DOS applications on top of this cockamamie thing. You'd be forced to use something like QEMU which WOULD emulate the hardware and then run something like FreeDOS on top of that. I say QEMU because it CAN emulate all sorts of hardware. in case you want to run stuff like DOS or CP/M-86 or CP/M. I suspect I am deviating a bit, originally I figured QEMU would be used to emulate non-intel stuff, but if I were to include non-reentrant stuff like DOS, it would be through something like that.

Re Hardware Manufacturers. Yep yer right, I didn't even think of it though, just figured to use commodity hardware, but your idea of a virtualized CPU is much much neater

Edited for spelling.

Pretty much.
When you look at it, the open source community already has done much of the ground work on this.
A little more and combining the various different projects and you'd have ZeeDos. lol

With squid's programming skills, I'm betting he could do it in a few hours.
Ok, a few days or so to get it working as a proof of concept.

Well yeah, the idea would be to use as much of what the Open Source community has done as reasonably possible.

I was thinking of UDOS (as in Universal DOS) but ZeeDos has an interesting ring to it and to paraphrase SUN's Line on ZFS "The Last Word on Operating Systems"

Damn, we just came up with a slogan and a name without writing a single line of code. We're now officially Vaporware

Sigma_Orionis wrote:Well yeah, the idea would be to use as much of what the Open Source community has done as reasonably possible.

I was thinking of UDOS (as in Universal DOS) but ZeeDos has an interesting ring to it and to paraphrase SUN's Line on ZFS "The Last Word on Operating Systems"

Damn, we just came up with a slogan and a name without writing a single line of code. We're now officially Vaporware

You need a marketing guy.

SciFiFisher wrote:You need a marketing guy.

You're now officially product manager

This product is so hot that it's evaporating on the flip side in even in a bearish market.

I will start the pre-production marketing hype.

ZeeDos... The last OS you will ever need.

It's secure!

It's easier to use than a Zippo lighter!

And women and men will swoon at your feet when they learn you actually own and use Zeedos!

It's cool. It's hip. Don't be square. You definitely don't want to be the last one in your neighborhood to purchase ZeeDos!!!

Best 50's marketing I've seen in years!

Ike and Dick, sure to click

[Mel Brooks Mode]"Don't be Stupid, Be a Smartie, come and join the ZeeDos Party"[/Mel Brooks Mode]

Ok.

This Cache Kernel thing is not so much as mythical as I thought. At least there's a Stanford U paper describing it.

Look at the abstract:

Operating system research has endeavored to develop micro-kernels that provide modularity, reliability and security improvements over conventional monolithic kernels. However, the resulting kernels have been slower, larger and more error-prone than desired. These efforts have also failed to provide sufficient application control of resource management required by sophisticated applications.

This paper describes a caching model of operating system functionality as implemented in the Cache Kernel, the supervisor-mode component of the V++ operating system. The Cache Kernel caches operating system objects such as threads and address spaces just as conventional hardware caches memory data. User-mode application kernels handle the loading and writeback of these objects, implementing application-specific management policies and mechanisms. Experience with implementing the Cache Kernel and measurements of its performance on a multiprocessor suggest that the caching model can provide competitive performance with conventional monolithic operating systems, yet provides application-level control of system resources, better modularity, better scalability, smaller size and a basis for fault containment.

I think I'm going to read the rest of the paper. And, the "application kernels" thing doesn't come from Freedows, it's terminology from the paper. And apparently they did make an implementation of it.

Never trust something just because it comes from academia.
I learned that the hard way with a project that was an expensive dud and everyone that had a clue knew it even the people developing it.
They milked millions however to do research on it.

I don't have the time to look into it right now but something doesn't add up.
But things that make me suspect are that a cache is nothing more than a system to speed up memory based mainly on cost, not performance.
It's not impossible to get far higher speed memory than you PC runs as main memory.
The problem isn't the technology so much as it is the cost of providing super fast access RAM.
It also consumes far more power which in turn means more expensive regulation of voltages and power supplies.

The only thing that modern cache has that isn't a cost factor is proximity to the CPU core when built on chip or placed right next to the CPU chip, usually both, unusually called internal and external cache. What a surprise. That just means reduced propagation delays which are pretty high by proportion when you start getting clock speeds about a 100 MHz.

Now, compare this to an O/S. What have they got in common?
Nothing.
There is no propagation delay issues in software for there to require a cache. The RAM speed is RAM speed either way.
The only thing you would use a software cache for is to speed up slow device access such as a hard disc.

So inserting one in a system that gives no speed advantage (actually slows things down because its implemented in software) and otherwise provides only reduced performance on a page fault is meant to speed things up. How exactly?
Maybe I haven't made that clear.

Average latency for a cached system is determined by the ratio if its hits and misses and the speed of a hit vs the speed of a miss.
A miss is basically what they call a page fault.
The speed of a hit is the cache speed.
The speed of a miss is the RAM speed.
Now what happens if you make cache speed = RAM speed?

You waste resources and nothing else.
Plus they have to fill page faults in software and provide the cache mapping in software, so that means that its hit is slower than a miss would be if there was no cache due to that overhead.

So I just can't see what they are trying to achieve.
They claim it makes the core kernel simpler. Well, yeah, if the core does nothing other than act as cache for no reason, sure it's fast.
What about the O/S on top of it? How exactly is it going to be any faster?

Anyway, I have to get back to my own stuff.
I just wanted to say the above. Something no make sense. Abla?

Trusting it because it comes from Academia? nope, liking it cause it sounds cool? yep.

That's why I'll read the paper. Up till know I had little more than the name and a general concept of what it did, at least now I have some material to read and see how it's supposed to be better than a MicroKernel. I just want to know if it's worth the trouble, cause otherwise just use L4 or Hurd and be done with it.

I don't think it's caching memory, I think it's caching pointers and handles, but I might be wrong. If all it does is caching memory, why bother make a kernel out of it, use a hardware cache

It's caching address space and threads.

Though like I said, I haven't got the time to get into it something sounds funny.

An O/S isn't a cache. So by producing a cache they have effectively pushed up the complexity to the next layer and called it not their problem.
That' basically what I see.