lkml.org 
[lkml]   [1996]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Binary Driver Issues
On Mon, 17 Jun 1996, Albert Cahalan wrote:

> Implement a driver in each class (scsi, network, filesystem...)
> that fits between the kernel and a binary-only driver. When the
> kernel interface changes, the middle driver converts between the
> new and old interfaces. This means that binary-only drivers do
> not benefit from improved kernel interface design, but at least
> they still run. Start with a null translation layer for 2.0.x,
> then add whatever is needed to let 2.0.x drivers run with Linux
> version 2.1.x, 2.2.x, and even 9.4.x.
I don't think it's likely that there are going to be fundamental changes
in kernel/driver interface in future. I don't know what is the case with
SCSI and net drivers but I assume the same. Fundamental changes made to
the kernel interfaces are difficult since they will require lot of
changes to the drivers even in source level.

Handling incompatibility problems in "normal" changes in kernel's
internals is not too difficult. I have done it with the commercial
version of the sound driver since last October. The driver doesn't access
kernel functions and structures directly but uses some kind of wrapper
library. This library hides all references to major kernel structures
such as "struct file_operations" behind handles. In this way I have been
able to use the same driver modules without problems since Linux 1.3.81
(there was a change in kernel routines not covered by the wrapper between
.80 and .81).

The original idea was to include this library to kernel so that
it get's compiled automaticly with the kernel. Unfortunately Linus didn't
accept this module to Linux 2.0.x so I had to use different approach.
Currenty the wrapper module (sndshield) is distribted with sources so
than it can be recompiled on the target machine whenever kernel is
changed).

I don't try to describe idea of the wrapper here but the implementation
is available as a part of of USS/Linux (see
http://www.4front-tech.com/linux.html) for more info.

> Yes, this is gross. It works though, and it lets the driver
> interface change. The translation layer can even have an
> emulator so that the Alpha and PowerMac can use 386 drivers.
> It can provide bug-for-bug compatibility so that drivers will
> still work if standard kernel functions add better error checking
> that crashes the old driver.
How about implementing Java (or Forth) interpreter in kernel. Many device
drivers don't have very stricht performance requirements so even
interpreted code may work. Drivers implemented in this way will work in
every plattform and every OS, provided that the interface is well
designed. It's still possible to use "native" drivers whenever they are
available.


Best regards,

Hannu
-----------------------------
Hannu Savolainen (hannu@voxware.pp.fi, hannu@4front-tech.com)
http://personal.eunet.fi/pp/voxware/hannu.html (my home page)
http://www.4Front-Tech.com/uss.html (UNIX Sound System (USS))
http://personal.eunet.fi/pp/voxware (USS Lite/TASD/VoxWare)



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.046 / U:1.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site