lkml.org 
[lkml]   [1998]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: GGI Project Unhappy On Linux
On Wed, 25 Mar 1998, David Todd wrote:
[deletia]
> I think the technical issue is whether the kernel provides services beyond
> that which is needed to boot and get a basic terminal up. Many folks think
> it's enough to give a user space thing hooks into the kernel, ala X. There was
> also some question as to whether sound should be where it is, or farther out
> into userland.

So, could KGI install as a module, grab a few hooks, and take over for
the just-plain-console code? I have to agree with the sentiment that you
really don't want userspace code playing directly with hardware (other
than the CPU!); the kernel's purpose is to organize access to the
hardware and protect system integrity. One of the most popular ways to
hose a system is to foul up the graphics card, therefore this function
(graphics organization and gatekeeping) belongs in the kernel.

Certainly, if GGI is adopted, it should be optional. I understand quite
well the argument that hardly anybody needs fancy graphics stuff to run
Quake on a router or Web server, and those sites shouldn't have to drag
around a lot of functionality that they will never use.

I also think that the plain-Jane console code needs to be there at every
bootup, to support simple boot-time messages that are sometimes important
to each of us. I've seen this method work well on other OSes with the
file system: you boot up with simple, bulletproof FS code that's just
smart enough to find the rest of the kernel, then switch over to the fancy
code for performance and features during normal operation.

> I think Linus's comment is the most important. The code has been "slushy" for
> some time now, a major subsystem violates that freeze.
>
> When 2.2 is out, and GGI is more complete, perhaps then the folks will be able
> to look at it closely.

I agree that this is not the time to import major changes in organization
and function into the kernel. Best to target 2.3 for serious integration
efforts.

> On the other hand, perhaps folks should now, to make sure it goes a useful
> direction as far as future kernel plans go.

Agreed. It should be examined by those who think it might be useful and
who can deal with an add-on product.

> A side comment:
>
> It may be a far better thing for Linux et al to figure out how to give better
> access to the hardware for such projects. I think they may be doing this, but
> don't quote.

My understanding is that that is exactly what the KGI portion of GGI is
for, w.r.t. graphics. Other low-level gatekeeping functions should be
explored too. But don't let's just allow any joe-user program to diddle
the hardware registers, like those OSes that crash all the time.

--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
One more time: a (level-2) switch is a bridge. A "level-3 switch" is
a router. Deal with it.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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