Como o libusb acessa coisas do kernel?

10

Pelo que entendi:

De um modo geral, um driver é executado no espaço do kernel e pode ser chamado a partir do espaço do usuário.
Somente código no espaço do kernel pode chamar coisas de baixo nível usb / ioctl
libusb é uma biblioteca, portanto, compila e executa no espaço do usuário

Então, como libusbobter USB de baixo nível?

usb drivers

— Thomas
fonte

10

O Libusb é uma biblioteca para interagir com dispositivos USB da mesma maneira que a maldição é uma biblioteca para interagir com terminais de texto, o ALSA (mais precisamente seu componente libasound) é uma biblioteca para interagir com dispositivos audi, etc. O kernel lida com as interações de hardware. Ele fornece arquivos de dispositivos que as aplicações podem abrir para interagir com o hardware, através read, writee chamadas do sistema .ioctl

ioctl é uma chamada de sistema: permite que aplicativos (código no nível do usuário) emitam solicitações que são processos pelo kernel.

O Libusb permite que os aplicativos registrem funções de retorno de chamada que são executadas quando o dispositivo tem algo a relatar. Aqui está uma visão geral aproximada do fluxo de informações sob o capô:

O sinal elétrico no barramento dispara um evento no controlador USB.
O controlador USB gera um sinal de interrupção no processador principal.
O processador executa o manipulador de interrupção no kernel do sistema operacional.
Os avisos do kernel que um processo está atualmente em um bloqueio read, writeou ioctlchamada de sistema no arquivo de dispositivo e faz com que a chamada de sistema para retornar.
No processo de aterrissagem do usuário, quando a chamada do sistema retorna, o código da biblioteca é executado.
O código da biblioteca executa a função de retorno de chamada registrada pelo programador do aplicativo.

— Gilles 'SO- parar de ser mau'
fonte

então não há necessidade de escrever drivers de dispositivo para dispositivos USB? (a não ser talvez para otimização de velocidade)

— Thomas

@ Thomas Você precisa escrever um driver do kernel se quiser conectar-se a uma estrutura independente de transporte: teclado, armazenamento, ethernet etc. Caso contrário, acho que você só precisará de um driver se a latência de um programa da terra do usuário for muito alta.

— Gilles 'SO- stop be evil'

Se um dispositivo não for reconhecido pelo computador (não há driver para ele), libusbainda será possível acessá-lo?

— Thomas

@ Thomas Eu não sei se o libusb pode lidar com todos os aspectos do protocolo USB, mas, em princípio, sim. Um programa de usuário pode se comunicar com qualquer dispositivo serial RS232, via /dev/ttyS*. USB é o mesmo princípio, apenas mais rápido e mais complexo.

— Gilles 'SO- stop be evil'

3

O Linux usa dois anéis, anel 0 é chamado de nível de kernel, anel 3 é chamado de nível de usuário. A conexão do usuário ao kernel é feita (como já foi dito) via syscalls. Entre eles estão as bibliotecas, como podem ser vistas na terra do usuário. Portanto, o acesso de nível mais baixo ao kernel é implementado nas bibliotecas, por motivos de estabilidade, segurança, sincronização, economia de espaço, etc. O driver do kernel fornece interfaces diferentes para a terra do usuário: (ioctl, sysfs, soquetes, dispositivos de caracteres e blocos e assim por diante) Interfaces de espaço do usuário . Portanto, se desejar, você pode implementar seu acesso ao driver do kernel omitindo as bibliotecas ou compilar muito mais facilmente seu binário com bibliotecas vinculadas estáticas.

Um bom ponto de partida é ler as fontes do libusb, elas estão bem documentadas.

0

Ele usa syscalls (2) e arquivos de dispositivo preparados pelo kernel ( /dev/bus/usb/*)

— UVV
fonte

Então, tudo funciona como se o kernel fizesse um driver especial para dispositivos desconhecidos que aceitassem leituras e gravações? Como somos notificados de interrupções e assim por diante?

— Thomas