Newsgroups: comp.os.minix
Path: utzoo!utgpu!watserv1!hbetel
From: hbetel@watserv1.waterloo.edu (Heather Betel)
Subject: Re: (shared libraries)
Message-ID: <1991May18.232615.9112@watserv1.waterloo.edu>
Summary: forget it!
Organization: University of Waterloo
References: <53470@nigel.ee.udel.edu> <3142@krafla.rhi.hi.is>
Date: Sat, 18 May 1991 23:26:15 GMT
Lines: 25

In article <3142@krafla.rhi.hi.is> adamd@rhi.hi.is (Adam David) writes:
>
>How about implementing a trap (680x0) or int (80x86) handler for the library
>calls. Those library calls which are used extensively, (for instance within
>the minix system itself) can be made resident (non-purgeable) and less used
>routines brought in as required. If the trap / int chosen is made to bypass
>message-passing altogether then the message overhead is kept reasonable, at
>least for those routines which don't need any intervention from the FS because
>they are permenantly resident or already present from a previous fetch.
>
	I don't understand this attitude. Part of the design
principles of minix is KISS (keep it simple, Stupid!)
	Take a good look at the kernel structure. he real kernel is
about 100 lines of source. It traps interrupts, and passes messages,
and chooses which process to run next. THAT IS VERY SIMPLE.
 	The rest are just processes. FS gets a simple message, and
sends out simple messages. When it gets all the needed replies, it
replies to the original message. SIMPLE. MM is not much different.
	All this avoids kernel bloat. Addind a "print formatted of
every imaginable data type" is the worst kernel bloat I have heard of.
It is worse than having 3 distinct ways of doing a
signal(signum,BLOCK) as in SUNOS. To sum it up, it is stupid. 
	That may sound harsh... Oh well.