I believe x64 specifies that only rings 0 and 1 are supported. So clearly AMD thought that were was so little market for OSes that require or can use rings 2 and 3 that they cut the feature. (There *is* a non-zero cost for hardware features, in design time, verification, fab time, chip area, power, etc.)
All of this is interesting, from an OS design point of view, but is rather pointless when applied to NTDEV. The NT model is what it is – two levels of privelege. So are most of the major, commodity OSes, so it isn’t exactly an uncommon model.
Also, people should consider the additional complexity that driver developers would need to deal with. Driver developers already need to understand IRQLs, paged-vs-non-paged, arbitrary thread context vs. known thread context, etc. Adding another axis to this would cause a lot more cognitive load for the developers, and would not in reality deliver much value. (Whole forests have been cut down to print all of the research papers on device driver isolation.)
Try to imagine the excruciating number of combinations of paged/non-paged, 4x rings, and multiple drivers all communicating with each other. If I allocate data at ring 1, and I pass it to a driver or OS component that runs at ring 0, what should happen? Boom? Now raise that number of combinations to the power of the average PNP device stack depth, and it quickly becomes obvious that more than 2 rings just causes insanity. At least if it is shoe-horned into an existing OS design, and not part of it from the beginning. (And I don’t know of any OS designed after 1980 where this was a feature. I’m sure the peanut gallery will point one out, though, if there is.)
Would I like to have better isolation between drivers? Of course. Which is why I would suggest looking elsewhere, such as http://research.microsoft.com/os/singularity/, rather than trying to resurrect a processor architecture that is not used, and is basically being abandoned.
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of Tim Roberts [xxxxx@probo.com]
Sent: Wednesday, March 28, 2007 2:34 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re:Driver Programming Fundamentals/Philosophy, was: Re: Calling NdisRequest() from ProtoclBi
Maxim S. Shatskih wrote:
> I don’t understand your point, Maxim. Portability between what and what?
>All these RISC machines, and now IA64.
Having the OS unportable to any other CPU even theoretically is a bad idea.
Nonsense. The ring 1 thing would be implementation detail of the x86
kernels – an added benefit available on architectures that had multiple
levels of protection. It certainly wouldn’t require any source code
changes in drivers, so I am unclear on how it would affect portability.
There are certainly precedents for this. NT supports I/O ports, even
though those do not exist on non-x86 architectures. It supports memory
barriers, even though those only have meaning for certain architectures.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer