From: James A Simmons <jsimmons@acsu.buffalo.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 17 Sep 1998 13:42:58 -0400 (EDT)

Re: kgicon into kernel?

On Thu, 17 Sep 1998, Marcus Sundberg wrote:

> Andrew Apted wrote:
> > It's just MHO, but I think there sheer size of the patch, as well as the
> > bad name of GGI on linux-kernel, and also the recent history of what
> > happened when abscon was put into the kernel, all conspire to make it
> > very likely to be rejected, so close to 2.2.
> 
> Well, personally I have split feelings about even trying to get in
> to the kernel: 
> As a GGI developer I think it would be nice as it would probably give
> us more users/testers and more developers.
> But as just a coder I wouldn't want the current kgicon in the kernel
> because of flaws in the current KGI API, and the fact that we're right
> now about to get a new KGI API. (What would Linus think if we got
> into the kernel, and then said "what we convinced you to put into the
> kernel was just a bad temporary solution, here's a replacement for that")
>

I agree. I see problems too. The reason I was yelling was hurrry up and
get a move on it. Like I said if QNX can get in so can kgi. The problem is 
if 2.2 is due out in 3 weeks then we don't have time to play around. Its
now or never. The sooner it in the kernel the sooner we get more
developers and more testers. 
 
> Bad things in current KGI:
> 1. It's supposed to be portable, but yet there are _tons_ of Linux
>    specific stuff in all the headers, and also some of it in the
>    drivers.

Yes. But have you notice where the the linux code mostly is. Its in the
kgi_init_*. Place these in the OS/bus wrapper (for us fb-kgi.c).  


> 2. We use a static buffer of 2*pagesize to hold the ioctl arguments,
>    even though most commands are less than 100 bytes. This wastes
>    kernel memory.

Who is the kernel memory guru? 

> 3. We keep static data inside the drivers! If I have 4 Millennium cards
>    I don't want to have four 60k copies of identical code in kernel
>    memory. It should be handled just like the libggi target does it -
>    have one struct per card containing a pointer to private data for
>    each subsystem driver.

Yes. I have notice that. Also for some platforms like PPC the monitor info
can be taking from the nvram. We should create these structs on the fly.
Also allocate subsystem structs on the fly and tehn set the pointer is
kgi_display to point to these. For example I have two card but one
monitor. Why compile two exact same monitor data structs. For multiple
cards I suggest that we make kgi_display a linked list. 

> 
> Number 2 can be solved pretty easily, but for 1 and 3 I really don't 
> see anything that would justify all the work, when we're just about
> to throw the current KGI API away anyway

Could we see the new API. Bring it forward onto the tabel and then
everyone can make a suggest or add a idea that was overlooked. Like
someone (can't remember who) saying how about placing the code into
kgi/[chipset]/*.h. This was a better idea then my hack for placing
../../include/[chipset].h in alot of the code.