On Fri, Nov 10, 2017 at 01:17:50PM -0500, Nathaniel McCallum wrote:
The more I look at lshw, the more I'm ambivalent (I'm not
just not for it either). It certainly collects a lot of relevant
information. However, I see the following problems.
1. lshw tries to make things human readable. This is bad for
databases. We want to record things like immutable numeric hardware
IDs rather than the current contents of pci.ids. lshw does provide
-numeric, but this just adds the numbers to the human readable
2. lshw collects a lot of data we may not be interested in. For
example, it reports the four different kinds of floppy disk drives my
BIOS supports. Also, L1, L2 and L3 cache. There is a bunch of stuff
like this. Is it useful? Some of it definitely is. But transferring
unwanted data over the wire is not being a good netizen. Also, some
people pay for data per MB transferred. We should be respectful.
3. lshw supports '-sanitize', but this merely replaces the values with
'[REMOVED]'. See above for why we don't want to transmit this data.
4. lshw reports bus configuration. I'm not sure if this is relevant or
how we would want to map this data. For example, if Dell uses the same
hardware in a bunch of laptops then we can deduplicate this to one
"hardware profile." But if bus configuration is part of this profile,
then we will have much higher cardinality. If this information is
important to have, we can make it work. But if not, it would be better
to try to save storage.
5. lshw doesn't seem to have a way to separate "system hardware" from
"transient hardware." To be fair, this may be impossible. But it would
be nice to understand the difference between, say, my bluetooth radio
and my YubiKey. I can't easily remove the former but I can the latter.
This also goes to cardinality reduction.
6. lshw mixes things that are transient with things that are
permanent. We can remove the timestamps with -notime. But, for
example, it reports the kernel module currently assigned to a piece of
hardware. This is probably relevant information, but we will have to
carefully separate the data based on its lifespan.
7. lshw reports virtual NICs as physical ones. We probably don't care
about this and I certainly don't want to bloat the database with
everyone's docker subnets unnecessarily.
Again, I was just pointing out a tool we use internally for inventorying our
hardware that I thought might be useful. If it doesn't work for you, feel
free to choose something else. :-) I do appreciate the feedback you
provided. I might work with folks on my team to address some of them as
they could be of benefit for our work too.
> On Fri, Nov 10, 2017 at 12:38 PM, Jeremy Cline <jeremy(a)jcline.org> wrote:
> > On 11/09/2017 09:12 AM, Don Zickus wrote:
> >> On Wed, Nov 08, 2017 at 05:02:05PM -0500, Nathaniel McCallum wrote:
> >>> It isn't documented in F27, but it does work. However, we probably
> >>> want at least this patch:
> >> And some beaker stuff looks interesting in
> >> Regardless. My overall point was the lshw tool seems to embody a lot of
> >> what you were looking for and thought it could be useful (with some more
> >> fixes) instead of re-inventing the wheel with new plugins. :-)
> >> Up to you guys.
> > I have no desire to re-invent wheels so I think it makes sense for us to
> > use lshw. Knowing it's being used internally is also good.
> > --
> > Jeremy Cline
> > XMPP: jeremy(a)jcline.org
> > IRC: jcline
> kernel mailing list -- kernel(a)lists.fedoraproject.org
> To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org