<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 11, 2022 at 12:16 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/10/22 9:12 PM, enh via Toybox wrote:<br>
+ if (!TT.i) TT.i = CFG_TOYBOX_ON_ANDROID ? "/vendor/pci.ids" :<br>
+ "/usr/share/misc/pci.ids";<br>
<br>
Applied.</blockquote><div><br></div><div>thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Heads up that there's another one in lsusb.c.<br></blockquote><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My head scratch is I added the usb.ids one to /etc (because it seemed the<br>
obvious place for me to add it going back to Unix v7, alongside /etc/services),<br>
but the lspci contributor (Isaac Dunham) put it in /usr/share/misc presumably<br>
because the Linux Foundation's FHS said so. Which is a directory I don't even<br>
bother to create in mkroot...<br>
<br>
Either location is "policy". I just checked where busybox's lspci looks and the<br>
answer is "it doesn't". No support for a pci.ids file that I can spot. So no<br>
help there...<br>
<br>
Meanwhile, on Debian:<br>
<br>
$ ls -l /usr/share/misc/usb.ids<br>
lrwxrwxrwx 1 root root 25 Aug 3 2019 /usr/share/misc/usb.ids -><br>
/var/lib/usbutils/usb.ids<br>
<br>
So A) it's not consistent, B) they patch it with symlinks. Which one does strace<br>
say debian's lsusb is using...? Neither:<br>
<br>
readlink("/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/subsystem", "../<br>
../../../../../bus/usb", 1024) = 25<br>
openat(AT_FDCWD, "/run/udev/data/+usb:1-2:1.0", O_RDONLY|O_CLOEXEC) = 9<br>
fstat(9, {st_mode=S_IFREG|0644, st_size=102, ...}) = 0<br>
read(9, "I:743051238083\nE:ID_MODEL_FROM_DATABASE=Nexus 4/5/7/10<br>
(tether)\nE:ID_VENDOR_FROM_DATABASE=Google Inc.\n", 4096) = 102<br>
<br>
It's fetching cached data written out by whichever udev variant this system is<br>
using. Because of course it is.<br>
<br>
I think I want to move the non-android location to /etc for consistency. (FHS,<br>
like LSB, is an interesting point of reference but not a compelling<br>
well-maintained standard. Simple minimal system says /etc, not<br>
/usr/share/opt/local/thingy. Then again, I'm biased:<br>
<a href="http://landley.net/writing/hackermonthly-issue022-pg33.pdf" rel="noreferrer" target="_blank">http://landley.net/writing/hackermonthly-issue022-pg33.pdf</a> )<br>
<br>
Also, given that pci.ids is a megabyte and usb.ids is 3/4 of a megabyte, I think<br>
I want to let it read a .gz version if present because uncompressed that's a lot<br>
of initramfs ballast.<br>
<br>
(No, I am not adding a menuconfig item for this.)<br>
<br>
You know, I _could_ use find_in_path(), since it's already there in lib/lib.c:<br>
<br>
char *path = "/vendor:/etc:/usr/share/misc";<br>
struct string_list *sl;<br>
int fd = -1, pid = 0;<br>
<br>
if ((sl = find_in_path(path, "pci.ids.gz"))<br>
pid = xpopen((char *[]){"zcat", sl->str, 0}, &fd, 1);<br>
if (pid<1 && (sl = find_in_path(path, "pci.ids")))<br>
fd = xopen(sl->str, O_RDONLY);<br>
if (fd != -1) {<br>
FILE *fp = fdopen(fd);<br>
// read contents<br>
fclose(fp);<br>
}<br>
<br>
Hmmm... Might still need some CFG_ANDROID tests to avoid twigging weird selinux<br>
rules searching for nonexistent stuff?</blockquote><div><br></div><div>(i'm _guessing_ this would only be used interactively, so no-one cares?)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> (Android's not likely to want the gz<br>
version, Saving a megabyte is a rounding error there, it's probably on a<br>
compressed flash filesystem anyway, and keeping it be directly human readable<br>
may count as a slight win in that context. So it would check /etc and<br>
/usr/share/misc for pci.ids.gz before finding /vendor/pci.ids...)<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>(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!)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But if I do that I need to teach pci.ids to read the data into memory in one<br>
pass the way usb.ids does, or else it'll try to lseek() a pipe.<br></blockquote><div><br></div><div>(tbh, that was my first thought for rewriting this code anyway.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>