On 27/06/2000 at 16.19 Jonathan S. Shapiro wrote:
>> 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.
yes, I was confused on that point.
>
>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.
probably the system crashes? :-)
>
>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).
thanks
>
>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.
I agree with you, an embeddable text-only version would be very nice, more
precisely I am thinking about four versions: GUI end-user, GUI server,
embeddable text-only end-user, and embeddable text-only server.
I am thinking about managing the embeddable text-only versions with the GUI
management tools of the GUI versions over the network (when you need the
graphical administration tools).
For example the embeddable text-only server version may be useful in
hazardous environments when you don't have an operator at all,
while the embeddable text-only end-user version may be useful as a "floppy
version" and/or as a network sniffer and monitor.
Those are useful applications in which I have much interest.
There are two related sites:
http://loaf.ecks.org (Linux On A Floppy)
http://www.trinux.org/ (Trinux)
valerio
>
>
>Jonathan