You don't know what you're talking about.
/BAH
You don't know what you're talking about.
/BAH
Did you notice that I used the word "proportion"? Do you know what that means?
I don't have to know.
/BAH
Sigh! There will have to be communication between cores. How that gets implemented will determine the security, reliability, and consistency of performance. Morten is using QNX today. How this will be changed to run within a mega-core complex system is the subject. Morten has talked about this in another post. This concept has the monitor (your nanokernal) not knowing about any hardware which implies that the I/O will be done using network protocol. Now think about that.
/BAH
You did not read what I wrote. Those virtual OS spaces you were talking about are applications w.r.t. monitor which is running.
You seem to be confusing OSes with monitors.
If it's absolutely in charge of the entire system, then it has to be able to access all of hardware, including the other cores. This implies that some kind of comm protocol and/or pathway has to go from all those other cores to the master core. This sucks w.r.t. performance. The system will run only as fast as the master core can send/receive bits. All other cores will constantly be in "master-core I/O wait".
/BAH
But Microsoft is going to fix that with their next OS.
Well, there are degrees of "most secure". ;-)
/BAH
No. YOu don't see my point. Distribution has a completely different set of problems that need to be solved. I worked long and hard to try to solve the simplest of them (this implies that the simplest were extremely complicated). When your business is distribution, then the tradeoffs of all design decisions will be made in favor of distribution and not anything else.
On-line distribution and support means that backdoors have to be wide open.
/BAH
No. The context of term core in this discussion has been CPU. These CPUs will be more sensitive than the old-fasioned memory doughnuts.
/BAH
On any solid CPU design, with ecc ram, you can run hardware diagnostics for hundreds of unit-years and never see an error.
Try that same test running an OS.
Engineers have figured out how to do their part right. Programmers, in general, haven't.
John
And will be until it's released for production.
John
There's nothing wrong with shared memory, as long as the kernal has absolute control over mappings. That must of course include all DMA transfer priviliges.
But the kernal CPU *knows* about everything; it just doesn't have to
*do* everything.John
How many CPUs are being shipped that use CML? Hint: it's in the very, very low single digits.
John
All the kernal has to do is set up priviliges and load tasks into processors. It should of course do no applications processing itself (which would imply running dangerous user code) and has no reason to move application data either. Stack driver CPUs, device driver CPUs, file system CPUs do the grunt work, in their own protected environments. There can be one shared pool of main memory for the apps to use, as long as access mapping is safe.
Memory can be shared as needed for processes to communicate. But nobody can trash the kernal.
What's wrong with that?
Even Intel is headed in that direction: multiple (predicted to be hundreds, maybe thousands) of multi-threaded cores on a chip, surrounding a central L2 cache that connects to DRAM and stuff, each with a bit of its own L1 cache to reduce bashing the shared L2 cache.
Does anybody think we're going to keep running thirty year old OS architectures on a beast like this?
John
What's wrong with waiting, when you have 1024 CPU cores available, and the limit is thermal? We've got to stop worshipping CPUs and start worshiping reliability.
John
I, for one, think we are going to do just that -- which is not the same thing as saying that I think it would be a good idea.
Nyah, they can fix it with a service pack.
As in: The Right Way (Better is Better), the Wrong Way (Worse is Better -- unless it's the other way around), and the Microsoft Way (If it boots, ship it!).
I consider myself a good programmer; interestingly, when I start to design some program using pseudocode, it (my pseudocode) always seems to turn to C. ;-)
Cheers! Rich
QNX is just made for such an environment. And it is 28 years old this year.
-- mrr
Whatever the OS of 10,560 is, it will probably be called OS/360;-)
Maybe you're right. How depressing.
John
Batch process runtime mentality.
She and her 'grasp' of computer science has some serious "been out of the mainstream for too many decades" issues.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required