Re: binary drivers and development

[Albert Cahalan <albert@users.sf.net>]

Lennart Sorensen writes:

> You forgot the very important:
>    - Only works on architecture it was compiled for.  So anyone not
>      using i386 (and maybe later x86-64) is simply out of luck.  What do
>      nvidia users that want accelerated nvidia drivers for X DRI do
>      right now if they have a powerpc or a sparc or an alpha?  How about
>      porting Linux to a new architecture.  With binary drivers you now
>      start out with no drivers on the new architecture except for the
>      ones you have source for.  Not very productive.

Rik van Riel writes:

> No, it wouldn't.  I can use a source code driver on x86,
> x86-64 and PPC64 systems, but a binary driver is only
> usable on the architecture it was compiled for.
>
> Source code is way more portable than binary anything.

The kernel already has an AML interpreter for ACPI. **duck**

As for portability, AML would do the job. It beats typical
vendor source code IMHO, because endianness and integer size
are well-defined. (like the Java VM and .net)

For the x86 and ia64 users, the AML interpreter is probably
already compiled into the kernel. Most people need it to
set up SMP or power management. So, no added bloat even.

AML code is fairly well controlled and isolated. There is
of course the backdoor via DMA for the truly determined
evil author, but such paranoia is rather extreme. AML is
really designed for this sort of task.

As with any interpreter, there are ways (JIT) to make the
AML interpreter go faster if need be.