ghw-snapshot: capture cpu, memory, topology data

[ffromani]

Needed for #66 (see #66 (comment) and following)

Add support to capture data ghw cares about in
/sys/system/devices/{cpu,node}.
With this patch, we can create snapshot we can reuse
to test the cpu, memory and topology packages using
the codeto consume snapshot added in commit 1a9fae7

There is quite a lot of opportunity to extract code
from ghw-snapshot and add it to the newly created snapshot
pkg, to make it easier to reuse and more testable.

This refactoring is deferred to a later change because
the new logic added is complex enough to stand in its own.

Signed-off-by: Francesco Romani fromani@redhat.com

[ffromani]

it seems ghw-snapshot is saving absolute (not relative) links for block devices pointing to the original scratchdir. This breaks block devices snapshot usage in my case.
Working on a fix, can be squashed in this PR or an additional one. Any preferences?
Same goes for snapshots: I'm collecting the promised reference snapshot from an handful systems I have access to, I can either push a followup PR or add here in the next few days. Of course they're going to be a bunch of blobs from git perspective.
I'd be happy to do whatever works best forreviewers!

[jaypipes]

it seems ghw-snapshot is saving absolute (not relative) links for block devices pointing to the original scratchdir. This breaks block devices snapshot usage in my case.

Yes, I did that on purpose after failing miserably with relative links :) The reason is because if you pass a directory containing relative links to Docker as a volume mount, Docker won't read the contents of the relative link (for security reasons). Docker considers a relative link to be simply a file that contains a string with a filepath in it:

moby/moby#1676

Working on a fix, can be squashed in this PR or an additional one. Any preferences?

I'd definitely be interested in your solution to this :) Please file a separate PR, though, as it will help for reviewing!

Best,
-jay

[ffromani]

it seems ghw-snapshot is saving absolute (not relative) links for block devices pointing to the original scratchdir. This breaks block devices snapshot usage in my case.

Yes, I did that on purpose after failing miserably with relative links :) The reason is because if you pass a directory containing relative links to Docker as a volume mount, Docker won't read the contents of the relative link (for security reasons). Docker considers a relative link to be simply a file that contains a string with a filepath in it:

moby/moby#1676\

Ah, darn, I added to this PR because I'm using the same approach I followed for /sys/devices/system/node/node0/cpu? (which symlink back to /sys/devices/system/cpu/cpu? :( I'll test with docker (and podman) then.

Working on a fix, can be squashed in this PR or an additional one. Any preferences?

I'd definitely be interested in your solution to this :) Please file a separate PR, though, as it will help for reviewing!

OK, so I already made a little mess so I'll stay put and wait for further instructions. Apologies!

[ffromani]

I think we have a good resolution onhttps://github.com//pull/205 - I will rebase this on top of it when we reach consensus.

[ffromani]

works, but forgot to snapshot the relevant content under /sys/devices/system/memory. Will update ASAP.

[ffromani]

updated! now the snapshot captures the /sys/devices/system/memory ghw cares about. Please note the example snapshot was removed from this PR. I'll add again shortly (in another PR) once I get access again to my test system.

[jaypipes]

++