Re: Devd event from GEOM?

On Tue, 25 Jan 2005, M. Warner Losh wrote:

> In message: <1106663905.35846.10.camel_at_shumai.marcuscom.com>
>             Joe Marcus Clarke <marcus_at_marcuscom.com> writes:
> : And how would I map those devices to a bus?  Speaking with Linux HAL in
> : mind, I would like to see storage devices added to devinfo.  It would be
> : great, IMHO, to see da0 attached to uhub2 on usb2 on ehci2 when walking
> : devinfo.
> 
> That's part of the problem.  CAM doesn't use newbus attachments.  IT
> should. 

For physical devices, it appears there isn't much argument against newbus
attachments, other than someone implementing it -- since this isn't really
my area, I'll leave that discussion (and ideally, coding :-) for someone
else.

The interesting question becomes how you map between levels of
abstraction: many consumers of device event information don't really care
about the device and the route by which messages get to it from the CPU. 
They care about the abstraction layered over the device, and the events
that occur in relating one object in an abstraction to another object,
perhaps involving topologies that have little to do with the physical
device topology.  This raise the questions as to whether the newbus
topology is really the most useful place to expose information like GEOM
slicing, volume management of disk devices, and ethernet bonding for
devices that may be physically discovered using newbus.  And even if we
can shove all the available object topologies into newbus, we'd also start
bumping into how to represent all the interesting event types in newbus.
One appealing thing to the current devd protocol design is that different
abstraction layers (classes) can define their own event name spaces, and
each abstraction layer can declare the events it knows about.  newbus
announces "I found a route to a physical device", GEOM shouts "And I found
some storage space on it", etc.

Robert N M Watson