From: Rodolphe Ortalo <Rodolphe.Ortalo@cert.fr>
  To  : ggi-develop@eskimo.com
  Date: Tue, 03 Aug 1999 17:06:32 +0200

Re: Matrox GGI accellerator

Jos Hulzink wrote:

> 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.

NB: If a user can 'overwrite' the GGI libs,or replace the kernel
driver with a 'customized' version : then he is already root in the
system...
Ensuring the integrity of the system software is also a
security issue, but a different one...
Here we want to ensure that user applications cannot
easily break the whole system. And we need to trust to
system software for preventing that.


> Heh, I finally got the idea. But define mmap pages please. Are these 1)
> part of the framebuffer (Video cards RAM) or 2) Kernel memory ? 3)
> Something very logical my stupid mind forgets ?

[Steffen, correct me if I'm wrong please.]
The 2 pinpong pages are conventional memory pages. At a precise
point in time, one of them is in kernel (or maybe more accurately
out of user space) and the other is in the application user space.

> And how to tell a program that a mmapped space it has a pointer to is no
> longer valid ? How does the kernel know that the buffer is full ? Still
> ioctl ? I'm thinking of an IOCTL that demands the kernel for switching and
> returns not before the other buffer is empty and ready to be filled by the
> program again.

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. But you don't
segfault the application, instead you take the recently-filled page,
give it to the driver, take the other page (eventually waiting
if its processing is not yet completed), put it up to the user space
(at the right virtual memory address), and then you simply
resume the uncompleted memory access.
I think that the userspace code does not see anything. The only
constraint it sees is that it has to write into a 2-pages long circular
buffer that gets 'magically' processed. Virtual memory is really
a wonderful thing.
Well, just to conclude: please Steffen, correct me if I'm wrong ! ;-)

> 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.

I guess only experimental figures will tell us. It's a pity we don't
have a full running thing yet. Furthermore, I suspect that a precise
application may exhibit a specific optimum. Just for the pleasure of
speculation however, I'd say that, in my opinion, a single page
may be enough.

Especially if it's a big page ! :-))))


Rodolphe


> P.s. sorry for this huge amount of questions, I'm an Electrical engineer
> learning Kernel programming, not a real engineer in Computer Science

You seem pretty concerned with software engineering issues. That's
somehow rare among 'hardware' people. Thanks for your attention.