Ok, assuming proper API for USER PROGRAMS:
- The API is implemented in a shared library
- That library knows about card-specific ioctl tricks,
and their evolution
- That library should propably consist of 'common' interfaces
part, plus card specific on-demand loaded parts, thus allowing
insertion of new card-drivers into the framework without
rebuilding the whole library (as when it is monolithic)
Now cards that need to have their own special drivers can have
them as loadable kernel modules.
(and whoever wants to use static libraries is doomed to fail..)
Can you say: "LIBC For Graphics" ?
The positive possibility I see at this is, when the card-specific
kernel module is opened (from its default text mode), it saves the
card state, and when the fd is closed, it restores that state.
Thus crashed application won't leave the display in a scrabled
state. (Additional interlocks would ensure that only one open
into the graphical mode is allowed per each virtual console,
restere the keyboard mode, etc.)
Could we (Linux users) get our act together with BSD folks, so that
there would be a unified set of drivers (and libraries) for both
platforms ? After all, this is a case where our platforms speak
with the hardware, and do it in very similar fashion (because the
hardware is the same..)
I do agree with Linus that kernel should not have tons of special
compiled-in stuff just to handle some odd OpenGL rendering interface.
All the kernel needs is text support, everything else (special) can
(and should!) be loaded by user.
For a comparison, look how much stuff there is in the standard kernel
for PCMCIA interfaces. The whole thing is made with loadable modules!
I am thinking it is a time for linux-ggi -- with co-op work with
the BSD people. ( .. and thus to get this discussion out from the
generic linux-kernel -list ;-) )
...
> Jon Taylor = <taylorj@gaia.ecs.csus.edu> | <http://gaia.ecs.csus.edu/~taylorj>
/Matti Aarnio <mea@utu.fi> <mea@nic.funet.fi>