The question is, what is the choice with firmware? Sometimes, there is one.
eg the ncr53c78xx (or whatever it is called today) driver contains an
assembler for the embedded processor. Other drivers include the firmware
which is simply downloaded.
The difference with your approach is that your library _can_ be supplied in
source code (where most of the others can't). Additionally, stuff to be
executed on the host CPU is at the mercy of the many different incarnations
of the system that there are out there. Do you provide different code for
every kernel release that is available as the kernel changes? Firmware for
embedded processors are different, they don't alter. The kernel does.
What about other platforms on which Linux runs?
Your binary module will presumably be 386 code. No optimisations for other
processors posisble. Or do you provide 5 different libraries?
> 1) Release hardware specs and let someone write a driver.
> 2) Write a driver himself and release it in binary form only.
> 3) Provide an API for dealing with the hardware, and have someone
> develop a driver based on this API (the "Olicom" way).
4) Release source code. You forgot the simplest one of all.
> I've always thought of the Linux community to be rather pragmatic -
> the "if it's useful and doesn't bother anything else, let us have it"
> approach. So I hope this can generate a useful debate, and is not shot
> down immediately with a "we want full source, or nothing" statement.
I agree. There is need to address these problems. But I start from a point
of disliking the idea :-(
-- [======================================================================] [ Kevin Lentin Email: K.Lentin@cs.monash.edu.au ] [ finger kevinl@fangorn.cs.monash.edu.au for PGP public key block. ] [ KeyId: 06808EED FingerPrint: 6024308DE1F84314 811B511DBA6FD596 ] [======================================================================]