From: Jason McMullan <jmcc@ontv.com>
  To  : ggi-develop@eskimo.com
  Date: 10 Jul 1998 15:21:56 GMT

Re: Degas cleanups

Jon M. Taylor <taylorj@ecs.csus.edu> wrote with confidence:

> degas/console
> degas/console/include
> degas/console/os/linux
> degas/console/os/patches/linux

> 	Allows for GGI Console being used with other OSes besides Linux 
> at some point.  Is this necessary?  Will this ever happen?  It is 
> happening with KGI, that is why I ask.

  GGI Console will be Linux-only for now. It can't be `copied'
to FreeBSD due to kernel source licensing issues, but the API
can be re-implemnted. Don't worry about cross-os.


> degas/console/drivers
> degas/console/drivers/include
> degas/console/drivers/joystick
> degas/console/drivers/mouse

> 	The most uncertain one.  How does KII fit into all this? 
> Presumably KII will take over the responsibility of handling input drivers
> and GGI Console would talk to it the same way it will talk to fbcon/kgicon
> - through an abstract interface.  The question is, should we make 
> preparations for KII in the tree, or leave the drivers in GGI Console's 
> domain where they are now?  Steffen?  Jason?  Talk to me, guys.  Anyway, 
> _if_ KII was put into Degas, I would structure it like this:

	Put the input drivers for GGI Console in GGI Console. When
Steffen's KII subsystem is functional, I'll just use it instead of
the GGI Console drivers.

> degas/kgi
> degas/kgi/include
> degas/kgi/os/linux
> degas/kgi/os/patches/linux
> degas/kgi/drivers
> degas/kgi/drivers/include

> 	Yes, I know I put kgicon in degas/kgicon.  I have been regretting
> it ever since, but I did not want to overwrite the existing kgi/ and
> include/kgi directories and I knew that we'd be having to move lots of
> directories around eventually anyway.  kgicon is really just the KGI-fbcon
> bridge, and now that people are porting KGI to other OSes (Roadrunner,
> Dolphin, FreeBSD) it is not really correct to call all of KGI "kgicon".

	Good point. Just move the current kgi tree to console/kgi and
replace it with kgicon.

> degas/lib
> degas/lib/libggi
> degas/lib/libggi/include
> degas/lib/libggi/extensions
> degas/lib/libggi/extensions/libggi2d
> degas/lib/svgalib

> 	Mostly OK right now, except for deciding where libggi2d should 
> go.  IMHO it is a LibGGI extension (and hence part of LibGGI) and so the 
> above directory structure would be correct.  However, it is currently 
> also present in degs/lib/libggi2d.  We need to resolve this.

	My vote is for degas/lib/libggi2d, and it should pull includes
from degas/lib/libggi/include. No need to make the dir structure too
deep.

> 	Note that there is no top-level degas/include directory.  This is 
> sensible, IMHO - there are no shared includes anymore (and if there are 
> this is (also IMHO) bad practice and should be cleaned up), so no shared 
> include directory should be present.

	Agreed. 


> * The top-level Makefile's check_dev and clean_dev targets are still using
> the old /dev/graph setup.  They need to be updated to create the correct
> files for GGI Console (kgicon uses /dev/fb which can be assumed(?) to
> already be present).  Again, if KII is to be included with Degas it needs 
> this too.

	GGI Console is Not Ready For Prime Time driver-wise, so
why not cut it out of (a) the makefile system and (b) the release
trees. When GGI Console can work with a KGIcon kernel and KGIcon
drivers, let's put it back into the makefile system.



-- 
Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc

On the wonderful world of Microsoft Products:

  Why put fault tolerance in the OS, when it's 
  already built into the User?
	-- Steve Shaw <nospamola_sbshaws@kc-primary.net>
	   comp.os.linux.advocacy