Goldfarb, Christopher <[EMAIL PROTECTED]> wrote: > > Aren't native x86 bits considered priviledged instructions?
"Fergus Henderson" <[EMAIL PROTECTED]> replied: > > No, not from the point of view of the OS or the hardware. > I think you are confusing the different levels. > > As far as the OS and the hardware are concerned, there > are two kinds of x86 instructions: the normal unprivileged > instructions, such as "add", "mul", "mov", etc., which can > be used by any process, and special privileged instructions, > such as "inb", "outb", etc., which can only be executed by > the kernel and device drivers. Actually it's not quite as simple as that. It is possible for a MOV instruction to do something that would work in kernel mode, but not in user mode. E.g. if you were to use it to try and read a kernel mode device driver's data structures, you would be allowed to do that in kernel mode but not in user mode. The processor's memory management hardware keeps track of which memory is supposed to be accessible. The tables that hold this information can specify (amongst other things) different levels of allowable access to kernel and user mode. (Actually it's more complex than that - the Pentium has more privilege levels than just 'kernel' and 'user'. It also has support for per-process assignment of privileges through descriptor tables, although I'm not sure how many OSs use this - I believe that Windows actually uses the page tables to manage per-process privileges. At least that's how NT used to work - all of the supported processors had page table support, but only Intel CPUs had descriptor tables as well...) Just to complicate things further it *is* possible to allow user mode code to perform inb and outb instructions. By and large you wouldn't, but the Pentium does actually support this. (There are two aspects to this. The processor maintains an 'IO privilege level', which says who's allowed to do unrestricted IO. User mode code is not allowed unrestricted access to IO, but the OS can still grant access to specific IO ports if it wants to.) > User-level processes which want to do I/O will normally > invoke the kernel via a system call, and then the kernel > will execute the necessary priveleged instructions on > behalf of the user-level process. This is more or less true, it's just that it's not the *instructions* which are privileged, it's what they end up doing. (Although there are a handful of instructions which are privileged, e.g. the ones that let you modify the available privileges... But even device drivers don't normally need to use these - it's only very specialised parts of the OS itself that use them.) -- Ian Griffiths DevelopMentor
