Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!rice!uupsi!sunic!isgate!krafla!adamd From: adamd@rhi.hi.is (Adam David) Newsgroups: comp.os.minix Subject: Re: Message-ID: <3130@krafla.rhi.hi.is> Date: 12 May 91 22:45:28 GMT References: <9864@star.cs.vu.nl> <9911@star.cs.vu.nl> Organization: University of Iceland Lines: 48 In <9911@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article klamer@mi.eltn.utwente.nl (Klamer Schutte) writes: >>How about shared libraries? This will cut back the size of all executables. >Maybe yes, maybe no. I don't care about how big the programs are when they >are in memory. What I care about is how big they are on the distribution >disks. I care about program size on working disk(s) and in execution memory. Slight savings in distribution sizes can be had by compressing most of the executables on all but one of the minix disks, requiring them to be decompressed in order to make working copies. Some people may seriously disagree with the merits of this approach. The two greatest savings in code size are from using compression and shared code (libraries). Compressed executables: There are several possibilities, in the context of minix I believe the most convenient way of achieving this is by letting the FS unpack compressed executables on the way from disk to memory. There are savings in storage space and in load time from magnetic media. Files can be unpacked with very little overhead, it is compressing files that can take a relatively long time. To implement the loading of compressed executables it is necessary to identify such files for special treatment by the FS and build an unpack feature into the FS. This is certainly a better solution than self-unpacking executables, both in terms of compression ratio and purity. Shared libraries: This can be acheived by implementing a library call table in the kernel and/or MM. Each library call has a number associated with it which indexes into the table. Each table entry has two parts, a link count and a vector to the actual code. Library routines can then be linked in when needed and removed when all processes have unlinked from any particular routine. This requires a system call to handle all library calls. Programs can either declare in advance what library routines are needed (needs a linker-loader and routines are unlinked at termination time), or the routines can be linked in during the library call and linked out on exit from the library call (and if termination occurs during a library call). Library routines with a link count of zero can continue to reside in memory until the memory is required for other puposes, at which time the vector address can be zeroed to signify that the routine is no longer present. I don't know enough about the minix system to decide where to actually load the library routines, they could in principle use any available memory slots. Any program linked with libc.a will of course continue to function normally, it will just take more space than necessary. As for how practical or desireable any of this would be for minix I will wait and see what other people think before commenting further. -- Adam David. (adamd@rhi.hi.is)