Re: [Trion-kernel-dev] More resources

[Daniel R. <cos...@gm...>]

> Another technique would simply be to support full RGBA from the get-go...
> which, imo, is a good idea anyway.  In that case, a shaped window is no
> different then a regular window... it just has fully (or even partially)
> transparent pixels.

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. Nevertheless I like the idea of supporting partial  
transparency in the video driver as it might save a lot of unneccessary  
complexity on the higher levels when, for example, implementing a  
crystal-like design as in windows vista. To support non-rectangluar  
windows one could easily combine RGBA with one of the two methodes that  
you mentioned earlier..

> Speaking of which, where is the final version?  I haven't read the whole
> thing, and I think my version is dated.

It was on my private webspace as I had some problem setting up my CVS  
client (WinCVS) for ssh access which seems to be needed to commit files.  
Now that I finally found some documentation that did not only apply to the  
old release of my client I've uploaded it to the reposity:  
trion/docs/trion design draft.pdf

> 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 wouldn't want to integrate an x11 server nativly into the trion design  
as it just much to high-level for a nanokernel approach. What I however  
could imagine is a linux compatability layer that puts the functionality  
of x11 into a libary/server running on native trion to support legacy  
programs (*very* important to be successfull) or to allow programmers to  
write programs the way they're used to. In fact one of the most important  
points about nanokernels is that they allow such solutions without a  
considerable overhead as their own structure is on a extremely low level  
and all of the abstraction takes place in the libraries. The programmer  
may thus decide which policy and API he wants to use by picking an  
appropriate library.

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

regards,
cosmo86