Messages in this thread |  | | Date | Tue, 10 Jul 2001 14:14:38 -0500 (EST) | From | "Mark H. Wood" <> |
| |
On Tue, 10 Jul 2001, Jesse Pollard wrote: > "Richard B. Johnson" <root@chaos.analogic.com> [snip] > > Unlike some OS (like VMS), a context-switch does not occur > > when the kernel provides services for the calling task. > > Therefore, it was most reasonable to have the kernel exist within > > each tasks address space. With modern processors, it doesn't make > > very much difference, you could have user space start at virtual > > address 0 and extend to virtual address 0xffffffff. However, this would > > not be Unix. It would also force the kernel to use additional > > CPU cycles when addressing a tasks virtual address space, > > i.e., when data are copied to/from user to kernel space. > > I believe the VAX/VMS implementation shared OS and user space: > > p0 - user application 0 > p1 - system shared libraries 0x3fffffff > p2 - kernel 0x7fffffff > rest was I/O, cache memory 0xffffffff > > It was a hardware design, not a function of the software.
Correct, except that "p2" is called S0. IIRC it is the top quarter of the address space, and there's a reserved S1 region. The command interpreter is also mapped into P2. The very top of memory is reserved for device registers.
> UNIX origins were on a PDP-11. there were two sets of addressing registers > 1 kernel, 1 user (except on 11/45 - 1 kernel, 1 user, 1 "executive" > (never used except in some really strange form of extented shared library)
Early '11s didn't have the Ispace/Dspace split. My PDP11 databook is at home, and I don't trust my memory far enough to say which model introduced the split. My recollection is that the earliest implementation was an add-on board which monitored the Unibus address lines and fired interrupts when it thought its programmed memory access rules were violated.
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu Make a good day.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |