Xref: utzoo comp.unix.questions:26381 comp.unix.sysv386:1446
Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!mips!apple!portal!cup.portal.com!ts
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.unix.questions,comp.unix.sysv386
Subject: Re: Loadable device drivers...in V.4?
Message-ID: <35143@cup.portal.com>
Date: 22 Oct 90 07:08:51 GMT
References: <6681@suns302.cel.co.uk> <35110@cup.portal.com>
Organization: The Portal System (TM)
Lines: 27

I left a couple of things out in my description of how dynamically
loadable drivers in ISC 1.0.6 worked.

First, I forgot a system call.  There is a system call that the installer
program can make that tells the kernel to call the device initialization
code.

Second, I forgot to emphasize an important point.  Any such scheme should
be done in such a way as to require no modification of drivers.  You do
not want to get a situtation where you have two versions of a driver, one
for compiling into the kernel, and one for dynamic loading.

Third, our scheme did require that the kernel be built with extra
space in cdevsw, bdevsw, and whatever the one for streams modules
is called.

Fourth, I don't remember if we allowed a device to be loaded that
used a shared interrupt vector.  We may have been limited to devices
that don't share vectors.

The reason the install program copied things into /dev/kmem to modify
cdevsw or bdevsw, rather than having a system call to do this, which
would probably be cleaner, was political.  The less kernel changes that
are required to implement something, the better the chances of convincing
people to do it.

						Tim Smith