>>This is great.  "There's a problem, I can't describe it, I can't tell
>>you how to repeat it, I can't repeat it myself, but it's Really Really
>>Bad?"
>>Without knowing what the specific problem is, I can't even begin to
>>fathom its cause, and whether that cause is a programming or design
>>error in their interface, a programming error in the code which uses
>>it, or what.  Without knowing that, it's impossible to know how to
>>make the design more bulletproof.
>	I'll try to repeat it sooner.  it was something with include file
>	ordering.

	okay, here are some of the issues I have experienced.  sorry for the
	delay.

	- even if you declare exactly the same MIB variable more than once
	  (have multiple SYSCTL_INT for the same MIB variable), kernel
	  compilation will not complain, kernel runs fine, sysctl(8)
	  will grab one of the declaration, and the user have no idea which
	  it was.  kernel compilation should fail.
	  (this symptom is very similar to the failure mode when we forget
	  to inculde opt_xx.h - you have almost no idea what happned, and
	  it is hard to find the source)
	- if you forget to declare SYSCTL_DECL before SYSCTL_INT, kernel
	  compilation chokes with totally cryptic messages like:

>../../netinet6/in6_rmx.c:248: `sysctl__net_inet6_ip6_children' undeclared here (not in a function)
>../../netinet6/in6_rmx.c:248: initializer element is not constant
>../../netinet6/in6_rmx.c:248: (near initialization for `sysctl___net_inet6_ip6_rtexpire.oid_parent')

	- if you do not include sys/sysctl.h, kernel compilation fails with
	  totally cryptic error messages (again).
	there are some other issues I experienced with header file inclusion
	ordering, which I cannot remember right now.

itojun