NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/os/linux/9800

Internet Message Format | 1992-09-03 | 4.8 KB

Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsm!cbnewsl!att-out!rutgers!psinntp!psinntp!pool!ujlh
From: [e-mail] (James Henrickson)
Newsgroups: comp.os.linux
Subject: Loadable device drivers for Linux [Was: Re: GNU kids on the block?]
Keywords: Linux, Mach, CISC, RISC
Message-ID: <[e-mail]>
Date: 2 Sep 92 17:28:02 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: State University of New York -- Institute of Technology
Lines: 96

In article <[e-mail]> [e-mail] (Rajat Datta) writes:
>
>Actually, AIX has loadable device-drivers and loadable kernel
>extensions.  And AIX is certainly not anything like a micro-kernel.
>
>I think you're absolutely right about loadable device-drivers, and in
>fact, they make more sense on the PC class machines than on ones that
>run VMS.  There is a far greater variety of devices available for PCs
>and the resources available (memory) is usually much less.  A fat
>kernel with every likely device driver can be tolerated better on
>systems with 64Mbyte plus systems than on our "poor" machines with
>8Mbytes and often less.

We often discuss the idea of loadable device drivers, and they
usually end up showing that loadable device drivers are wanted.
I think it would be productive to discuss the implementation
of loadable device drivers, so I'll start with what I think is
a relatively simple implementation.  Note that I am not as familiar
with Linux internals as some other people, so please correct any
areas where my idea is weak.  I feel that an open discussion could
result in a reasonable implementation, with fewer trial-and-error
pains than are usually encountered when one or a few people attempt
such a feat.

PHASE 1:
--------

What if we just started with a dynamic boundary for the real memory
used by the kernel?  Device drivers could be located at the end of
the kernel where they would be easier to locate and add/remove.
Adding a driver would involve moving this "boundary" and remapping
a few pages for the user processes that were using this area
of memory.  Adding such a feature shouldn't be difficult to debug,
after which we could work a little more on loadable drivers.

The code for the various file systems could reside in this area,
and always exist at boot time to facilitate mounting the root
file system (which ever type it may happen to be).

Phase 1 would only involve the relocation of drivers and
implementation of dynamic boundaries, so we can attempt to
isolate any bugs before we get very far.

PHASE 2:
--------

A system call could be added to add/remove a device driver.
Two programs can be written to dynamically load/unload drivers by
using this system call.  Lines could be added to /etc/rc to load
frequently-used drivers and to unload rarely-used drivers.  Perhaps
these frequently-used drivers should be tagged with a "lock in
memory" bit?  This "lock in memory" bit could prevent automatic
unloading of unused drivers (like when unmounting a file system)
but still allow them to be manually unloaded using the "unload"
program.  This gives the system administrator the ability to
maximize performance by eliminating the overhead involved in having
to reload a device driver each time a file system is mounted.

Loading a new driver would involve shifting the boundary, remapping
a few pages for the user processes, and then loading the driver.
Tiny test drivers could be added to test the "load" and "unload"
routines, as well as setting the "lock in memory" bit.

Loading/unloading device drivers involves quite a bit of overhead
and may affect ongoing processes like TCP/IP, so care should be
excercised in determining when to load or unload a driver.

PHASE 3:
--------

Full implementation of dynamic device drivers.  By this time,
all known bugs have been fixed and the driver format has been
determined to facillitate the writing of additional drivers.
In this phase, the only bugs should be in the drivers themselves
and not in the kernel.

----------------------------------------------------------------

Ideas?  Suggestions?  Please reply to comp.os.linux, for further
discussion.  I would prefer that even flames be posted instead
of mailed to me, as any such flames would refer more to my lack of
understanding of Linux internals than anything else, and may help
others to better understand Linux.  :-)

This is not a complete plan, but merely a rough outline.  I have
left out specific details of the implementation due to my lack
of familiarity with Linux internals.  I also know that there are
a lot of weak areas in my idea, but it is a good starting point
for a serious discussion.


--
Jim H.
*
* James L. Henrickson
* [e-mail]        "Some day I might have a real .signature!"