2011-10-12 19 views
7

Sto facendo un piccolo modulo del kernel per fornire accesso allo spazio utente ad alcune funzionalità in modalità kernel di un chip ARMv7 (in particolare, controllo della cache). Sto leggendo tramite Driver di dispositivo Linux di Corbet, Rubini e Hartman. In esso descrivono come realizzare un driver + dispositivo + bus completo. Non voglio affatto creare un autista di autobus. In effetti, il "driver" che sto creando non ha assolutamente bisogno di corrispondere alla definizione di un dispositivo - è implicitamente abbinato alla CPU della piattaforma. Qualcuno può spiegare a me:Accesso al driver Linux tramite sysfs

  1. Dove in sysfs dovrebbe miei attributi andare? Dovrebbe essere nella mia voce modulo sotto /sysfs/modules/mymodule? Anche /sys/devices/platform sembra essere promettente, così come /sys/devices/system/cpu.
  2. Se esiste un luogo in cui dovrei inserire i miei attributi kobject/come collegarlo? Come ottengo il necessario kset? Tutti gli esempi che ho visto creano un kset e quindi collegano ad esso dal kobject - Non ho visto un'API per richiedere un nome esistente kset?

Scusate se questo è semplicemente ovvio, o se c'è qualche esempio molto semplice e facilmente scoperto da qualche parte che non ho scoperto per qualche motivo. Qualcuno può far luce su questo?

risposta

8

Non ho lavorato molto con sysfs, ma ho trovato un esempio semplice che è molto simile a quello che stai facendo (naturalmente, è anche sotto ARM). Dai un'occhiata a arch/arm/mach-omap1/pm.c, in particolare il file sysfs idle_show/idle_store. Viene registrato (utilizzando sysfs_create_file()) come /sys/power/sleep_while_idle e utilizza il globale kobj (definito in include/linux/kobject.h). Ci sono alcuni altri kobj globali definiti che potresti usare, anche se non credo che siano adatti al tuo autista.

Si tratta di un driver di piattaforma? Come un guidatore che non si adatta a nessun bus, sembra una buona misura. I driver di piattaforma ottengono la propria directory sotto/sys/devices/platform e possono avere attributi lì. Date un'occhiata a drivers/hwmon/coretemp.c, che ha temp1_crit, temp1_crit_alarm, temp1_input, ecc. Come attributi. Sembra abbastanza semplice: creare gli attributi, elencarli tutti in un array, definire un attribute_group, registrarlo con sysfs_create_group() nella funzione probe(), e annullare la registrazione con sysfs_remove_group() nella funzione remove() (magari con __ATTR()?).

Probabilmente ci sono altri driver di piattaforma che definiscono gli attributi (cercare sysfs_create_group) se sono necessari altri esempi. Spero che questo ti aiuti!

+0

Daremo un'occhiata al driver coretemp.c. Grazie! –

+0

Un aggiornamento: il modulo coretemp era il modello perfetto. Ho ottenuto alcuni attributi sysfs che funzionano abbastanza bene. Grazie ancora. –

Problemi correlati