Есть ли какая-либо замена для 'lspci'?

[116270] Файл [116827]/proc/bus/pci/devices[116828] может помочь:[12220]Папка [116829]/sys/bus/pci/devices[116830] имеет еще больше деталей, но распространена шире...[116273].

[116300]Вы можете получить аналогичную информацию из файловой системы sysfs в разделе (например) [116847]/sys/device/pci0000:00[116848]; также в разделе [116849]/sys/class/pci_bus[116850] имеется сим-ссылка. Сначала я расскажу об этом, так как он предоставляет некоторые подсказки о соответствии вывода [116851]lspci[116852], которые вы можете изучить на системе, имеющей lspci, чтобы ознакомиться с ними. [12232]Вот некоторые отредактированные результаты [116853]lscpi[116854]:[12233]Заметка [116855]00:1c.[116856] имеет .3,.4,.6, и .7, а также 03:00.0, 04:00.0, 06:00.0 и 07:00.0. Они соответствуют -- более поздние являются устройствами, прикрепленными к первым. Симлинки в [116857]/sys/class/pci_bus[116858] указывают на узлы в [116859]/sys/devices/pci0000:00[116860] вот так:[12234]Вам не нужно слишком много думать об этом, если вы просто хотите получить информацию о том, что там есть, но я упоминаю об этом, потому что эти соответствия могут запутаться по отношению к выводу [116861]lspci[116862]. Внутри этих узлов (это каталоги) находится файл с именем [116863]subsystem_device[116864], который в текстовом виде содержит 16-битный (4-значный) шестнадцатеричный (4-значный) hex-код, например [116865]0x84ca[116866]. Подобные шестнадцатеричные коды есть в [116867]subsystem_vendor[116868] и [116869]device[116870], но более поздний из них нам бесполезен (n.b. это [116871]не[116872] идентификатор устройства, предоставляемый устройством, это метка внутри системы), а первый не достаточно конкретен (но он все же может быть полезен, см. ниже). [12236] Поскольку список этих кодов предположительно постоянно растет, хорошим местом для их поиска является онлайновая база данных [116873] [116874]. Чтобы получить список всех этих кодов из примера:[12237]я избежал здесь симлинкованных каталогов, чтобы использовать [117075]find[117076].[116876] Обратите внимание, что 0x084ca многократно повторяется. Просмотрев это через "Поиск устройств" в базе данных, вы увидите, что это "450NX PCIet Memory & I/O Controller" от Intel. Причина, по которой он так часто повторяется, заключается в том, что в него подключены другие устройства. [12238] Вместо того, чтобы рассматривать все это, давайте сделаем краткий обзор, чтобы выяснить, что такое мой беспроводной контроллер. [116877]/sys/class/net[116878] перечисляет 3 симлинки:[12239]Соответствующие названиям меток, используемых, например, в выводе [116879]ifconfig[116880]. [116881]wlp6so[116882] ссылки на [116883]pci0000:00/0000:00:1c.6/0000:06:00.0/net/wlp6s0[116884], но это не поможет нам идентифицировать устройство. В дереве есть два узла [116885]subsystem_device[116886], корни которых уходят в [116887]pci0000:00/0000:00:1c.6. [116888], первый - [116889]0x84ca[116890] (снова контроллер) и один - в [116891]0000:06:00.0[116892], [116893]0x850d[116894].[12240] Здесь мы сталкиваемся с реальностью пропущенных записей в БД. Там есть форма, в которую вы можете отправить информацию для добавления, но, конечно, это нам сейчас не помогает.[12241]Поиск в режиме онлайн "pci 0x850d" обнаруживает [116895]ссылку на источник ядра linux[116896],[116897]1[116898], так как ядро использует эти коды для загрузки соответствующих драйверов. Это говорит нам о том, что (это wifi чип, якобы от ASUSTEK) мы могли бы вывести другим способом, а именно, посмотрев на узел [116899]subsystem_vendor[116900] в том же каталоге (Asustek оказывается в онлайн-базе данных при выполнении "Vendor search:" для 0x1043) и учитывая, что это относится к wifi интерфейсу. [116901]2[116902] Также есть подсказка о том, что OEM (производитель оригинального оборудования) является Atheros, так как это исходный код драйвера ath9k -- и действительно, [116903]lscpi[116904] перечислен [116905]06:00[116906] как "Сетевой контроллер": Qualcomm Atheros AR9485 Беспроводной сетевой адаптер (rev 01)".[12242]Не глядя на источник для [116907]lscpi[116908], я бы предположил, что он запрашивает устройства непосредственно для строки. Вероятно, ядро этого не делает, так как для загрузки драйверов использует уникальный идентификатор устройства, а информация ему не нужна.[12243]1. Лучшим местом для поиска, исходя из этого открытия, было бы использование [117077]grep -R[117078] в каталоге [117079]драйверов/[117080] дерева исходных текстов ядра. Если вы не можете его найти, то драйвера для него все равно нет.[12244]2. Конечно, это было бы не так очевидно, если бы ни один драйвер не был загружен и интерфейс не работал, но ID всё равно будет в [117081]/sys/devices/...[12245]