Re: KGI and LibKGI

[Brian S. J. <br...@tu...>]

On Fri, 16 Nov 2001, Nicolas Souchu wrote:
> > 2) LibKGI's sole purpose is to abstract OS mechanisms when they may
> > vary from OS to OS.  All the structures needed to use a display should
> > be in the KGI API, not the LibKGI API, and LibKGI only exists to
> > locate and provide handles with standard methods via which these
> > structures can be accessed/sent/received.
> 
> Especially for OSes completly different like unix and windows or whatelse.

Yes, It would be very nice to have a rundown of various OSes to see what 
the available mechanisms are.

> > 3) LibKGI should not require extension in order to access
> > subsystem-private data areas.
> 
> You mean?

LibKGI should not have to load another .so to be able to send/receive
data to a resource which only exists in a certain subsystem driver,
for example if you have a specific kind of ramdac which exports a 
proprietary structure to control a proprietary feature, LibKGI should
be able to send/receive data to/from it without modification.

> > 4) With the exception of tasks that require extensive OS assistance,
> > and mode negotiation, which has to have a standard intraface anyway in 
> > order to tie together the subsystems, LibKGI is not responsible for 
> > abstracting differences in drivers/chipsets, ONLY differences in the OS.
> 
> Of course, this is KGI job.

Hmmm... not what I was driving at.  I was thinking more that (except
in certain cases, e.g. mode negotiation) it was neither LibKGI nor
KGI's job, rather being the job of something higher level like LibGGI or
PhoeniX.

> > 5) LibKGI is not held to the standard that LibGII is: binary
> [...]
> > be present, you will be able to recompile and get a functioning
> > application.
> 
> How to handle emulation of OSes. FreeBSD is really proud to execute Linux
> binaries. What happens if the application has to be recompiled if it is
> closed-source (Netscape, Acrobat, vmware are typical examples)?

Depends on how well emulated the Linux environment is by FreeBSD.  If
they support all the MMAP features used under Linux and had all the right
filehandles, then it would work.  We of course have the option of 
providing a recommended set of flags for compiling closed-source
binaries that would aid in this situation (but then, hopefully most stuff
would use an opensource mid-level library like GGI or GL instead of
LibKGI.)

> > 6) LibKGI should be macro-heavy and only use functions when needed or
> > in non-performance-critical areas.
> 
> Of course, in this way you loose the binary compatibility. Do you really
> think that a function call is a huge overhead? It is when you have bad cache
> policies in your CPU but most of the time it costs no more than a CPU cycle.

The inline reductions done by the compiler save much more than the function 
call overhead itself.

--
Brian