Re: [Trion-kernel-dev] More resources

[Manuel H. <mho...@ph...>]

> Maybe I'm missing something as I've some problems imagining how the video
> driver could make sure that an application doesn't write to areas that are
> outside of its non-rectangular window if the protection information is
> stored in the bitmap itself. After all application have full access to the
> buffer which also encompases those regions that are ouside of the
> non-regular window.

This could be done by allowing the application to change the RGB data while
keeping the transparency data fixed. Every application has its own virtual
screen, but only those regions which are not transparent are shown on the
physical screen. To support partially transparent windows, we could use only
7 transparency bits and use the last one for maintaining access rights.
Another possibility would be to grant every application full access to its
virtual screen.

> > While this question isn't overly relevant in this stage of the game, I'm
> > curious as to what people think in eventually implementing (ie, porting)
> > an x11 server to trion?

I think we could port an X11 server to Trion as soon as we have set up an
API. This would be quite easy if we set up a Linux API on top of the Trion
kernel, just like the L4Linux which has been developped by the L4KA group
and implements Linux on top of a nanokernel. But of course we could also
port an X11 server to a native Trion API - just like any other server /
resource manager in the nanokernel design.

> > What does everyone think are the things that need the most work?
>
> First of all we of course have to get a basic (only uniprocessor, no fancy
> features) nucleus up and then a console, keyboard and floppy driver will
> be neccessary to get the most fundamental functionality working (debug
> output, typing, loading other drivers). After that I'd go on by
> implementing the three managers of the system: task manager, memory
> manager, device manager (what each of the servers in detail does is
> described in §1.3 of my paper). Together these three servers and the
> nucleus build a basic system so that it from then on doesn't matter that
> much any more in which order things are done.

I agree, although I think we could include SMP support from the very
beginning. But we can also add this later.

Regards,
Manuel