In article <Pine.NEB.4.58.0401311142430.20420@haiku.jarai.net>
vaxzilla@jarai.org wrote:

> --- uvm_map.o ---
> #   compile  GENERIC/uvm_map.o
> /u0/work/netbsd-current/src/obj/tooldir.NetBSD-1.6ZG-i386/bin/vax-\
> -netbsdelf-gcc -mno-asm-pic -ffreestanding -O2 -Werror -Wall \
> -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes \
> -Wstrict-prototypes -Wno-sign-compare -Wno-uninitialized -D_VAX_INLINE_ \
> -I. -I/u0/work/netbsd-current/src/sys/arch \
> -I/u0/work/netbsd-current/src/sys -nostdinc -DLKM -DMAXUSERS=8 \
> -D_KERNEL -D_KERNEL_OPT -c /u0/work/netbsd-current/src/sys/uvm/uvm_map.c
> --- uvm_map.o ---
> /u0/work/netbsd-current/src/sys/uvm/uvm_map.c:3881: \
> field `ukh_entries' has incomplete type
> --- uvm_map.o ---

I think this warining happens only on gcc-2.95.x,
which is still used on vax and sh3 etc.

In uvm_map.c, struct uvm_kmapent_hdr is declared:

---
struct uvm_kmapent_hdr {
	LIST_ENTRY(uvm_kmapent_hdr) ukh_listq;
	int ukh_nused;
	struct vm_map_entry *ukh_freelist;
	struct vm_map *ukh_map;
	struct vm_map_entry ukh_entries[];
};

#define UVM_KMAPENT_CHUNK                               \
	((PAGE_SIZE - sizeof(struct uvm_kmapent_hdr))   \
	/ sizeof(struct vm_map_entry))
---

With a quick glance, uvm_kmapent_hdr is allocated by PAGE_SIZE
and size of ukh_entries are calculated after allocation,
but is it really valid even on gcc-3.x?
I'm afraid such hack might cause wrong optimization.
(I guess it's invalid in ANSI-C, but no idea if it's matter here)
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp