Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!spool.mu.edu!think.com!cass.ma02.bull.com!mips2!bull.bull.fr!corton!mcsun!hp4nl!star.cs.vu.nl!jms
From: jms@cs.vu.nl (Jan-Mark)
Newsgroups: comp.os.minix
Subject: Re: <minix/minlib.h>
Message-ID: <9916@star.cs.vu.nl>
Date: 12 May 91 15:38:06 GMT
References: <9864@star.cs.vu.nl> <klamer.673867917@mi.eltn.utwente.nl> <9911@star.cs.vu.nl> <1991May12.001703.11152@syd.dit.CSIRO.AU>
Sender: news@cs.vu.nl
Reply-To: jms@cs.vu.nl (Jan-Mark Wams)
Organization: VU Dept. of Computer Science, Amsterdam, The Netherlands
Lines: 32

In article <1991May12.001703.11152@syd.dit.CSIRO.AU>,
	evans@syd.dit.CSIRO.AU (Bruce.Evans) writes:
> 
> It would be sufficient to put only stdio and everything it references in
> the shared library. Anyway my current libc.a is only 47K text for the 386
> version compiled by gcc. The data space should be close to 0 once the
> library is made sharable (few globals).
> 
> Complexity is the main problem.
> -- 
> Bruce Evans		evans@syd.dit.csiro.au

	I do agree that some functions should be in a shared library,
	and some should not, but where IS the complexity, mentioned?
	(Kernel patches?) IMHO globals like ``errno'' and the
	environment pointer should create big problems. The compiler
	will have to do magic there. (Like putting them in a known
	place.) The kernel should only need a new system call.  (eg.
	``slibcall (int num);'') The kernel could send a message to a
	SLIB task, that will change the CS,SP and IP. (or 386, 68k,
	sparc equivalents.) The process can than be put back in the
	process queue (The function arguments will still be on the stack
	from the function call.) Upon return from the call, the CS,SP
	and IP are changed again. Are there any pitfalls here I've
	missed? 

	Jan-Mark.
--

				 (:>	jms
				(_)
			========""======