From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Thu, 17 Sep 1998 19:17:45 +0200

kgicon into kernel?

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")

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

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

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se