Accesso alla memoria del modulo del kernel

Due moduli del kernel diversi possono accedere alla stessa area di memoria da una chiamata a ioremap_nocache ()?

Ho un driver wireless e un modulo separato, vorrei che il modulo separato profilasse i valori di rumore sulla scheda, mentre il driver è ancora in funzione. Da qui la mia domanda sopra.

Una strada che ho esplorato è stata quella di avviare un thread del kernel dal driver, quindi ho implementato un semaforo per evitare qualsiasi condizione di competizione derivante da letture / scritture simultanee nello stesso spazio di indirizzi. Speravo che un thread figlio potesse accedere alla stessa area di memoria.

Purtroppo questo non ha funzionato come mi aspettavo. Gradirei qualsiasi suggerimento.

kernel

— Radagasp
fonte

Perché avresti bisogno di un modulo del kernel per profilare i valori di rumore?

— gertvdijk,

Grazie per la domanda, il driver wireless è molto complesso e, per alterarne la periodicità, le calibrazioni potrebbero indurre alcuni risultati indesiderati. Dovrei farlo poiché fa le sue calibrazioni solo per intervalli troppo lunghi per le mie esigenze. Poiché so esattamente come profilare il dispositivo in un modulo separato, sono solo curioso di sapere se riesco ad accedere alla stessa area di memoria con cui il driver sta lavorando.

— Radagasp,

Si prega di modificare la tua domanda per includere tutti i dettagli sui vostri precedenti tentativi / approcci. Ecco come funziona questo sito. Non è un forum di discussione, ma un sito di domande e risposte, vedi?

— gertvdijk,

La discussione può includere domande e risposte, alcune giuste e altre sbagliate - sembra che l'interpretazione delle regole tra gli amministratori, sia nella provincia della semantica. Ovviamente ho aggiornato la mia domanda.

— Radagasp,

Suppongo che tu intenda implementare un altro modulo del kernel poiché pensi che sia più facile condividere i dati tra i moduli del kernel. Ma forse non è una buona scelta. Se è possibile "profilare il rumore" nello spazio utente, penso che una soluzione migliore sia implementare il "profiler" nello spazio utente.

In questa soluzione, il profiler dello spazio utente legge i dati, esegue alcuni calcoli e quindi invia il risultato.

Se questa soluzione è ok, l'implementazione è la seguente.

Nel modulo del kernel, è solo per registrare un dispositivo char in '/ proc' e implementare le primitive 'read' e 'write'. Nello spazio utente, è solo quello di implementare il profiler, leggere e scrivere sul dispositivo char. Dettagli e informazioni per questa implementazione sono tutti qui .

— vitorafsr
fonte

Non credo di avere abbastanza la tua risposta ... a quanto ho capito, avrei comunque bisogno di scrivere un modulo, e questo modulo proverebbe ad accedere alla stessa area di memoria da una chiamata a ioremap_nocache () che l'altro il modulo sta usando. O stai dicendo che registro il dispositivo char nel modulo wireless

— Radagasp

Bene, dovrai implementare un software, ma non un modulo. Dovrai scrivere un normale programma per lo spazio utente, più semplice di un modulo, che legge da '/ dev / nameofdevice' e scrive su di esso. Non c'è bisogno di usare 'ioremap_nocache ()', solo syscalls come 'open', 'read', 'write', 'close'. E sì, il modulo wireless dovrà registrare il dispositivo char "/ dev / nameofdevice" all'interno, per esporre i dati a userland.

— vitorafsr,