Como detectar programaticamente quando um dispositivo gera uma interrupção? ____ qstntxt _

Como detectar programaticamente quando um dispositivo gera uma interrupção? Isso pode acontecer quando um dispositivo é conectado ou desconectado.

E também neste caso: por exemplo: quando um dedo é segurado sobre um scanner de impressão digital, uma interrupção é levantada. Como detectar e possivelmente interceptar essa interrupção?

Eu quero escrever um aplicativo usando Gtkmm de modo que quando um evento ocorre como um CD sendo inserido ou um pendrive sendo conectado, eu pego a interrupção que esses dispositivos geram e uso para fazer algo no meu aplicativo, envolvendo esses dispositivos.

Se isso não puder ser feito em Gtkmm, posso interceptar a interrupção em um nível inferior e informar o aplicativo Gtkmm?

Eu estava verificando como o GParted se comporta. Inicialmente estava mostrando %code% e quando conectei meu pendrive, ele abriu automaticamente o aplicativo %code% . Quando chequei o GParted, o pendrive não estava presente no menu suspenso de dispositivos. Ele apareceu apenas quando eu selecionei “Refresh Devices” no menu do GParted ou `Ctrl` + `R` .

____ azszpr144883 _
%bl0ck_qu0te%
Não, essa é uma atividade espaço do kernel . Felizmente, o kernel reporta o resultado de certos eventos através de interfaces acessíveis a partir da userland.

É um pouco ambíguo em sua pergunta se você deseja detectar quando um dispositivo de bloco está conectado, ou quando um sistema de arquivos é montado (embora pareça ser mais o antigo). Se o seu sistema usa automontagem (eles geralmente fazem por padrão), ele montará sistemas de arquivos de dispositivos de bloco quando eles estiverem conectados, caso contrário você terá que fazê-lo manualmente (por exemplo, com %code% ).

De qualquer forma, você deseja pesquisar / analisar / varrer uma interface baseada no nó de arquivo do kernel. Eu fiz isso antes em um aplicativo (na verdade, um C ++ GTK) que rastreia os dispositivos de bloco conectados e os sistemas de arquivos montados via %code% e %code% . Este é um método simples e independente de linguagem. Algumas pessoas acham isso um pouco desagradável no início porque envolve a leitura de arquivos / diretórios, mas essas interfaces não existem no disco, portanto não há sobrecarga de E / S pesada e lembre-se: %code% é uma chamada do sistema. A leitura dos nós de arquivos nas interfaces do kernel equivale à mesma coisa que uma API de %code% style, exceto, novamente, que é independente de idioma. Quando você vai ler esses nós, o kernel passa as informações que eles representam diretamente.

O diretório %code% lista os dispositivos conectados como arquivos especiais do nó do dispositivo - por exemplo, %código%. Eles são adicionados e removidos pelo kernel à medida que os dispositivos são plugados e removidos, portanto, se você rastreá-lo pesquisando em intervalos (digamos, a cada 5 segundos), é possível detectar o que há de novo e o que foi. A única complicação aqui é que, como não há API de estilo de retorno de chamada, você precisa criar seu próprio thread para isso, se quiser uma verificação contínua (talvez porque %code% exige que você clique em %code% ).

Uma alternativa provavelmente melhor para %code% seria o material em %code% . Observe que há uma diferença significativa entre %code% e %code% (veja abaixo) ou %code% na medida em que os nós do último contêm informações sobre coisas como dispositivos, enquanto os nós em %code% é uma conexão real com o dispositivo (assim, se você verificar %code% , não se incomode em ler os arquivos individuais, apenas note que eles existem).

%code% now-a-days é um link simbólico (veja também a opção %code% em %code% ) codificar%; %code% é uma interface principal do kernel do canivete suíço (consulte %code% ). Isto lista sistemas de arquivos montados ; Se você usar a montagem automática, as coisas aparecerão e desaparecerão quando o material estiver conectado / desconectado. As informações em %code% e %code% geralmente estão na forma de texto ASCII, portanto, você pode examinar esses arquivos com %code% , etc e analisá-los com funções de sequência (fluxo).

