Re: [somewhat OT] binary modules agaaaain

From: Grzegorz Kulewski
Date: Thu Apr 22 2004 - 09:14:43 EST

On Tue, 20 Apr 2004, Horst von Brand wrote:

> Guennadi Liakhovetski <gl@xxxxxxxxx> said:
> > On Tue, 20 Apr 2004, Bartlomiej Zolnierkiewicz wrote:
> > > > A binary module is "considered good" if
> > > This is a false assumption IMO no binary only modules can be "good".
> > I agree! That was just an idea to make Linux life easier __if__ it
> > __must__ live with binary modules.
> Then call it "tolerable", not "good". ("Barely tolerable" comes to mind,
> but might be a bit harsh...).
> In any case, one of the biggest advantages of Linux is that in-kernel
> interfaces aren't set in stone. They are extremely efficient because they
> are expressed in terms of access to data structures and inline functions
> and macros. The kernel is extremely flexible because it can be configured
> in hundreds of different ways. All of this is lost through a fixed
> binary-only interface to the binary blob inside the module.


Maybe I am totally wrong, but I think that binary modules should (if they
must exists) be divided into source (better opensource) interface and
binary only part. But I think that majority of binary only drivers could
be moved to user space in the great part. Some of them for example are in
kernel only to allow to create new device and "bind" to it. The rest can
be probably moved to userspace. Yes, there is performance issue, but only
in some very rare cases: video cards and maybe something more. But modem
drivers, vlan drivers, most raid drivers, archiving and versioning
filesystem implementations, network filesystems (LUFS?), and probably more
can be removed from kernel.

So I think that there should be some kind of special user-space processes
that are userspace, have separate adress space, have some special
scheduling rules (to make them more important than normal processes) and
can interface with kernel better than normal processes (maybe they will
have more special syscalls and some kind of callback functionality...).

The interface should allow create and "bind" to device, allocate memory
region, dma, interrupt, port range, etc. This interface can be considered
unstable and change with the kernel. There should be way to allow some
process to do something and disallow to do everything else (to protect
from hidden secret code or simply broken driver). And the interface can be
not very portable but should be highly extendable by vendors to allow them
add other functionality to it (if vendor will make this functionality gpl
and if it will be good it can be included into mainline kernel). This way
vendors can cooperate with kernel developers.

What do you think?

Grzegorz Kulewski

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at