Thanks Jason,
I had this itch to change the refs and make it something like you 
describe but...I did not want to change the work that Ken did BUT I am 
thrilled I have a clean compile, and am building the tops20 sys with TCP 
as I type.

I have worked with FreeBSD - cause the Xwindows support seemed so easy, 
might have been me.  Debian - casue of the CCC capability, Redhat cause 
it came with a couple of alphas I picked up and because of the SELinux 
capabilities.  but I seem to have this bent towards NetBSD.  Just seems 
natural to me.  Considering that I jump from PC to Vax to Alpha as I 
play with things, I like the transparance.  Now, to have a version of 
the 10 that runs cleanly on all three environments is great!!

I will tweak the sources with your suggestion and see what it does for me.
thanks
bob
Jason Thorpe wrote:
> 
> On Friday, May 9, 2003, at 03:04  PM, bob smith wrote:
> 
>> # This auxiliary file is needed to get around a bug in the NetBSD
>> # /usr/include files.  <stdio.h> includes <sys/types.h> which includes
>> # <machine/types.h> which incorrectly exposes a typedef of vaddr_t 
>> (normally
>> # a kernel only type), thus conflicting with KLH10's vaddr_t.
>> # By including this file ahead of any other source files (see the 
>> -include
>> # in CENVFLAGS) we can nullify the typedef.
>> # And while we're at it, blast paddr_t for the same reason.
>>
>> netbsd-sucks.h:
>>     @echo '/* DO NOT EDIT - dynamically generated, see Makefile */' > $@
>>     @echo "#define vaddr_t _kernel_vaddr_t" >> $@
>>     @echo "#define paddr_t _kernel_paddr_t" >> $@
>>     @echo "#include <sys/types.h>" >> $@
>>     @echo "#undef paddr_t" >> $@
>>     @echo "#undef vaddr_t" >> $@
> 
> 
> Nonsense.  I seem to recall that identifiers that end in _t are reserved 
> for the system in ISO C, and thus user applications that define them 
> themselves are incorrect.  I.e. it's KLH10 that is buggy for defining 
> its own vaddr_t and paddr_t types.  Instead, it should choose another 
> name, like "klh10_vaddr" and "klh10_paddr".
> 
>         -- Jason R. Thorpe <thorpej@wasabisystems.com>
> 
>