8. lshw only shows the USB interfaces in the current configuration. I presume because the kernel only shows this information in /sys. However, lsusb is able to show the interfaces on all configuration descriptors (it queries using libusb). On Fri, Nov 10, 2017 at 2:19 PM, Don Zickus <dzickus@xxxxxxxxxx> wrote: > 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 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. >> >> 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. > > Cheers, > Don > > >> >> >> On Fri, Nov 10, 2017 at 12:38 PM, Jeremy Cline <jeremy@xxxxxxxxxx> 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: >> >>> https://github.com/lyonel/lshw/commit/135a853c60582b14c5b67e5cd988a8062d9896f4 >> >> >> >> And some beaker stuff looks interesting in >> >> >> >> https://github.com/lyonel/lshw/commit/f95aa917a84a8ee74ce79e9b4f9e198d21a2e4d9 >> >> >> >> 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@xxxxxxxxxx >> > IRC: jcline >> > >> _______________________________________________ >> kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
