Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!phigate!prle!prles2!cstw163!meulenbr
From: meulenbr@cst.prl.philips.nl (Frans Meulenbroeks)
Newsgroups: comp.os.minix
Subject: Re: (shared libraries)
Message-ID: <meulenbr.674383161@cstw163>
Date: 16 May 91 08:39:21 GMT
References: <53470@nigel.ee.udel.edu> <3142@krafla.rhi.hi.is>
Sender: news@prles2.prl.philips.nl
Lines: 54

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 was thinking in the same line as Adam.
If all library functions which are called from kernel/fs/mm are
collected in one place (e.g. a lib component), and are callable the
same way a system call is performed (but perhaps by using a different
int/trap), a lot of code could be shared. It would not enlarge the
minix img, since all library code is already in there (but the code
would be moved to a different location).
minix.img might even become smaller because if the same subroutine
is called from both fs mm and kernel, it is only included once, instead
of three times.

The new user library call would be very simple. E.g. in 68000 assembler.
std_err:	move.w	STD_ERR_MAGIC,-(a7)
		trap LIBTRAP
where LIBTRAP contains the trap number to trap libraries. and
STD_ERR_MAGIC is the code for std_err.
If the magic numbers for the lib are into a table then
the trap handler could be quite easy:
	move.w (a7)+, a0
	shl	a0,2	! multipy by 4 to get word index
	move.l	table_base,a2
	adda.l	a0, a2
	jsr	(a2)
Of course this could be coded a lot smarter.

For functions without global variables this is very easy to implement.
For functions which use global variables, it is a little more complex,
but you could quite easily push the addresses of the global variables on
the stack and use them in the (modified) library routine.
The only place I can see which may cause problems is with functions with
variable argument list (read printf and friends).

I propose to put into such a common library all library functions which
are called from mm/fs/kernel/tools, and a few heavily used library
funcions (mainly some parts ofstdio and perhaps the string functions and malloc).

advantage:
smaller executables. Take up less space on disk and in core
disadvantage: a few additional instructions when doing a library call.

Does this sound ok?? Andy, would you adapt such a scheme??

--
Frans Meulenbroeks        (meulenbr@prl.philips.nl)
	Centre for Software Technology