Devd event from GEOM?

[Poul-Henning Kamp]

In message <Pine.NEB.3.96L.1050125150800.3036C-100000 at fledge.watson.org>, Robert Watson writes:

>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.

GEOM already has its own mechanism, and given the diversity of what geom
classes can do, I don't think trying to shoehorn it into a newbus like
view makes sense.

>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.

Right.  IMO we just need devfs to add "And here is a thing you can access".

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.