>  > 	KAME team really need to revisit struct res_state_ext in
>  > 	/usr/include/resolv.h.  is it acceptable if I remove it once
>  > 	from the header?  Quite unfortunately, libc contains globally
>  > 	accessible symbol:
>  > >>extern struct __res_state_ext _res_ext;
>  > 	but I believe noone except libc code ever touches this.  This was
>  > 	introduced in sometime June 1999.

I originally introduced this struct into KAME just because there are no room
to extend in struct __res_state.  To keep binary compatibility, I cannot
add members to __res_state.  I was very careless to forget to reserve
some paddings in __res_state_ext.

There are at least two issues raised.
	1.  Update resolver to bind8.
		resolver in bind8 requires some additional members in
		struct __res_state.
		Unlike other platforms, our __res_state has no additional 
		pad at the end of struct.  So we must use some tricks
		to migrate into bind8 with keeping binary compatibility.

	2. Scoped-aware address sort for resolver.
		resolvsort feature in sort_list might be useful to
		specify preferences, though it is not clear defined yet.

So KAME team would like to reconsider the way to extend current __res_state
to allow some future extension without breaking compatibility.

> If nothing outside of libc touches it, then yes, please remove it from
> the header file.

There is only one file in source tree.
	basesrc/usr.sbin/faithd/faithd.c

And at least one in pkgsrc
	pkgsrc/mail/smtpfeed/

Both of them are derived from KAME/WIDE.

Atsushi Onoe