Networking stack into kernel

[Jonathan S. Shapiro]

[I have added marcb to the accept list for eros-arch.  The following
message were sent before that, so I am forwarding it.]

> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:jsshapiro@earthlink.net]
> Sent: Saturday, May 02, 1998 3:29 AM
> To: eros-arch@eros.cis.upenn.edu
> Subject: graphics vs. window managers
>
> I'm glad to find another term.  Here is the distinction I am actually
> trying to draw:
>
> People refer to X11 (incorrectly) as a window manager.  Ditto to Win32
> interface.

I would refer to X11 the set of, protocol, API, a window multiplexor and
display (including input devices) manager. Win32 is an API.

> Whatever you want to call those, I want to interject between them and
> the hardware a real-estate arbiter.  If you want to think of pushing
> window ownership decisions down into the driver that's fine with me.

I would not personally subscribe to the driver owning the windows.

> The goal, in the end, is to host an X server on top of the base thing,
> and be able to simultaneously host some other graphics system, and get
> all the windows on the same screen.

My position on a graphics sub-system comes from the Photon approach
(http://www.qnx.com/product/photon/photon.html). The architecture is as
follows:

A 2.5D graphical event space in which window objects exist. Mouse clicks and
keyboard events travel from the user through this space and hit or pass
through window(s). Drawing events pass from the initiating window (which
could be the background, an infinite distance away) towards the user. These
drawing events interact with the windows as they pass up. If they hit an
opaque window the die. If they hit a transparent window the keep going, and
possibly they could hit a translucent window the could modify the event in
some way.

The graphics space is also an ideal one. (eg. 24bit colour, infinite
resolution (maybe)). The cursor is handled by a window infinitely close to
the user (actually by the device driver windows).

Device driver windows turn drawing events into "physical" representations.
That could be a frame buffer, a printer or anything else you want. They
would usually be transparent to allow multiple ones to view the same
applications.

The window manager is a task that has a special relationship with the 2.5D
space manager (note the 2.5D manager could provide multiple such spaces, or
multiple instances could exist). It builds extra windows that provide the
decorations. It would also be able to move the windows with in the event
space.

In EROS the 2.5D manager, window manager, windows (graphical or device)
would be domains with the right keys. Check pointing could happen as usual
and it's only the device managers that need to be aware in some way of the
reboot etc.

To get X11 applications working, a special X11 window would present a X11
server to the X11 application, that would just forward drawing and window
creation calls into the 2.5D manager's event space.

>
>
> shap

In my mind it is the most flexible and rich framework for dealing with the
issues. As an example a text based application would just send text drawing
events when given a refresh event for a region of it's display. The device
driver window would be responsible for the double buffering etc.

If it was really desired (for speed), the text operations could be partially
managed by the text window by it sending a bitblt command first before the
updating of the part of the text screen.

Also a finial note, the window's should be able to communicate with the 2.5D
manager remotely over a network. Either via a connection to the 2.5D manager
or to a window proxy.

Regards,

Marc Boschma