On Tue, Feb 14, 2006 at 10:10:27PM +0700, Robert Elz wrote:
> There has been talk, at various stages, of a method that should
> be developed to allow the actual drives (spindles) that underly
> a filesystem (device upon which a filesystem may reside) to
> be located.
...
> The code below is woefully incomplete - I have no idea how to find the
> component devices of a raidframe, so that part is all missing.  I also
> have no idea how to find the device that (eventually) backs the space
> under a vnd, so that part is missing as well.  ccd should be more or less
> OK however, as should wd and sd (other devices I didn't bother with,
> that's just more copies of the same basic code).

one other issue with the sample implementation is that the uncontrolled
recursion through VOP_IOCTL could result in running off the end of the
kernel stack if the storage configuration is highly nested.  it would be
better to have each driver just add its immediate child devices/files/whatever
to a list of components that need to be examined and have a higher-level
routine do the iteration over the list, transferring a component to a separate
list of components already examined after that component's immediate children
are retrieved.  (or in the style of your example, copying the name of the
component out to the return buffer rather than keeping it on a list in the
kernel.  you get the idea.)

-Chuck