If that's the case, we have a set of information points available in an API called libdevinfo and there is a generic tool to view these nodes and their properties called prtconf. Certainly, target nodes are missing from the device tree and certainly switches do not exist there either. I only mention it because it is a very similar tool, though much more generic set of device information.
As Sumit pointed out, boundaries will be very difficult to define. I agree. Without knowing how each technology will consume underlying, existing or new subsystems, it's difficult to envision what will be important to an administrator when viewing the tree. It's being called a SCSI SAM filesystem but if it were purely SCSI, why are switches involved? Why would FC transport properties be involved? What happens when you end up running non-storage traffic through your so-called storage HBAs, like IPFC? Is the NIC a storage HBA or is it also responsible for HTTP traffic? We have tools that manage these storage transport protocols in a much more meaningful way than I believe we can ever hope to achieve with a single filesystem, CLI, etc. Sooner or later, the specifics of each storage transport need to be brought to light. When that is attempted in a single CLI (and I do really believe that is ultimately what this filesystem will end up looking like), it becomes complex and unwieldy, defeating the original purpose, which was simplicity. I think what we need, and what I believe we have been striving towards, is a more common approach to the various tools that we have such that, where possible, administrators can move between them and not feel as though they need to learn (and remember) a different set of commands and syntax for very similar operations. But when it comes to specifics for a particular subsystem, I believe the benefit of being able to intelligently communicate the semantics of that subsystem outweighs the benefit of remembering a single name, whether that is a root filesystem name or the name of a CLI. This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
