> All we need is a popular hardware vendor introducing shared libs into the
> kernel :)..
Shared libraries in the kernel are pointless.
A shared library is a common library that can be shared between different
address spaces. That is not needed, because the kernel has only one
(kernel) address space.
When kernel modules are loaded they can export symbols, and other kernel
modules can use it. When the kernel wants to use functions in external
modules it can use kmod/kerneld (with a bit of bootstrapping, the external
module has to put the needed address into some hook which the kernel
will call then, this is usually done with some shared structure like
a device).
So all things you would want from shared libraries are already there.
> Having windows drivers coders doing Linux kernel code scares me. :)
> On Mon, 11 Jan 1999, Jacob Hawley wrote:
>> Creative intends to put out two equally important pieces for the Linux
>> community.
>>
>> 1) An OSS Binary driver that can be used in the next few months from a company
>> called 4Front. This will allow Linux users to begin using their SB-Lives
>> immediately, while Creative becomes more familiar with Linux. This solves the
>> immediate issue of a SB-Live working on Linux.
This is only a short term stopgap solution. For example extensions to the
Linux source architecture (the ALSA project) will probably not well handled
by OSS.
>>
>> 2) Longer term we will produce a library(.LIB) that can be linked into ALSA,
>> OSS, or what ever. This library will expose the features of the chip and will
>> allow for additional functionality to be added. I suspect this is what most
>> people are actually asking for. In addition, we will write some form of
>> programmers reference guide to the chip so that anyone not interested in using
>> the library can program their own driver. We will likely put this out as a SDK,
>> which will include some sample source code for initializing the chip.
This would only work out if the library (lib*.a not .LIB btw@) is very thin.
Things like disabling interrupts or translating kernel addresses to bus
addresses are all done with inline functions or macros in Linux, and the
interface is only defined for source code portability. There is just no
stable ABI for kernel modules.
Also it does not address the issue of porting the drivers to other
architectures like Sparc,Alpha,Merced,ARM.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/