-Another reason for libsysfs is it satisfies requirements the LTC RAS team has
-for getting current system device information. Rather than keeping tons of
-information in udev's in memory database, or even querying that database for
-the sysfs directory that will require storing extra reference info in memory,
-I've decided the RAS requirements can be fulfilled with a library atop sysfs.
-Sysfs contains devices currently on the system.
-
-Applications like the Error Log Analysis piece, for example, can query the
-sysfs library for device information. ELA gets specific information in an
-error message thanks to the dev_* and soon to be proposed netdev_* macros.
-One goal of the ELA is to gather as much information about an erroring device
-so service engineers and administrators can diagnose the problem. The ELA
-will get an error message with the bus id and driver name of the device. It
-will then need to query sysfs for other VPD information.
-
-I've used syfs in the name of libsysfs for a reason, I believe sysfs will be
-the device tree to use in the future. Until all VPD info is in sysfs, the
-library could also make use of /proc, sginfo, and other sources for device
-information under the covers so ELA and other applications don' t need to all
-have that knowledge.
-
-
-I'd like to know what everyone thinks about my proposal to split this all up
-into three separate subsystems. All comments are welcome.
-
-Thanks,
-
-Dan
-
-