> Regarding checking for devices, would it be possible to make the
> device tree information available to sysctl?  if the structure's
> chosen well, subvariables could later be added to indicate other
> information (ie, disk geometry, vendor info, perf stats, whatever
> other bloat anyone wants and can be bothered to add)
>
> [ ... ]
>
> What do folks think of this as a concept?  How hard would it be to
> implement?

I've thought about this a fair amount (surprise surprise 8-), and one
of the conclusions that i came to is that there can't be a 'sane'
implementation of it, unless sysctl takes "char *" arguments, rather
than ints.

the big problem is, if sysctl doesn't take char *'s as args, then you
need to query the kernel to see what the appropriate name->number
mappings are, etc., and then convert them a possibly-endless string of
ints.  i'd much rather give sysctl the string:
	"dev.isa0.foo.bar.baz"
to pass to the kernel and have the kernel split it up, than have
sysctl:
	(1) call the kernel (probably repeatably) to see what
	    'numbers' various strings in the hierachy map to,
	(2) invoke the kernel with the right set of numbers.
The overhead of doing the latter (for dynamically-named system
information) certainly comparable in complexity, and probably
comparable in CPU time, than doing the strcmps in the kernel.

note that you also need some common name like "index", to tell
you what's available at that level.  e.g. (on an AlphaStation 200):

	variable		return
	--------		------
	dev.index		"mainbus0"
	dev.mainbus0.index	"cpu0 apecs0"
	dev.mainbus0.apecs0.index
				"pci0"
	dev.mainbux0.apecs0.pci0.index
				"ppb0 de0 ncr0 sio0 tga0"
	dev.mainbus0.apecs0.pci0.de0.index
				"media macaddr"
	[ ... ]

and probably could even have machine-independent code to do all of the
hierarchy handling (based on config parent/child relationships).

alternately, one could have devices/busses that support the interface
attach themselves, and present a flat namespace -- that could be
easier, in some ways.


chris