From: pmacdona@sol.UVic.CA (Peter MacDonald)
Subject: SLS 1.05: Softlandings Modular Linux Released
Date: Tue, 5 Apr 1994 00:16:32 GMT
Approved: email@example.com (Matt Welsh)
SLS 1.05 RELEASE ANNOUNCEMENT:
Announcing, the official of the release of SLS 1.05, the Softlanding
(Modularized) Linux System. It is a joint announcement of the release
of the SLS 1.05, the CD and the kernel modularization patches.
Modularization of the kernel is aimed squarely at reducing,
and eventually eliminating the requirement to recompile the kernel,
either for changing/modifying device drivers or for dynamic access to
infrequently required drivers. More importantly, perhaps, the efforts
of individual working groups need no longer affect the development
of the kernel proper. In fact, a binary release of the official kernel
should now be possible.
SLS 1.05 is available for ftp'ing from tsx-11.mit.edu. Additionally, the CD
version or floppy or tape distributions can be obtained from Softlanding Software
(see below for more info). The CD will begin shipping shortly so all Quarterly
subscribers should be receiving their next installment in the next few weeks.
SLS 1.05 FEATURES:
- The Linux kernel 1.0, fully modularized by Softlanding (totalling 63 modules).
- Nearly everything is loadable (devices, fs's, network, math, etc)
- Many extra loadable modules included (IFS, Double FS, IPX, CD, ...).
- A powerful, flexible menu shell (Mesh) written for SLS system admin.
- A massive shift to Tcl and Tk apps (like Picasso and XTeXShell).
- Idraw and Doc (Interviews) are gone, so is clisp.
- Elvis has been supersceded by VIM (which has help and no refresh bug).
- Addition of two new shells: tcsh and pdksh. Added Pine as well as elm.
- man pages are not preformatted, so as to support Tkman (and printing).
- XFree86 2.0, with modified Servers link kit to allow compileless link.
- Most binaries updated and libreadline in ftp, bash, the wish shells...
- migration to linux-utils 1.5, with modifications to add shadow support.
- adoption of /sbin, for that leaner, cleaner /etc look (see below).
- Non-destructive installation option (over existing ext2 fs partitions).
- Holes are now automatically compressed on install, for "ALL" files.
- Network/CD/HD installs now try to do the mount, "before" doing a mke2fs.
- Unavoidably, one disk has been added (to 'b') giving 31-5.25 or 26-3.5.
The CDROM has the following additional features:
- no binaries are located in /etc.
- preceding means SLS runs from CD in 400K+ ramdisk (for /etc, /tmp, ...)
- Linux source tree with all .o's intact for quick driver mods.
- XFree86 2.1 in addition to 2.0
- Contains Andrew, Interviews, Object Builder, etc.
- Includes mainstream packages such as mosaic, gopher, archie, etc.
- Contains both X and non-X versions of most programs.
- A large repository of Tcl/Tk code (most all that is available?).
- Contains about twice the source code of the previous release (compressed).
Installation options include:
- Install directly from CDROM
- Install from CD, over the network (3 1/2 boot only)
- Install from harddrive, over the network (3 1/2 boot only)
- Copy the /install packages to a DOS hard drive for installation
- Copy the /install packages to a DOS floppies (both 3.5 and 5.25)
- tar the /install packages to Tape for installation
Operational modes for the CD include:
1) run from CD, with no writable file space
2) run from CD, with a small (600K+) ramdisk
3) run from CD, with a partition mounted on /local
4) run with installation ramdisk as root and mounting CD on /mnt
5) run with mini install (~15 Meg) and mounting CD on /mnt
6) run with mini install and NFS mounting remote CD on /mnt
7) run with mini install and NFS mounting remote SLS on /mnt
Note that options 1), 2) and 4) can be used on machines with no harddrive.
Also, with the introduction of the loadable ramdisk, option 1) can be
converted into option 2) anytime after bootup, by running "MakeRamDisk".
Running from CD, even on diskless machines, is now very practical, because
the directories that contain config files are now all contained on a single
mount point to either a ramdisk, floppy or regular disk.
Unlike the previous SLS CD's, the sources have grown in volume to the point where
they must now be distributed as compressed tar archives, in order to fit them all
onto the CDROM.
"updatedb" has been run on the CD, so any file on the CD can be located in seconds
using the "locate" command. From the hard drive you can locate any file containing
locate -d /a/cd/usr/lib/find.codes PATTERN
Man pages are provided in both formatted and unformatted format.
The primary feature of this release is Linux 1.0 modified to convert nearly all
Linux devices and facilities into loadable modules. It is hoped that eventually
this will cause the number of kernel patches to diminish, and the current kernel
to be split into two pieces: kernel proper and kernel modules. Perhaps an API
can even be evolved to reduce dependancies on kernel data structures.
Following is a condensed list of the 63 or so modules that have resulted from the
SLS kernel modularization:
at1700 atixlmouse atp ax25 binfmt_coff binfmt_elf busmouse cdu31a
cdu535 d_link dble dscsi dsd dsg dsr dst el1 el3 el7 el9 ext ext2
fdomain floppy g_NCR5380 hp hpfs_fs ifs inet ipx isofs lance lmscd
lp math mcd minix msbusmouse msdos ne net_dev nfs panasonic pas16
proc procdev psaux quota ramdisk sbpcd seagate slippp sound sysv
t128 tpqic02 ultra ultrastor unix wd wd7000 xd xiafs
Central to the feasibility of a modularized kernel is our bootstrap loader
which allows bundling modules up into a kernel image permitting even disk drivers
to be modularized. This bootloader was implemented as an extension to insmod.
There is now only one kernel image: the one on the bootdisk. The kernel on
the 3 1/2 is identical to the 5 1/4 except that it bootloads the network and NFS
code. But since the Net code is loaded, the only difference is that you have
to manually load the network after bootup, if you do an installation from 5 1/4's.
Likewise, the 3 1/2 zImage is identical to the 5 1/4 if it is started with the
lilo option "exc=unix,net_dev" (see below for details).
As with virtual consoles, ptys, shared libs and other Softlanding contributions,
these kernel patches are covered by the same GPL copyright as Linux. Please
refer to /usr/src/linux/COPYING for details. Programs/packages in SLS are
copyrighted by their respective authors. In all cases, to the best of our
knowledge, "we think" none of these restrict commercial redistribution,
provided you observe GNU like redistribution policies. SLS system admin
and system install specifics, other than the above, are copyright Softlanding
Software, whose copyright is the same as GPL, except that you can not rename
SLS (say by creating a new distribution using SLS sysadm) without permission.
Redistribution, for any other purpose whatsoever is hereby granted.
Virtually everything that is not part of the intrinsic kernel logic in
SLS has now been made loadable. As well as regular devices, such as CD's,
parallel ports and mice, all of file systems are now loadable.
Ditto for networking code. The unix domain sockets are loadable
(perhaps only useful for development). Individual protocols such as IPX and
AX25 are now also loadable. So also is the sound code, the Elf and Coff
binary formats and the math emulator. The ramdisk is also loadable and
unloadable, and so can have it's size set at runtime. Even things you
might not consider candidates for loading, like quotas for example, are.
So you must load the quota's module first, in order to use quotas.
The SCSI devices have also been made loadable, but since SCSI has
both low and high level drivers, the concept of composite modules is
introduced. Composite modules simply permit a module to add symbols
to the kernel symbols list that is exported for module linking. In the case
of SCSI, first the generic SCSI code is loaded. Then the low-level (board/
controller) drivers are loaded. Lastly are the high-level (tape/disk/CD)
drivers. The last high-level driver loaded is passed an argument telling it
that it is last, and so to initialize the scsi subsystem. Failure to detect
a board, causes all scsi modules to be deleted.
BOOTTIME MODULE LOADING:
The other major piece to the puzzle was a bootstrap loader for linux modules,
to allows modules to be bundled with a boot image. In essence, the bootstrap
loader piggybacks a collection of modules onto the end of the kernel
image before it is compressed. At boot time, the modules are initialized
and autodetected as usual. In all cases, if prerequisites are not detected
at boottime, the module is unloaded, freeing it's memory and resources.
For math.o for example, this means that autodetection of a coprocessor
automatically unloads the math emulation software.
A side benefit of boottime loading is that the call to xxx_setup() does not
Result in a kernel patch to init/main.c, because the module loader automatically
senses the presence of the xxx_setup() routine and calls it for you with
any commandline arguments from the lilo prompt.
POSTBOOT MODULE LOADING:
Some drivers, such as disk controller code, need to be loaded at
boottime, but others, such as Network code can be loaded after bootup.
To have the modules loaded automatically for you, you could just do
something like the following: move or copy the desired modules from
the source tree, or from /install/modules/src to /install/modules/
The following lines, which have been added to the top of /etc/rc.local
will auto load them for you.
if [ -d /install/modules -a -d /proc/dev ]; then
(cd /install/modules; for i in *.o; do insmod $i; done )
Interestingly, object files that are loadable modules are no different
than ordinary .o's in that they can still be statically linked. When
using "make config" on the Linux kernel, there are now four options:
include, exclude, loadable and boot-loadable. You can identify
loadable modules in "make config" by a "*" in the first column.
Selecting 'l' instead of 'y' or 'n' makes the module loadable.
Selecting 'm' cause the module to be loaded at boottime before
the root fs is mounted.
Implementation-wise, loadable modules use the same .o files that the
kernel links in. There is no need to recompile the module if you decide
to statically link it, rather than load it. See below for more details.
One other thing that this release adds is optional support for /proc/dev.
The purpose of /proc/dev is to allow the kernel to report which
devices it presently considers valid. Currently, the device reporting
is not yet very accurate, so it is not compiled in by default, but eventually
this feature could be used by configuration software, in setting up the system,
and in particular, the /dev directory as in AIX. However, the main benefit
lies in the dynamic allocation of major or minor device numbers, of which the
former are in short supply. A dynamic scheme could have the module loader
create the requisite /dev entries. This would also help developers avoid
The insmod.c code has also been modified to allow passing arguments to modules
using the -a option. This is used by such modules as ramdisk.o, to allow setting
the ramdisk size, so a ramdisk can be created and destroyed at any time.
Currently, the size can be changed without rebooting by unloading and
reloading with a different value. 4096 (4Meg) is the current maximum.
There is also a -f option, to force loading even if the version of
the module does not match the kernel version.
It became necessary to modify the compressed-image bootup code, because
there was no longer room in the < 640K area for the compressed kernel
and the gzip code to run. So now the kernel is moved to just below
the 2Meg mark before decompression, and the uncompressing data
chases the compressed data boundary.
CONFIGURATION VIA LILO:
A few simple options are currently supported with lilo, to control which
the handling of bootstrap loaded modules. The first, the exclude option
causes the named modules to be *not* loaded or autodetected.
causes the modules to be disabled and discarded. Since composite module
members are checked at load time to ensure that dependant
modules are already loaded, you can disable whole hierarchies of
modules with a single statement. For example to disable
all scsi and all network devices in one fell swoop use
On the other hand, you can specify just the modules to include with:
This does the opposite of above. Only the modules listed are autodetected.
This can limit the sometimes lengthy autodetection sequence to just the
installation bootup, After which, bootup should be as fast as a custom compiled
kernel. The intent is clearly to reduce, and perhaps someday eliminate, the need
for most people to compile the kernel. Another benefit is that autodetection
causes some machines to lockup at boottime. This provides a dynamic way
to selectively disable modules.
DMA MEMORY ISSUES:
One undesirable feature of current Linux device drivers is that they are
allowed to do memory math at init time to allocate themselves some memory.
For a few devices (basically only the sound and qic02tape), they
require memory that has the same physical and logical address for DMA.
The rest can just use the normal memory allocation of the kernel.
To this end I have changed all devices to use a dalloc() call instead
of memory math. These currently provide roughly the same functionality as the
current kernel, but allow for all devices to be loadable as modules.
There is also a dmamalloc() call for Tape and Sound, as there has to be a
block of contiguous memory to allocate for the device when it is loaded.
To control this behaviour, you can use the "mod=" option, whose syntax is:
DMA is the amount of dma ram to set aside, NUM is the number of modules
you wish to load after boottime before ram is released, and debug gives
a verbose printout of the sequence of module initialization.
The following statement at the lilo prompt, sets aside the specified
amount of memory for boot load modules (from the default of about 256K).
This reserves 512K of ram for modules at boottime.
Again, the memory is called dma memory because
this type of memory allocation is the only kind that can
be used for dma (memory_start math). kmalloc will not work.
Normally, any unused portion of the above memory is released by the time
init is called, right after bootup. However, if one wishes to load
the qic02tape driver or the sound driver after bootup (the only option
without recompiling as they are not part of the default kernel),
an additional step is required:
This tells the kernel to not release the unused dma memory after bootup
but instead allow you to load '1' module before releasing unsed ram.
If you want the tape driver as well, and allow for extra ram you would use:
etc. Note: DMA requiring modules must then be the FIRST modules loaded
While the preceding may seem somewhat contrived, there may not be a general
solution to the problem of allocating a chunk of DMA ram at any arbitrary time
without a reboot. Of course, I would be delighted to be proved wrong, but until
then, if you need these devices, the best way may be to compile them into the
Normally to use a module you "insmod" it. To have it done at boottime
for you automatically, you just move or copy it into /install/modules.
If you still want to rebuild the kernel, you will need to ensure that you
have installed the accompanying module utilities: insmod, rmmod and lsmod.
Do a make config as usual, but type 'm' for to bootload a module, or
'l' to have it compiled but not loaded. Then do a 'make dep' as usual.
Then type "make mImage". This will make "mImage" which you can boot exactly
the same as zImage. After booting, do "lsmod" to see the loaded modules.
In later builds, you can control exactly which modules are loaded into the
bootstrap, by editing .config, and thus avoid the lengthy make config.
Normal builds without modules are supported as usual.
The sound code, although loadable, needs to be modified to
allow loading individual low-level (board) drivers. Since it also has
DMA complications, this was not done for SLS. Sound can really only be
loaded at boottime, or by using the "mod=" lilo option, because it
needs 1:1 mapped memory for dma.
The console, keyboard and serial code (and ipc?) could also be made
loadable. Payback is minimal, unless Linux is used in imbedded systems.
Better detection of when modules are busy, and hence unloadable, should
also be added.
A (much) better configuration control mechanism should be put
Better memory management could be used, say removing
the restriction of aligning modules on page boundaries.
In a typical non-SCSI installation of about 10 modules,
this could save about 20K (assuming 1/2 page per module).
For the bootstrap-loader, rather than add linker logic code to the kernel,
the fixup has been done at compile time (using a modified insmod.c
from the module package). Perhaps in later implementations this will change,
because modules this causes modules to be bigger at boottime. It might be
necessary to save room in the boot image as the kernel and or disk modules
continues to grow.
Future implementations might include auto loading of devices upon open
(demand loading) and unloading when idle.
The option to install on an existing partition is really designed
to allow installation on systems with a big partition
HOW TO MODULARIZE A DRIVER:
The first requirement to make module foo.o a module, is that it have
two functions foo_init() and foo_cleanup(). There must also be the following:
#include < linux/module.h>
char foo_version = UTS_RELEASE;
Finally, memory allocation should not use memory math on mem_start, but
should rather use dmalloc() etc, as defined in module.c. Simple huh.
Oh, and if you want to pass arguments at init time. there should also
be a foo_setup(). Using "insmod -a N module.o" will pass argument N
to the module. Currently, only integers are supported.
Lastly, if you get an undefined symbol when trying to load a module, it
means that you need to add it to kernel/ksyms.S.
Mesh, the Softlanding MEnu SHell, is a cross between a menu system,
a file browser and a (somewhat bash-like) shell. It is also designed to
serve as the front end to a system administration program, under development.
Mesh is designed to reduce the number of keystrokes and be easy to learn.
Any normal unix command can be executed from the mesh command line.
The current file name can also be referenced by the first %s in the command line.
The second %s refers to the destination (other) window, and the third %s, the
Additionally, Mesh displays menu items at the bottom of the screen, which can
be selected using the Alt-X command, where X is substituted with the first capital
letter in the menu title string. Mesh also has popup lists which can be cursored
through, or shortcutted by just typing the letter that is capitalized in the label.
Mesh doesn't actually have any built in menu items. Rather menus are defined
in /etc/meshrc, ~/.meshrc, and/or are specified with the -menu argument.
At any time, you can use Alt-Z to return to the top level menu. Other behaviour of
note includes: When you just hit enter at a file, the default action is executed.
The default action is based upon the
file suffix as defined by the Suffix settings in .meshrc. Note that if no extension
is matched, the last defined Suffix entry gets used, usually the program "less".
When you hit enter the first match is executed. Or, Typing just the command '1'
causes it to skip the first match. '2' skips the first 2 matches etc.
Note that control-k is considered a shortcut for '1', or skip 1.
In all cases, failure to match causes the last or default Suffix command
to be executed. Additionally, if a file is executable, and it has no extension
matching default rule, then you can execute it with control-k. You can see what
suffix defaults the current file matches using the .Setup.Keys command.
Powerful as it is, Mesh is soon to be overhauled to use Tcl, for greater
flexibility, configurability, and generality.
The change of direction of not preformatting the man pages has come about
primarily for two reasons. First and foremost, Tkman an X based manual page
reader that now comes with SLS requires unformatted pages to work properly.
This reader which offers hypertext, section parsing, history and much more
makes reading man pages a real joy compared to the old more or less approach.
It would also be nice to see a text based version of this reader RSN.
Secondly, numerous people pointed out that trying to print preformatted
man pages caused most printers to complain (well barf actually).
And even if you got it to work, it looked lousy. All you got was typewriter
font, and all the page numbers didn't line up on page boundries, etc, etc.
Anyways, formatting usually takes only a second or two on most machines.
Unloading modules is currently not guarrented to clean up everything properly
for all devices. Individual drivers need perhaps more attention.
The source to picasso has been included because it has a fair bit of C++
code, and because there is a bug under Linux/Tk with image rotate and
The compiler must be installed in order to use X-windows, in order to link
the X servers. This saves around 3 Meg in the distribution.
The option to install on an existing partition is really designed
to allow installation on systems with a big partition containing
data (like /home) that should be preserved.
SLS is available on floppies (31 5.25 floppies or 26 3.5 floppies), QIC150 or
CDROM from the address below for a flat rate distribution fee of US $99
($125 Canadian) + $15 shipping and handling. Mail payment, either
cheque or money order, in advance, to Softlanding. Visa and Mastercard
are also accepted.
The SLS CDROM contains the full source tree and a 60+ page user manual
"Using SLS". A quarterly CD (4 CD's over 1 year) is available for US $199
(255 Canadian) + $15 S&H. Quantity discounts are also available for resellers.
When ordering floppies, ensure that you specify the bootdisk type (3 1/2 or 5 1/4).
Softlanding also offers support subscriptions for SLS as follows:
Individual support, (one user, one machine) is $99 per year.
Group support, primarily for resellers and reseller/corporate, $999 per
PO Box 48054 - 3575 Douglas St,
Victoria, BC, Canada
Phone (604) 592-0188
FAX (604) 595-5820
See Softlanding for a gentle touch down from a DOS bailout.
From: pmacdona@sol.UVic.CA (Peter MacDonald)
Subject: SLS 1.05: update/patch
Date: Wed, 13 Apr 1994 16:33:55 GMT
Approved: firstname.lastname@example.org (Matt Welsh)
The following update is to SLS 1.05, which was released about
a week ago:
There are two new SLS bootdisks on tsx-11.mit.edu. They incorporate
patches (which you can also find at the end of this note). These
should fix the problems that some have been seeing with either hanging
at boot-time, or other seemingly random behavior that occur only on
certain hardware configurations.
Note: Due to the nature of the fixes, you should probably update your
bootdisk to get the new kernel, *EVEN* if you do not see any problem with
the current kernel. And you should get and apply the patch at bottom
to the source. If you don't, some lurking nasty may one day bite you.
A1 (5 INCH):
There is also a fix for the broken a1.5 which after updating e2fsck now/needs
ld.so. This was not detected because ld.so on the floppy was a link to ld.so on
the SLS CD against which test installs were done against. Room was made for
ld.so on a1.5 by dropping out the CD drivers from the floppy. But since
there was a little room left over, the unix sockets were added back in,
and so do not have to be loaded in rc anymore. This latter is just a
convenience. I am looking at making the 3.5 inch version of the release
available on tsx in soft-link format.
Again, because of the above fixes, you should get the new modules
unless you plan to build the kernel yourself (which at this stage
may not be a bad idea).
Note that both su and in.ftpd did not get support for shadow compiled into
them. I am working on fixing that, but in the meantime you should know
Shadow support is completely optional in SLS. To disable it, just rename
/etc/shadow to something else. If you do so, make sure you use the "passwd"
program to set passwords for at least root. The passwd program has been
modified to look for /etc/shadow, and if not found assume that you do not
want them. The shadow support SLS added to util-linux is such that
shadow aware binaries automatically adapt to either mode.
Also, not that a couple of permissions did not get set correctly. Just do
the following to correct rsh/rlogin not working for non-root:
chmod a+x,u+s /usr/bin/rlogin /usr/bin/rsh
If you do find a problem, particularly a kernel problem regarding modules,
you shouldn't assume someone else has reported. Please let me know.
Given the traffic on the news groups, it is better to send me mail at:
Mail submissions for comp.os.linux.announce to: email@example.com
Be sure to include Keywords: and a short description of your software.