On 11/10/2017 01:17 PM, Nathaniel McCallum wrote: > The more I look at lshw, the more I'm ambivalent (I'm not against it, > 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 > strings. That seems like it would be a good improvement for upstream. > 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. These three issues seem easily solvable by some client-side filtering before sending it to the server. > 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. That does sound nice and I don't know whether or not it is possible, but it doesn't sound unique to lshw and if there's a solution I imagine lshw would like to have it. > 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. I think we'll want the module information. I do agree we need to think carefully about how to model the data. Generally, I agree that lshw isn't perfect, but it seems like there's a lot of value in it and we can help improve it where it makes sense. Where it doesn't make sense, we can easily manipulate and supplement the data client-side. Of course, my opinion may change dramatically once we actually implement this :) -- Jeremy Cline XMPP: jeremy@xxxxxxxxxx IRC: jcline
_______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