O WRT para outros tipos de dispositivos, como um scanner de impressão digital, %code% é um bom lugar para começar - %code% contém um diretório %code% e um %code% . Dispositivos de bloco são geralmente armazenamento; as informações neles podem ser acessadas aleatoriamente . Dispositivos char trocam informações com o sistema em um fluxo, o que inclui coisas como scanners, câmeras, coisas HID (dispositivo de interface humana, por exemplo, mouses e teclados). Percebo que o gtkmm tem algumas coisas de alto nível para coisas HID anexadas, presumivelmente, uma vez que elas são significativas na interação com a GUI.

____ azszpr146272 _

Eu aprovo a resposta por %code% . Mas, em vez de usar a chamada do sistema %code% para verificar as alterações no sistema de arquivos, pode-se usar %code% .

Sua página man é aqui e aqui .

Há uma excelente explicação e exemplo dos criadores (desenvolvedores) de %code% aqui .

___

Question

Como detectar programaticamente quando um dispositivo gera uma interrupção? ____ qstntxt _

Como detectar programaticamente quando um dispositivo gera uma interrupção? Isso pode acontecer quando um dispositivo é conectado ou desconectado.

E também neste caso: por exemplo: quando um dedo é segurado sobre um scanner de impressão digital, uma interrupção é levantada. Como detectar e possivelmente interceptar essa interrupção?

Eu quero escrever um aplicativo usando Gtkmm de modo que quando um evento ocorre como um CD sendo inserido ou um pendrive sendo conectado, eu pego a interrupção que esses dispositivos geram e uso para fazer algo no meu aplicativo, envolvendo esses dispositivos.

Se isso não puder ser feito em Gtkmm, posso interceptar a interrupção em um nível inferior e informar o aplicativo Gtkmm?

Eu estava verificando como o GParted se comporta. Inicialmente estava mostrando %code% e quando conectei meu pendrive, ele abriu automaticamente o aplicativo %code% . Quando chequei o GParted, o pendrive não estava presente no menu suspenso de dispositivos. Ele apareceu apenas quando eu selecionei “Refresh Devices” no menu do GParted ou `Ctrl` + `R` .

____ azszpr144883 _
%bl0ck_qu0te%
Não, essa é uma atividade espaço do kernel . Felizmente, o kernel reporta o resultado de certos eventos através de interfaces acessíveis a partir da userland.

É um pouco ambíguo em sua pergunta se você deseja detectar quando um dispositivo de bloco está conectado, ou quando um sistema de arquivos é montado (embora pareça ser mais o antigo). Se o seu sistema usa automontagem (eles geralmente fazem por padrão), ele montará sistemas de arquivos de dispositivos de bloco quando eles estiverem conectados, caso contrário você terá que fazê-lo manualmente (por exemplo, com %code% ).

De qualquer forma, você deseja pesquisar / analisar / varrer uma interface baseada no nó de arquivo do kernel. Eu fiz isso antes em um aplicativo (na verdade, um C ++ GTK) que rastreia os dispositivos de bloco conectados e os sistemas de arquivos montados via %code% e %code% . Este é um método simples e independente de linguagem. Algumas pessoas acham isso um pouco desagradável no início porque envolve a leitura de arquivos / diretórios, mas essas interfaces não existem no disco, portanto não há sobrecarga de E / S pesada e lembre-se: %code% é uma chamada do sistema. A leitura dos nós de arquivos nas interfaces do kernel equivale à mesma coisa que uma API de %code% style, exceto, novamente, que é independente de idioma. Quando você vai ler esses nós, o kernel passa as informações que eles representam diretamente.

