lkml.org 
[lkml]   [1996]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: SVGA kernel chipset drivers.
From
Date
Jon M Taylor wrote:
> On Wed, 5 Jun 1996, Theodore Y. Ts'o wrote:
>
> > The problem with the GCI architecture you've described it is that it's
> > locked into whatever acceleration features that the GCI team knew about
> > when it first created the GCI architecture.
>
> First, it is GGI, not CGI. Second, why must this be set in
> stone? If things can change as much as they have in the /proc
> filesystem, a precedent is there for this sort of thing. Besides, there
> are undoubtedly ways of either ensuring complete backwards compatibility
> (i.e., IOCTLs only get added, never removed or modified) or implementing
> some srt of versioning scheme to ensure that older apps always use the
> IOCTL set they were compiled to use. I'm sure that there are other
> solutions as well.
...

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>


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.184 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site