Acesso à memória do módulo do kernel

Dois módulos de kernel diferentes podem acessar a mesma área de memória de uma chamada para ioremap_nocache ()?

Eu tenho um driver sem fio e um módulo separado. Gostaria que o módulo separado fizesse o perfil dos valores de ruído na placa, enquanto o driver ainda estivesse em operação. Daí a minha pergunta acima.

Uma avenida que eu explorei foi iniciar um thread do kernel a partir do driver e, em seguida, implementei um semáforo para evitar qualquer condição de corrida decorrente de leitura / gravação simultânea no mesmo espaço de endereço. Eu esperava que um thread filho pudesse acessar a mesma área de memória.

Infelizmente, isso não funcionou como eu esperava. Gostaria muito de receber sugestões.

kernel

— Radagasp
fonte

Por que você precisaria de um módulo do kernel para analisar os valores de ruído?

— precisa saber é

Obrigado pela pergunta, o driver sem fio é muito complexo e, para alterar a periodicidade das calibrações, pode induzir alguns resultados indesejados. Eu precisaria fazer isso, pois ele só faz suas calibrações para intervalos que são muito longos para minhas necessidades. Como sei exatamente como criar o perfil do dispositivo em um módulo separado, estou curioso para saber se posso obter acesso à mesma área de memória com a qual o driver está trabalhando.

— Radagasp 28/01

Por favor edite sua pergunta para incluir todos os detalhes sobre suas tentativas anteriores / abordagens. É assim que este site funciona. Não é um fórum de discussão, mas um site de perguntas e respostas, entende?

— precisa saber é o seguinte

A discussão pode incluir perguntas e respostas, algumas certas e outras erradas - parece que a interpretação das regras entre os administradores está na província da semântica. Claro que atualizei minha pergunta.

— Radagasp

Suponho que você pretende implementar outro módulo do kernel, pois considera mais fácil compartilhar dados entre os módulos do kernel. Mas talvez não seja uma boa escolha. Se for possível 'analisar o ruído' no espaço do usuário, acho que uma solução melhor é implementar o 'profiler' no espaço do usuário.

Nesta solução, o criador de perfil de espaço do usuário lê dados, realiza alguns cálculos e envia o resultado.

Se esta solução estiver correta, a implementação é a seguinte.

No módulo do kernel, é apenas para registrar um dispositivo char em '/ proc' e implementar as primitivas 'leitura' e 'gravação'. No espaço do usuário, é apenas para implementar o criador de perfil, lendo e gravando no dispositivo char. Detalhes e informações para esta implementação estão todos aqui .

— vitorafsr
fonte

Acho que não recebi sua resposta ... como eu a entendo, ainda precisaria escrever um módulo, e esse módulo tentaria obter acesso à mesma área de memória de uma chamada para ioremap_nocache () que o outro módulo está usando. Ou você está dizendo que eu registrar o dispositivo de char no módulo wireless

— Radagasp

Certo, você terá que implementar um software, mas não um módulo. Você precisará escrever um programa de espaço do usuário normal, mais simples que um módulo, que leia '/ dev / nameofdevice' e grave nele. Não é necessário usar 'ioremap_nocache ()', apenas syscalls como 'open', 'read', 'write', 'close'. E sim, o módulo sem fio terá que registrar o dispositivo char '/ dev / nameofdevice' dentro, para expor os dados à terra do usuário.

— vitorafsr