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

Re: Makefile vote II

On Thu, 17 Sep 1998, Steffen Seeger wrote:

> > 
> > Well I seen everyones respone. I actually like the idea of moving all the
> > hardware header files under kgicon/include/[chipset] instead of
> > kgicon/kgi/include/[chipset]. I think this is a solution everyone can live
> > with. All the code can have a #include <kgi/include/[chipset]/foo.h>. Also
> > as pointed out this will be advantage if someone wants to program hardware
> > specific features like ping-pong buffers. Can we all agree on this and
> > change the code to this. 
> 

> I  still don't see the advantage. The <vendor/model.h> convention as it is
> now is IMHO perfect. These headers only contain register definitions, no
> code, or driver specific stuff. And including them via 
> #include <vendor/model.h> doesn't require more than an additional
> -I to gcc. 

The linux kernel makefile system doesn't work this way. The makefile
system sets -I its self and you can't change easily. True you could do a
-I for normal userspace programs. 

> 
> You can change this, if you like, but be aware that __you__ will have
> to convert your drivers to the new scheme. The agreement was that kgicon
> development doesn't touch the internal module interface, but writes a system
> layer and does neccessary adjustments. So, don't move headers around and
> change the overall tree structure. This make things worse than they are.

Then I will change it for myself and present the my tree to linus. With
the new cvs browser I can see what you guys have changed. I see none of
guys don't think their is a snowball chance in hell of getting it in.
Well I think your wrong. QNX filesystem just got added to 2.1.121. So much
for a code freeze. Do you think linus will think QNX filesystem support is
more important than KGI.