From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Thu, 5 Aug 1999 21:45:38 +0200

Re: Matrox GGI accellerator

> > Hmm, just thinking... Open source isn't that cool at all here: Some user
> > can hack the GGI libs and thus still crash the system. Damn.

You do not need to do that. Unless we get "suid libs" (something I had
thought about a while ago, but it is very difficult to do), a lib is never
safer than the app that uses it. You can just bypass it. You have all the
rights, the lib has.

> > And how to tell a program that a mmapped space it has a pointer to is no
> > longer valid ? 

SIGNAL. Only asynchronous mechanism we have. I'd just unmap and signal or
block at the next access.

> > How does the kernel know that the buffer is full ? 

Either next one being accessed or explicit flush.

> You don't need a real system call. [Please , Steffen correct
> me if I'm wrong.] You can simply trap a memory fault when the
> application tries to write 'after' the current page. 

That is as expensive as a system call (even more IIRC), but more convenient.

> > I'm just wondering by myself how big a pingpongbuffer must me for optimal
> > speed. You don't want a sync to take ages, just because there was a huge
> > buffer still waiting to be filled completely that still needs to be
> > executed.

IMHO that can be decided dynamically by the kernel. Minimum is machine page
size, but you can have any number of them in the circular area. and you can
concatenate them as needed. The kernel could even "see" that the overhead
of trapping at every page gets too high and trap at every second page only.

I would for performance reasons actually advocate to use "blind" access to
the circular buffer and explicit flush using a separate call that gives the
current filling state. That allows the program to normally just fill the
buffer, no matter how the kernel has currently organized the segfaulting.
Steffen's next-page-at-offset method has a little drawback here, as it
relies on knowing where the kernel will trap the next time.

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =