On 2/11/22 1:29 PM, enh wrote: > Heads up that there's another one in lsusb.c. > > thanks, but we may as well wait until someone has a specific use case. > (although > it's unfortunate that there's no workaround with lsusb to specify a path like > there is with lspci.)
Just noticed the discrepancy last email. :) > (Android's not likely to want the gz > version, Saving a megabyte is a rounding error there, it's probably on a > compressed flash filesystem anyway, and keeping it be directly human > readable > may count as a slight win in that context. So it would check /etc and > /usr/share/misc for pci.ids.gz before finding /vendor/pci.ids...) > > well, that's part of the background for why the patch says /vendor --- the > assumption is that no-one wants to pay to ship a pci id database, and even the > one user i have is for the virtualized cuttlefish stuff, not for an actual > device, and even they seem to just have a database with the pci ids they care > about, rather than a full database. Simple gzip brings them down to ~250k each. xz brings them down to 201 and 189 but I learn towards just gzip because it's fast and cheap and I've got decompression code for that built-in already. I even already wrote most of the compressor but got derailed trying to make it match other gzip implementations' output for sha3sum reasons. (Mostly a question of when to do dictionary resets, and knowing when to use the builtin dictionary vs the calculated one. Alas, not things the RFC covers...) > in a sense you're right, that this is small (compared to, say, a sample > wallpaper or whatever), but the pressure in the other direction is that it's a > lot easier to justify space for user-visible stuff like wallpapers (even if > most > users don't use most wallpapers) than it is for a database of debugging info. > > (i haven't yet checked, but i'm curious whether this database code actually > works? the cuttlefish folks seem to think it does, but that might be because > they have a cut down database? i did test this quickly on my laptop last night > but got seemingly nonsense results. Hmmm... $ toybox lspci 00:1f.2 Class 0106: 02a PCI Hotplug Controller A:1e03 00:1c.0 Class 0604: 02a PCI Hotplug Controller A:1e10 00:1f.0 Class 0601: 02a PCI Hotplug Controller A:1e55 02:00.0 Class 0280: 02a PCI Hotplug Controller A:0087 0b:00.0 Class 0805: EN-1217 Ethernet Adapter:8221 00:1c.5 Class 0604: 02a PCI Hotplug Controller A:1e1a 00:16.0 Class 0780: 02a PCI Hotplug Controller A:1e3a 00:1b.0 Class 0403: 02a PCI Hotplug Controller A:1e20 00:1c.3 Class 0604: 02a PCI Hotplug Controller A:1e16 00:19.0 Class 0200: 02a PCI Hotplug Controller A:1502 00:1f.3 Class 0c05: 02a PCI Hotplug Controller A:1e22 00:00.0 Class 0600: 02a PCI Hotplug Controller A:0154 00:1c.1 Class 0604: 02a PCI Hotplug Controller A:1e12 00:1a.0 Class 0c03: 02a PCI Hotplug Controller A:1e2d 00:1d.0 Class 0c03: 02a PCI Hotplug Controller A:1e26 00:02.0 Class 0300: 02a PCI Hotplug Controller A:0166 00:14.0 Class 0c03: 02a PCI Hotplug Controller A:1e31 00:1c.2 Class 0604: 02a PCI Hotplug Controller A:1e14 No, it does not. I'll have a go... > it wasn't obvious to me how the loop through > the file is actually taking into account the indentation level that's actually > meaningful for the database? at least for the full database i have on my > laptop... i might rewrite it one weekend, but i should probably find the time > to > send you my gpiod.c and my strace fixes that have been lying around on my > raspberry pi for months first!) I have recently cleared more time to work on this, as you know. :) > But if I do that I need to teach pci.ids to read the data into memory in > one > pass the way usb.ids does, or else it'll try to lseek() a pipe. > > (tbh, that was my first thought for rewriting this code anyway.) Indeed. I'd forgotten that lspci already had database reading code when I added it to lsusb. The two file formats actually look identical, except that pci.ids has a third indentation level. Should be easy to get them to share code... Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net