Subject: SLS 1.05: Softlandings Modular Linux Released
From: [email-masked] (Peter MacDonald)
Date: Tue, 5 Apr 1994 00:16:32 GMT
Newsgroups: comp.os.linux.announce

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.

CDROM FEATURES:
----------------
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
PATTERN with:

    locate -d /a/cd/usr/lib/find.codes  PATTERN

Man pages are provided in both formatted and unformatted format.

1.05 SYNOPSIS:
--------------
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).

COPYRIGHT:
----------
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.

LOADABLE DEVICES:
-----------------
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 )
        fi

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.

PROC/DEV:
---------
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
dev collisions.

MODULE ARGUMENTS:
-----------------
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. 

BOOTSTRAP MODULES:
------------------
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.

	exc=module1,module2,...

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 

	exc=net_dev,dscsi

On the other hand, you can specify just the modules to include with:

	inc=module1,module2,...,moduleN

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:

	linux mod=DMA,NUM,debug

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).

	linux mod=512

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:

	linux mod=-1,1

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:

	linux mod=600,2

etc.  Note: DMA requiring modules must then be the FIRST modules loaded
after booting.

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
kernel.

USING IT:
---------
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.

FUTURES:
--------
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
in place.    

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:
-----
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 
current window.  

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.

MAN PAGES:
----------
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.

BUGS/WARNINGS:
--------------

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
stretch.

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.

 
AVAILABILITY:
-------------
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

    Softlanding Software
    PO Box 48054 - 3575 Douglas St, 
    Victoria, BC, Canada
    V8Z-7HS
    Phone (604) 592-0188 
    FAX (604) 595-5820

See Softlanding for a gentle touch down from a DOS bailout.