Sono sorpreso che l'onnipotente Google non abbia una risposta pronta alla domanda "che cos'è VCHIQ?" Sono un fanatico del kernel da molto tempo e non un dipendente Broadcom, né sono un esperto BCM283 *, ma ecco cosa ho trovato per (forse) i posteri:
Dal ramo del kernel Raspberry Pi :
Interfaccia di comunicazione da Kernel a VideoCore per la famiglia di prodotti BCM2708.
Ciò che vale la pena notare qui è che VideoCore è (sorpresa sorpresa) il controller video per il SoC che esegue il Pi, e sembrerebbe che questo sia un modo pratico per eseguire IOCTL più o meno diretti verso vari sottosistemi collegati alla GPU . Che questo includa il video non è una grande sorpresa, ma immagino abbia senso che l'interfaccia della videocamera abbia il suo silicio all'interno di VideoCore, dato tutto il codec che il video deve fare.
Quindi perché il controllo audio viene eseguito anche attraverso VideoCore (altrimenti non sarebbe necessario VCHIQ per controllarlo)? Ho il sospetto che, dato che VC ha il supporto hardware per H.264 e altri codec (e poiché è possibile instradare l'audio tramite HDMI), era solo il posto più semplice per inserire il silicio. Bene, questo e il fatto che il chip BCM ha due MMU (uno per VC + ARM, un altro per il normale utilizzo del sistema operativo - vedi diagramma a pag.5 ), che rende possibile il DMA a zero-copia (non è necessario copiare cose sul silicio audio: basta dire che un pezzo di memoria appartiene a esso e non alla CPU. Non so se lo fanno effettivamente sotto le coperte, ma perché non dovresti?).
Si noti che gli IOCTL su VCHIQ non trasferiscono realmente i dati di per sé, ma impostano DMA e altre operazioni tra blocchi di memoria e inviano comandi a vari bit. Questo può essere super pericoloso, dal momento che potresti potenzialmente rovinare le strutture interne dei dati del kernel dallo spazio utente, bloccare la GPU, aggirare i dati corrotti, ecc. Quindi non impostare / dev / vhciq in modalità 777 !!!
In ogni caso, la risposta breve a "cos'è VCHIQ?" Ecco qui:
VCHIQ è un'interfaccia di comando tra il kernel Linux in esecuzione e le periferiche (tra le altre cose) nel silicio VideoCore. / dev / vhciq fornisce l'accesso generico allo spazio utente a quei comandi per l'uso (almeno) della telecamera e dei sottosistemi audio. È un'interfaccia abbastanza pericolosa da esporre a programmi casuali, quindi le autorizzazioni un po 'restrittive per impostazione predefinita.
Ci sono persone all'altezza dell'hardware BCM nella comunità RPi; Non sono uno di loro (forse sono profondo fino alle caviglie dopo un paio d'ore di ricerca :-)). Detto questo, penso che questa sia una panoramica di alto livello decente e gradirei aggiunte / correzioni.
Per quanto riguarda il motivo per cui www-data richiede l'autorizzazione, ciò sarebbe dovuto al fatto che il tuo programma CGI sta generando processi figlio come quell'utente. Non conosco bene quel particolare giocatore, ma di solito è meglio eseguire un demone specializzato per controllare il programma che si interfaccia al suono e controllarlo dal CGI usando un socket UNIX o un'interfaccia simile piuttosto che generare un bambino.
In effetti, un fornitore di sicurezza è stato arrestato qualche tempo fa per consentire al proprio server Web di accedere alla propria macchina. Probabilmente lo hanno fatto per facilitare la gestione dei processi piuttosto che scrivere questo tipo di livello intermedio, ma è un no-no di sicurezza. Dare a Apache un accesso praticamente illimitato al DMA della GPU è una cattiva idea (anche se lo ammetto molto più difficile da sfruttare).
Spero che questo risponda alla tua domanda.
/dev/vhciqeseguire l'audio in generale - in questo caso è perché l'OP lo sta usandoomxplayerper farlo, il che probabilmente non è l'ideale.