[Beaker-devel] Tool for Inventory gathering
Amit Saha
asaha at redhat.com
Tue Jul 9 05:32:53 UTC 2013
----- Original Message -----
> From: "Amit Saha" <asaha at redhat.com>
> To: "Beaker development" <beaker-devel at lists.fedorahosted.org>
> Sent: Monday, July 8, 2013 4:53:59 PM
> Subject: [Beaker-devel] Tool for Inventory gathering
>
> Hi all,
>
> I spent some time on Friday to see how the lshw based inventory task is doing
> by running on one of our test systems - both in terms of what it gets
> and how does it compare to the existing smolt based task.
>
> I didn't go far with the comparison. Why? Because, lshw's parsing script
> broke due to the XML being different for the particular CPU I was running on
> and what the parsing script was expecting. I could fix it (like I have done
> earlier) to accommodate for this formatting change..and do the same for
> similar errors when I come across one.
>
> But, here is what I am thinking:
>
> Why don't we just get rid of the smolt and lshw tasks and instead query
> directly from the /proc and /sys (procfs and sysfs)?
> I have done some exploration in this area [1] and [2]. In [1], I am reading
> directly off /proc and using Python's in built text
> processing methods to get the information I want. Today I explored using
> pyudev (Python interface to libudev for accessing the device
> attributes from /sys) which you can see in [2].
>
> From what I can see these are the information we usually look to get from our
> inventory task and how
> we could get them using one/both of the approaches (/proc and/or /sys):
>
> - CPU details (easily done by reading /proc/cpuinfo)
>
> - Memory details (easily done by reading /proc/memenfo)
>
> - Disk details (we could continue using libparted - we will need to deal with
> the shared library version choices that we currently have).
> The total size is easily gettable from /sys/block, but I don't see a way to
> get the geometry details.
>
> - Devices (Gettable from /sys/devices)
>
> What do you all think?
>
> Here are the links:
>
> [1] http://amitsaha.github.io/site/notes/articles/python_linux/article.html
> [2] http://nbviewer.ipython.org/5946601
>
> Best, Amit.
This morning, I spent some more time trying to see how much the Kernel exports into /proc and /sys
on non-x86 archs. I tried s390x, ppc64 and armv7hl. And the data exported is not a lot.
On s390x running a 2.6 kernel, /proc/cpuinfo doesn't even have the CPU frequency:
vendor_id : <masked>
# processors : 2
bogomips per cpu: 11061.00
features : <feature list masked>
processor 0: version = FF, identification = <masked>, machine = <masked>
processor 1: version = FF, identification = <masked>, machine = <masked>
(<masked> stands for original data masked)
For comparison, all 'lshw' comes up with is:
description: Computer
width: 64 bits
*-core
description: Motherboard
physical id: 0
*-memory
description: System memory
physical id: 0
size: 491MiB
*-cpu
physical id: 1
bus info: cpu at 0
*-network
description: Ethernet interface
physical id: 1
logical name: eth0
serial: 02:de:ad:be:ef:04
capacity: 1Gbit/s
capabilities: ethernet physical fibre 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=qeth_l2 driverversion=1.0 duplex=full firmware=V611 ip=<blah> link=yes multicast=yes port=fibre
This is not surprising, since it's probably a fair assumption to make that most user space utilities
would depend on what the Kernel is exporting.
Of course things could be different on more recent Kernels.
On the other hand, querying devices using udev (via pyudev) works fairly well
even on these archs.
--
Amit Saha <http://echorand.me>
Infrastructure Engineering and Development
Red Hat, Inc.
More information about the Beaker-devel
mailing list