23 Jun
2019
23 Jun
'19
10:08 p.m.
From: Andrew Warkentin
Mach and the other kernels influenced by it basically
destroyed the
reputation of microkernels ... a simple read() of a disk file, which is
a single kernel call on a monolithic kernel and usually two context
switches on QNX, takes at least 8 context switches - client->VFS->disk
FS->partition driver->disk driver and back again).
Hammer-nail syndrome.
When the only tool you have for creating separate subsystems is processes, you
wind up with a lot of processes. Who'd a thunk it.
A system with a segmented memory which allows subroutine calls from one subsystem
to another will have a lot less overhead. It does take hardware support to be
really efficient, though. The x86 processors had that support, until Intel dropped
it from the latest ones because nobody used it.
Excuse me while I go bang my head on a very hard wall until the pain stops.
Noel
23 Jun
23 Jun
11:54 p.m.
New subject: CMU Mach sources?
On Sun, Jun 23, 2019 at 06:08:56PM -0400, Noel Chiappa wrote:
Hammer-nail syndrome.
When the only tool you have for creating separate subsystems is processes, you
wind up with a lot of processes. Who'd a thunk it.
A system with a segmented memory which allows subroutine calls from one subsystem
to another will have a lot less overhead. It does take hardware support to be
really efficient, though. The x86 processors had that support, until Intel dropped
it from the latest ones because nobody used it.
One of the real problems with how x86 implemented segments was that
the segments were layered on top of the 32-bit virtual address space
implemented by the page tables. So if you wanted to use a pure
segmented architecture, ala Multics, you run into the same problem as
32-bit IP addresses. If you need to allow for segments to grow, you
very quickly fragment the 32-bit address space.
If I recall correctly, this wasn't an issue with Multics because the
DPS-8 had page tables for each segment.
Maybe if Intel/AMD had kept segmentation support when x86_64 was
developed, trying to do something more novel with segments could have
worked when we went to 64-bits (or maybe, like IPv6, what's really
needed is 128-bits of address space :-P). But, Itanic was supposed to
be the dominant 64-bit architecture that was going to take over the
whole world, and when that turned out not to be the case, AMD threw
together x86_64 as the "just good enough" architectural extension.
- Ted
24 Jun
24 Jun
5:04 p.m.
New subject: CMU Mach sources?
So with that Mt Xinu Mach/386 thing I thought I’d take another stab at building the source
from the CSRG CD-ROM set.
The makefiles from the i386 version are so cut up it’s a seemingly hopeless mess. I took
the mach.kernel.mk directory and tried to build of 4.3BSD UWisc, but that went nowhere
quick as the tool chain just isn’t right and there is a bunch of VAX stuff missing. It
looks more complete for the SUN-3.
So in a fit of rage, I copied the bare needed i386 files into the SUN-3 tree and it
actually compiles.
ROUGH notes….
Mach25 is where I put the 386 directory & running from inside the mach.kernel.mk
directory.
mv ../mach25/sys/i386 .
mv ../mach25/sys/i386at .
mv ../mach25/sys/mach/i386 mach
mv ../mach25/sys/sysV .
cp ../mach25/sys/conf/*i386* conf
ln -s i386 machine
ln -s mach/i386 mach/machine
cp Makeconf Makeconf-orig
vi Makeconf
------
bash$ diff Makeconf-orig Makeconf
85c85,86
< CONFIG = ${${TARGET_MACHINE}_CONFIG?${${TARGET_MACHINE}_CONFIG}:STD+ANY+EXP}
---
#CONFIG =
${${TARGET_MACHINE}_CONFIG?${${TARGET_MACHINE}_CONFIG}:STD+ANY+EXP}
CONFIG = STD+WS-afs-nfs
89a91
#SOURCEDIR = /usr/src/mach.kernel.mk
91c93,95
< OBJECTDIR = ../../../obj/@sys/kernel/${KERNEL_SERIES}
---
#OBJECTDIR =
../../../obj/@sys/kernel/${KERNEL_SERIES}
#OBJECTDIR = /usr/src/mach.kernel.mk/obj
OBJECTDIR = ./obj
------
vi Makefile
include ../../${MAKETOP}Makefile-common
to
include ${MAKETOP}Makefile-common
vi src/config/Makefile
include ../../${MAKETOP}Makefile-common
to
include ${MAKETOP}Makefile-common
mkdir obj
make
And it actually compiled…
cc -c -O -MD -I. -I../../sys -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL
-fno-function-cse ../../i386at/pic_isa.c; ; ;
cc -c -O -MD -I. -I../../sys -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL
-fno-function-cse ../../i386at/rtc.c; ; ;
cc -c -O -MD -I. -I../../sys -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL
-fno-function-cse ../../i386at/wt.c; ; ;
cc -c -O -MD -I. -I../../sys -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL
-fno-function-cse ../../machine/swapgeneric.c
(null command)
(null command)
(null command)
loading vmunix.sys
rearranging symbols
text data bss dec hex
479200 47980 125520 652700 9f59c
ln vmunix.sys vmunix
md -f -d `ls *.d`
ln -s STD+WS-afs-nfs/vmunix KERNEL.STD+WS-afs-nfs
Naturally the Mt Xinu bootloader won’t run it.
479200+47980+125520[+40968+42516]
That’s all I get out of it. I’ll have to mess with it later on as it’s getting late, but
I thought it was worth sharing.
1773
days inactive
1774
days old
2 comments
3 participants
participants (3)
-
Jason Stevens -
jnc＠mercury.lcs.mit.edu -
Theodore Ts'o