Description of problem:

We now have a fork of 'lshw' at [1]. There are absolutely no tests in 'lshw' of any kind. As we start making 'lshw' ready for our inventory task, it makes sense to have a test suite which tests its functionality on different hardware.

[1] http://git.beaker-project.org/cgit/lshw/


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

One direction (also considering how we use 'lshw') is to present a particular hardware configuration to 'lshw' and match it's XML output to what is expected - thus helping prevent regressions, for one thing. 

Now, coming to the problem of how to provide this hardware configuration as input to 'lshw': 

A majority of lshw's functionality is implemented by directly reading information from procfs and sysfs. (However, functionalities such as those dealing with storage devices involve ioctl() calls). For at least the functionalities which read their info from the procfs and sysfs file systems, we can adopt an approach similar to utilities such as those part of the 'util-linux' package [2]. One of them, 'lscpu' (for example) has a switch '-s' to read a system snapshot instead of reading directly from the "live" system. 

A problem here is that the various files being read all hard coded in lshw. So, we would first need to make lshw ready for reading snapshots - adding a switch and perhaps have some conditionals using macros around all the places where it attempts to read from the system..or something like that which results in the minimum changes to the existing code.

[2] https://www.kernel.org/pub/linux/utils/util-linux/