Você pode obter informações semelhantes do sistema de arquivos sysfs sob (por exemplo) /sys/device/pci0000:00 ; existe também um link simbólico em /sys/class/pci_bus . Vou discutir isso primeiro, já que ele fornece algumas pistas sobre as correspondências com lspci output que você pode examinar em um sistema que possui lspci para se familiarizar.
Veja algumas saídas lscpi editadas:
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09)
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4)
00:1c.4 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c4)
00:1c.6 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 7 (rev c4)
00:1c.7 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 8 (rev c4)
03:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)
04:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 03)
06:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)
07:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
Observe que 00:1c. tem .3, .4, .6 e .7, e também há 03: 00.0, 04: 00.0, 06: 00.0 e 07: 00.0. Estes correspondem - os mais atrasados são os dispositivos anexados ao anterior. Os links simbólicos em /sys/class/pci_bus apontam para nós em /sys/devices/pci0000:00 da seguinte forma:
0000:03 -> 0000:00:1c.3
0000:04 -> 0000:00:1c.4
0000:06 -> 0000:00:1c.6
0000:07 -> 0000:00:1c.7
Você não precisa pensar muito sobre isso se quiser apenas informações sobre o que está lá, mas menciono isso porque essas correspondências podem ficar confusas em relação à saída lspci .
Dentro desses nós (eles são diretórios), você encontrará um arquivo chamado subsystem_device , que contém um código hexadecimal de 16 bits (4 dígitos) em formato de texto, por exemplo, %código%. Existem códigos hexadecimais semelhantes em 0x84ca e subsystem_vendor , mas o último não serve para nós (não é não um ID de dispositivo fornecido pelo dispositivo, é um rótulo interno ao sistema ) e o primeiro não é específico o suficiente (mas ainda pode ser útil, veja abaixo).
Como a lista desses códigos provavelmente cresce o tempo todo, um bom lugar para consultá-los é um banco de dados on-line . Para obter uma lista de todos os exemplos do exemplo:
> find /sys/devices/pci0000:00 -name subsystem_device -exec cat '{}' \;
0x84ca
0x84ca
0x84ca
0x84ca
0x84ca
0x849c
0x84ca
0x84fb
0x84ca
0x84b7
0x84ca
0x1080
0x84ca
0x850d
0x84ca
0x8488
0x84ca
0x84ca
0x84ca
0x84ca
0x84ca
Eu evitei os diretórios com links simbólicos aqui para usar device . Aviso 0x084ca é repetido muito. Olhando para cima através de "Device Search" no banco de dados revela que este é um "450NX PCIset Memory & I / O Controller" da Intel. A razão pela qual se repete tanto é porque as outras coisas estão ligadas a ele.
Em vez de seguir todas essas etapas, vamos dar um atalho para descobrir qual é o meu controlador de wifi. find lista 3 links simbólicos:
em1
lo
wlp6so
Correspondente aos nomes dos rótulos usados em, por exemplo, /sys/class/net output. ifconfig links para wlp6so , mas isso não nos ajuda a identificar o dispositivo. Há dois pci0000:00/0000:00:1c.6/0000:06:00.0/net/wlp6s0 nós na árvore com raiz em subsystem_device , o primeiro é pci0000:00/0000:00:1c.6 (o controlador novamente) e um no 0x84ca , 0000:06:00.0 .
É aqui que nos deparamos com a realidade de entradas ausentes no banco de dados. Existe um formulário que você pode enviar informações para adicionar a ele, mas é claro que isso não nos ajuda agora.
Uma pesquisa online por "pci 0x850d" mostra uma referência à fonte do kernel do Linux , 1 desde que o kernel use esses códigos para carregar os drivers apropriados. Isso nos diz algo (é um chip wifi, aparentemente da ASUSTEK) que poderíamos ter deduzido de outra forma, ou seja, olhando para o nó 0x850d no mesmo diretório (a Asustek está no banco de dados online quando você faz um "Vendor" search: "para 0x1043) e considerando que isso se refere à interface wifi. 2 Há também uma pista sobre o OEM (fabricante do equipamento original) ser Atheros, já que este é o código-fonte do driver ath9k - - e, de fato, subsystem_vendor listou lscpi como "Controlador de rede: Adaptador de rede sem fio Qualcomm Atheros AR9485 (rev 01)".
Sem olhar a fonte para 06:00 , eu presumo que ela consulta os dispositivos diretamente por uma string. O kernel provavelmente não faz isso, pois usa o ID do dispositivo exclusivo para carregar os drivers e as informações não são úteis para ele.
1. Um lugar melhor para procurar, com base nessa descoberta, seria usar lspci no diretório grep -R da árvore de origem do kernel. Se você não conseguir encontrá-lo, não há driver para isso de qualquer maneira.
2. É claro que isso não seria tão óbvio se nenhum driver fosse carregado e a interface estivesse inativa, mas o ID ainda estaria em drivers/