Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.misc Subject: Re: Multics bloat??? Are you sure??? Message-ID: <1990Dec7.190739.26331@Think.COM> Date: 7 Dec 90 19:07:39 GMT References: <90@ <6100008@m.cs.uiuc.edu> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 50 In article <6100008@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes: >Mutlics segments are/were limited to 262K (or less, I don't remember >exactly). Systems like 4.3BSD and System 5.0 move beyond these >PDP-11ish limitations into the modern world, where files can be 20 >megabytes and filesystems can have 100,000 inodes or more, filenames >can be arbitrary length, etc. etc. etc. If you had to use Multics >today you'd be screaming in pain due to the hardwired limitations. While Multics segments are limited to 255K (that's words, so it's almost 1Mb), there is a library routine that supports treating specially-marked directories as a single file constructed of all the segments in the directory; this is called a Multi-Segment File, and the msf_manager_ library is pretty straightforward to use (it can be used to access ordinary segments as well, and will automatically convert them to MSFs when necessary). Additionally, the I/O library interface to files (the Multics equivalents of Unix open/read/write) uses msf_manager_, so it will transparently support huge files. I think an MSF can conceivable grow to a few gigabytes, if you've configured the disk with enough inodes. When the Multics C compiler was implemented we even taught the compilers and dynamic linker how to deal with multi-segment executable files (it support static linking of C programs, to deal with namespace collision problems, and this tends to bloat the executables beyond a megabyte). MSFs can be considered analogous to Unix indirect blocks. The difference is that Multics puts this functionality in a user-ring library (since Multics has been doing dynamic linking and shared libraries since day 1, libraries are cheap), to keep the kernel interface simple. So whose kernel is bloated? The Multics kernel is amazingly simple and pure compared to modern Unix kernels, although not quite as pure as some recent alternate kernels such as Mach. Very little is in there unless it *has* to be there. The one glaring exception is the terminal driver, which would make the BSD terminal driver look simple, yet doesn't do many of the things most other terminal drivers do (e.g. it doesn't have a settable interrupt character -- it's hardwired to the BREAK signal); however, when video terminals became popular a user-ring replacement was developed to support them (it supports programmable input editing a la Emacs, input line recall (like some Unix shells, but in effect for all programs, not just the shell), automatic output paging, etc.). Unix is slowly working its way towards the elegance of Multics. The System V streams mechanism is a good step (it's similar to the Multics I/O module mechanism, except that Multics does it in the user ring), and some flavors of Unix now have dynamic linking. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar