Re: GUI systems Jonathan S. Shapiro (shap@eros-os.org)
Tue, 27 Jun 2000 16:19:50 -0400

> A graphics system must be able to redraw the entire screen and single
> windows. A "redraw" routine should be faster than paging

I think some confusion has arisen. There is no paging overhead to redraw if we include the frame buffer in the checkpoint area.

The problem is that taking a checkpoint implies marking everything copy on write, and the next vertical scroll anywhere on the screen causes all of the frame buffer pages to need to be copied. Further, given that the graphics operations are done by the hardware and that the hardware doesn't generally have an MMU in front of the frame buffer, you can't rely on the hardware to honor the copy on write requirement. This issue will only arise every ~5 minutes, but it *will* arise every ~5 minutes, and it will rapidly become an annoyance.

A 32-bit megapixel display contains 4Mbytes of data. That's less of an issue than it was when I originally rejected including the frame buffer, but it's still a substantial fraction of available real memory. The reason it matters is that we must assume that this copy will be done aggressively, and that including the frame buffer in the checkpoint will therefore require that we keep available 4M of main memory into which we can make a temporary copy of the frame buffer at checkpoint time. While memory sizes have gone up, memory bandwidths are still pretty slow, and this copy is done across an I/O bus. It can't be done as a single move without messing up interrupt priorities and violating some bus contracts, so it's not a simple thing to implement.

Also, there is the problem of how to correctly restore the frame buffer when some idiot swaps out the video card.

On the whole I really feel that I want to keep this out of the kernel if possible. It's complex, it's tricky, and it can be added later in a compatible way while the reverse is not true (it cannot be removed compatibly).

That said, I *do* want to study the new Linux frame buffer implementation. Even if the frame buffer is not persistent, having a standard interface to it seems like a very useful thing.

> Also, a GUI is nice, but it is not always needed, IMO it must remain a
> separate add-on component.

In most respects I agree, but it's worth testing this assertion. In theory you can run Linux just fine without a GUI at all. In practice, this denies you all of the administration tools, a large number of tools that the user guides assume are present, and so forth.

For this reason, I think that the decision to include a GUI is actually a very fundamental decision.

My personal opinion is that EROS should have an embeddable implementation that doesn't have a GUI, but that we should acknowledge going in that this is simply a different operating environment than the end-user or server version. There will be domain code that overlaps between the two, but they really are quite different systems -- not least because embedded authentication is a qualitatively different problem.

Jonathan