Loadable device drivers...in V.4?

ian reid ir at cel.co.uk
Sat Oct 20 00:54:35 AEST 1990


Now with the move to make UNIX a truly shrink wrapped product it would
be nice for certain things which MS-DOS users have taken for granted to be
incorporated into V.4.  The following comments are certainly true for V3.2 and
as far as I am aware for V.4, please correct me if I am wrong.

I am specifically thinking of loadable device drivers.  Now I am not pretending
that config.sys doesn't cause users a great deal of pain and heartache, but
when you consider the inconvenience a UNIX user is put to achieve this task
the point becomes valid.  These inconveniences are:-

1) The user must have the kernel configuration subset loaded, taking up valuable
disk space on the users disk, causing vendors to distribute systems on a lot of
media, and requiring a lot of installation time.

2) The kernel must be rebuilt and reinstalled, which takes a lot of time.

3) Even a simple changing of a kernel parameter variable requires a kernel 
rebuild and re-installation.

But what if we lived in a world where there was one generic kernel.  The kernel
would provide all the device independent facilities.  All device drivers would
be loaded at run-time by the kernel.  Space for system buffers would be 
dynamically allocated at run-time by the kernel by reading its mtune file.  The 
question is how would this process be managed.

The framework is already in place.  All drivers are described by the various 
mdevice, sdevice files.  All kernel parameters are described by the mtune
and stune files.  When a new driver was added to the system the new files would 
be added in the usual way, with checks for interrupt conflicts etc, only a 
kernel build and installation would not be needed.  The drivers themselves would
be built as some form of shared library.

This must all be possible, as SunOS4.0-> already has something similar (I am not
familiar with details).  So does V.4 have this facility or something similar or 
is it planned to add such a facility in the future.

-- 
Ian



More information about the Comp.unix.sysv386 mailing list