OSDev.org

Well, you can rise IOPL to any of these privilege levels, so you could put IO driver code into these rings. The main use for these PLs is, AFAIK, that they can freely access any data segments with higher PL (higher value, lower privilege, I mean), so a disk driver in ring2 could write directly into a buffer in a ring3 data segment, that was provided by an application.

But when you use the flat address space model (and thus overlapping segments), the benefit of ring1 and ring2 tends to zero, that's probably why these PLs are typically not used anymore.

cheers Joe

Yes, but disregarding which privilege level I put IOPL in, what's the actual difference between the two?

Hi,

Crazed123 wrote:Yes, but disregarding which privilege level I put IOPL in, what's the actual difference between the two?

AFAIK it's mostly for systems that use segmentation fully (perhaps without paging).

For example, you could have the kernel at CPL=0, device drivers at CPL=1, services at CPL=2 and applications at CPL=3. Then, device drivers would be able to access segments used for services, but services wouldn't be able to access segments used for device drivers.

Apart from this (and IOPL) there is no difference between CPL=1, CPL=2 and CPL=3. There are some instructions that can only be used at CPL=0 which makes it a little different.


Cheers,

Brendan

One more question, since I don't have processor docs for non IA-32s: Do those other architectures have an equivalent to designating a process ring 1 or 2 and setting IOPL there, thus allowing device drivers to be run outside Pure Kernel Mode without giving I/O access to user programs?

Thanks a ton.

I don't know of any, at least

• Alpha
• PowerPC
• ARM
• StrongARM
• IA64

don't have an equivalent to IA32 segmentation, AFAIK. PMode segmentation was a try to revive the advantages of 8086's fixed base segmentation, AFAICS, but with some protection extensions (the PLs) and variable segment bases. And in theory it could work really good, if there only were a decent number of compilers that fully support segmentation, and modern CPUs would implement it in a more efficient way.

In general, using segmented memory has become quite out of fashion. And I don't mean that just the people don't use it much - also the CPU designers did not enhance the segmentation hardware much in today's processors (P IV, Athlon64). I remember there were rumours (or even facts?) that using non-flat segments today generates quite a lot of overhead, at least.

Yes, but disregarding which privilege level I put IOPL in, what's the actual difference between the two?

Eh, I suspect you left my previous post half-read, have you?

cheers Joe

Actually, I read it. I just wanted to know the technical difference between the two rather than the benefits of using them.

Hmmm... so I guess non-IA-32s only have userspace and kernelspace. Drat, I was going to create a seperate protection level to put device drivers in.

In general, using segmented memory has become quite out of fashion. And I don't mean that just the people don't use it much - also the CPU designers did not enhance the segmentation hardware much in today's processors (P IV, Athlon64). I remember there were rumours (or even facts?) that using non-flat segments today generates quite a lot of overhead, at least

AMD64s in 64-bit mode (not compatibility mode) force a flat memory space and don't allow different bases or limits for CS and DS (ES, FS and GS may be changed for special uses), so it seems it's going quite out of fashion.

Crazed123 wrote: Hmmm... so I guess non-IA-32s only have userspace and kernelspace.

For the most part, yes. Although I remember reading up on MIPS, and being surprised to discover that it has three modes (user, kernel, and supervisor). In general, you can't assume more than two modes if you want your OS to be portable to other architectures.

Hmph. So do other processes at least have a way to simulate the extra protection level by designating some user processes able to do I/O but not others?

I would really look it up myself, but I don't have the docs and don't want to go hunting down processor docs for every processor I'm not using so far.

Crazed123 wrote: Hmph. So do other processes at least have a way to simulate the extra protection level by designating some user processes able to do I/O but not others?

I would really look it up myself, but I don't have the docs and don't want to go hunting down processor docs for every processor I'm not using so far.

IA32 is one of the few architectures that has a separate I/O space. Most other architectures use memory-mapped I/O exclusively, which means you can control access to devices with the MMU. If you were to implement drivers in user-mode, the kernel could grant a driver appropriate access to its device's memory-mapped registers.

AR wrote: @purevoid: You're writing your OS in OCaml, all in kernel mode, right? In this case you can just directly link against the kernel, no need to worry about gates since you have no protection rings.

Yes I am. How can I link against the kernel? I'd be very interested how this would work, so that I can dynamically load ocaml programs at runtime =)

The ELF Spec includes documentation on how to implement dynamic linkers, basically you'll just need to export symbols from the kernel and have the dynamic linker bind the symbols to the programs at runtime.

I'm not sure whether exporting symbols from an executable image (kernel) works properly, but it should hopefully. Basically the kernel will be just acting like a DLL.

According to ELF it will work, it just isn't used on any current systems.

ColonelKernel: Thanks, that makes everything exactly as portable as I want it to be.

Any tips on how to export the symbols correctly? I was told they have to show up in .dynsyms section of my ELF file.

Good question. Shouldn't it work just to export them like you would from a normal program, thus making them show up in the exported symbol tables?