O diretório %code% lista os dispositivos conectados como arquivos especiais do nó do dispositivo - por exemplo, %código%. Eles são adicionados e removidos pelo kernel à medida que os dispositivos são plugados e removidos, portanto, se você rastreá-lo pesquisando em intervalos (digamos, a cada 5 segundos), é possível detectar o que há de novo e o que foi. A única complicação aqui é que, como não há API de estilo de retorno de chamada, você precisa criar seu próprio thread para isso, se quiser uma verificação contínua (talvez porque %code% exige que você clique em %code% ).

Uma alternativa provavelmente melhor para %code% seria o material em %code% . Observe que há uma diferença significativa entre %code% e %code% (veja abaixo) ou %code% na medida em que os nós do último contêm informações sobre coisas como dispositivos, enquanto os nós em %code% é uma conexão real com o dispositivo (assim, se você verificar %code% , não se incomode em ler os arquivos individuais, apenas note que eles existem).

%code% now-a-days é um link simbólico (veja também a opção %code% em %code% ) codificar%; %code% é uma interface principal do kernel do canivete suíço (consulte %code% ). Isto lista sistemas de arquivos montados ; Se você usar a montagem automática, as coisas aparecerão e desaparecerão quando o material estiver conectado / desconectado. As informações em %code% e %code% geralmente estão na forma de texto ASCII, portanto, você pode examinar esses arquivos com %code% , etc e analisá-los com funções de sequência (fluxo).

O WRT para outros tipos de dispositivos, como um scanner de impressão digital, %code% é um bom lugar para começar - %code% contém um diretório %code% e um %code% . Dispositivos de bloco são geralmente armazenamento; as informações neles podem ser acessadas aleatoriamente . Dispositivos char trocam informações com o sistema em um fluxo, o que inclui coisas como scanners, câmeras, coisas HID (dispositivo de interface humana, por exemplo, mouses e teclados). Percebo que o gtkmm tem algumas coisas de alto nível para coisas HID anexadas, presumivelmente, uma vez que elas são significativas na interação com a GUI.

____ azszpr146272 _

Eu aprovo a resposta por %code% . Mas, em vez de usar a chamada do sistema %code% para verificar as alterações no sistema de arquivos, pode-se usar %code% .

Sua página man é aqui e aqui .

Há uma excelente explicação e exemplo dos criadores (desenvolvedores) de %code% aqui .

___

#1 resposta do (3 votos)
#2 resposta do (0 votos)

4

Como detectar programaticamente quando um dispositivo gera uma interrupção? Isso pode acontecer quando um dispositivo é conectado ou desconectado.

E também neste caso: por exemplo: quando um dedo é segurado sobre um scanner de impressão digital, uma interrupção é levantada. Como detectar e possivelmente interceptar essa interrupção?

Eu quero escrever um aplicativo usando Gtkmm de modo que quando um evento ocorre como um CD sendo inserido ou um pendrive sendo conectado, eu pego a interrupção que esses dispositivos geram e uso para fazer algo no meu aplicativo, envolvendo esses dispositivos.

Se isso não puder ser feito em Gtkmm, posso interceptar a interrupção em um nível inferior e informar o aplicativo Gtkmm?

Eu estava verificando como o GParted se comporta. Inicialmente estava mostrando /dev/sda e quando conectei meu pendrive, ele abriu automaticamente o aplicativo files . Quando chequei o GParted, o pendrive não estava presente no menu suspenso de dispositivos. Ele apareceu apenas quando eu selecionei “Refresh Devices” no menu do GParted ou Ctrl + R .

devices linux signals interrupt

por user2555595 16.07.2014 / 16:34

2 respostas

0

Eu aprovo a resposta por goldilocks . Mas, em vez de usar a chamada do sistema read para verificar as alterações no sistema de arquivos, pode-se usar inotify .

Sua página man é aqui e aqui .

Há uma excelente explicação e exemplo dos criadores (desenvolvedores) de inotify aqui .

por 24.07.2014 / 08:06

Tags devices linux signals interrupt

Solaris 10 - É possível reinicializar um sistema a partir de um script de inicialização? pode ligar o tema da cor a um buffer?

score 3 · Accepted Answer

I can try to trap the Interrupt at a lower level and inform the gtkmm application.

Não, essa é uma atividade espaço do kernel . Felizmente, o kernel reporta o resultado de certos eventos através de interfaces acessíveis a partir da userland.

É um pouco ambíguo em sua pergunta se você deseja detectar quando um dispositivo de bloco está conectado, ou quando um sistema de arquivos é montado (embora pareça ser mais o antigo). Se o seu sistema usa automontagem (eles geralmente fazem por padrão), ele montará sistemas de arquivos de dispositivos de bloco quando eles estiverem conectados, caso contrário você terá que fazê-lo manualmente (por exemplo, com mount ).

De qualquer forma, você deseja pesquisar / analisar / varrer uma interface baseada no nó de arquivo do kernel. Eu fiz isso antes em um aplicativo (na verdade, um C ++ GTK) que rastreia os dispositivos de bloco conectados e os sistemas de arquivos montados via /dev/ e /etc/mtab . Este é um método simples e independente de linguagem. Algumas pessoas acham isso um pouco desagradável no início porque envolve a leitura de arquivos / diretórios, mas essas interfaces não existem no disco, portanto não há sobrecarga de E / S pesada e lembre-se: read() é uma chamada do sistema. A leitura dos nós de arquivos nas interfaces do kernel equivale à mesma coisa que uma API de listAttachedDevices() style, exceto, novamente, que é independente de idioma. Quando você vai ler esses nós, o kernel passa as informações que eles representam diretamente.

O diretório /dev lista os dispositivos conectados como arquivos especiais do nó do dispositivo - por exemplo, %código%. Eles são adicionados e removidos pelo kernel à medida que os dispositivos são plugados e removidos, portanto, se você rastreá-lo pesquisando em intervalos (digamos, a cada 5 segundos), é possível detectar o que há de novo e o que foi. A única complicação aqui é que, como não há API de estilo de retorno de chamada, você precisa criar seu próprio thread para isso, se quiser uma verificação contínua (talvez porque /dev/sda exige que você clique em gparted ).

Uma alternativa provavelmente melhor para Refresh Devices seria o material em /dev . Observe que há uma diferença significativa entre /sys/block e /dev (veja abaixo) ou /proc na medida em que os nós do último contêm informações sobre coisas como dispositivos, enquanto os nós em /sys é uma conexão real com o dispositivo (assim, se você verificar /dev , não se incomode em ler os arquivos individuais, apenas note que eles existem).

/dev now-a-days é um link simbólico (veja também a opção /etc/mtab em -s ) codificar%; man ln é uma interface principal do kernel do canivete suíço (consulte /proc/self/mounts ). Isto lista sistemas de arquivos montados ; Se você usar a montagem automática, as coisas aparecerão e desaparecerão quando o material estiver conectado / desconectado. As informações em /proc e man proc geralmente estão na forma de texto ASCII, portanto, você pode examinar esses arquivos com /proc , etc e analisá-los com funções de sequência (fluxo).

O WRT para outros tipos de dispositivos, como um scanner de impressão digital, /sys é um bom lugar para começar - cat contém um diretório /sys e um /sys/dev . Dispositivos de bloco são geralmente armazenamento; as informações neles podem ser acessadas aleatoriamente . Dispositivos char trocam informações com o sistema em um fluxo, o que inclui coisas como scanners, câmeras, coisas HID (dispositivo de interface humana, por exemplo, mouses e teclados). Percebo que o gtkmm tem algumas coisas de alto nível para coisas HID anexadas, presumivelmente, uma vez que elas são significativas na interação com a GUI.