[Toybox] [PATCH] lspci: use a different default location for pci.ids on Android.

[enh]

On Fri, Feb 11, 2022 at 12:16 AM Rob Landley <rob at landley.net> wrote:

> On 2/10/22 9:12 PM, enh via Toybox wrote:
> +    if (!TT.i) TT.i = CFG_TOYBOX_ON_ANDROID ? "/vendor/pci.ids" :
> +        "/usr/share/misc/pci.ids";
>
> Applied.


thanks!


> 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.)


> My head scratch is I added the usb.ids one to /etc (because it seemed the
> obvious place for me to add it going back to Unix v7, alongside
> /etc/services),
> but the lspci contributor (Isaac Dunham) put it in /usr/share/misc
> presumably
> because the Linux Foundation's FHS said so. Which is a directory I don't
> even
> bother to create in mkroot...
>
> Either location is "policy". I just checked where busybox's lspci looks
> and the
> answer is "it doesn't". No support for a pci.ids file that I can spot. So
> no
> help there...
>
> Meanwhile, on Debian:
>
> $ ls -l /usr/share/misc/usb.ids
> lrwxrwxrwx 1 root root 25 Aug  3  2019 /usr/share/misc/usb.ids ->
> /var/lib/usbutils/usb.ids
>
> So A) it's not consistent, B) they patch it with symlinks. Which one does
> strace
> say debian's lsusb is using...? Neither:
>
> readlink("/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/subsystem",
> "../
> ../../../../../bus/usb", 1024) = 25
> openat(AT_FDCWD, "/run/udev/data/+usb:1-2:1.0", O_RDONLY|O_CLOEXEC) = 9
> fstat(9, {st_mode=S_IFREG|0644, st_size=102, ...}) = 0
> read(9, "I:743051238083\nE:ID_MODEL_FROM_DATABASE=Nexus 4/5/7/10
> (tether)\nE:ID_VENDOR_FROM_DATABASE=Google Inc.\n", 4096) = 102
>
> It's fetching cached data written out by whichever udev variant this
> system is
> using. Because of course it is.
>
> I think I want to move the non-android location to /etc for consistency.
> (FHS,
> like LSB, is an interesting point of reference but not a compelling
> well-maintained standard. Simple minimal system says /etc, not
> /usr/share/opt/local/thingy. Then again, I'm biased:
> http://landley.net/writing/hackermonthly-issue022-pg33.pdf )
>
> Also, given that pci.ids is a megabyte and usb.ids is 3/4 of a megabyte, I
> think
> I want to let it read a .gz version if present because uncompressed that's
> a lot
> of initramfs ballast.
>
> (No, I am not adding a menuconfig item for this.)
>
> You know, I _could_ use find_in_path(), since it's already there in
> lib/lib.c:
>
>   char *path = "/vendor:/etc:/usr/share/misc";
>   struct string_list *sl;
>   int fd = -1, pid = 0;
>
>   if ((sl = find_in_path(path, "pci.ids.gz"))
>     pid = xpopen((char *[]){"zcat", sl->str, 0}, &fd, 1);
>   if (pid<1 && (sl = find_in_path(path, "pci.ids")))
>     fd = xopen(sl->str, O_RDONLY);
>   if (fd != -1) {
>     FILE *fp = fdopen(fd);
>     // read contents
>     fclose(fp);
>   }
>
> Hmmm... Might still need some CFG_ANDROID tests to avoid twigging weird
> selinux
> rules searching for nonexistent stuff?


(i'm _guessing_ this would only be used interactively, so no-one cares?)


> (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.

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. 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!)


> 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.)


> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220211/53ad8cf4/attachment-0001.htm>