lkml.org 
[lkml]   [1998]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Feature Wish] GGI in Linux 2.3
On 16 Jan 1998 ketil@ii.uib.no wrote:

> Hmm...I was thinking along the lines of the old GGI argument of "sound
> drivers get into the kernel, so why not graphics?" (approximated and
> condensed for your convenience)
>
> Now, thinking about the GGI issues of: a KGI, which defines access to
> the hardware, and libGGI, which contains routines for using that access
> (correct me if I'm wrong on this). Shouldn't sound behave similarly?
>
> That is, a KSI which opens for accessing the audio hardware, and a
> libGSI (or whatever). I admit to not knowing about how the sound
> driver(s) is implemented in the kernel, but couldn't this allow stuff
> like multiple sound cards (``multi-mouthed'' systems)? Wouldn't it
> simplify the kernel, and move stuff into userspace?

OSS already supports multiple cards, if you have enough free IRQs, DMAs,
etc. However, the main reason for not putting all of the graphic
abstraction into the kernel is merely that of size. For example, if your
card supports a linear framebuffer but not a hardware accelerated BitBlt
then it's a bit unnecessary to put a BitBlt function into the kernel when
a userspace library could do it just as easily.

Whereas, although the sound driver is pretty bloated, it's not a tenth of
the size that a decent video abstraction would be, so it has ended up (for
better of worse) in the kernel.

Matthew.

--
Matthew Kirkwood | Mail: matthew.kirkwood@lmh.ox.ac.uk
LMH JCR, | Web: http://www-jcr.lmh.ox.ac.uk/~weejock/
Oxford OX2 6QA, |
England. | "To do things badly is a basic human right"

\
 
 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2011 Jasper Spaans