> I thought the bus walk was to find a leaf in a hierarchy of devices, where > the bus is a top node of the devices on the bus. Ie, like "i8042:kbd" etc. > But that might be pure fiction, I never really groked the way devices are > organized in oskit.
That is right, it's a tree where the non-leaf nodes are called busses. Stick a call to oskit_dump_devices(); in after the probe in an oskit kernel, and it will show you the whole tree. Some of the example kernels do this. In oskit-mach, we only probe on demand in device lookup, so you'd have to insert an early oskit_bus_probe (osenv_rootbus_getbus ()); call to see anything from oskit_dump_devices. The probe happens in oskit_bus_walk_lookup (or bus_walk_from_compat_string), the first time device_open is done on something other than "console", "kmsg", "time", or "mem". The silly "bus device" interface in oskit/ds_bus.c lets you do the dump yourself from the Hurd, e.g. "storecat -Tdevice @" to see the root bus. That produces a silly syntax that is reasonably understandable from looking at it, and should be trivially machine-parseable. >From there you can see each of the busses (pci, ide or scsi controllers, etc) and with "storecat -Tdevice @pci" or whatever you can follow each node and walk the tree yourself. Once you look at the tree, and read oskit/unsupported/bus_walk_lookup.c for the big comment at the start about the bus-walk syntax, I think it will all make sense. I added the ds_bus.c hack as a minimal kludge interface for the kernel to report device information that could be used to write a user-level device manager thingie as a translator for a virtual filesystem or whatever you like. For user-level drivers, such a program would be the central server for managing hardware io resources and such. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
