On 2015-11-15 14:45, Pszemol wrote:
>>>> Myslisz tak samo jak misie od Androida. Przecież sterownik
>>>> musi być w C. A h... nie musi.
>>> No ale wypadałoby, żeby to co napierdala przez 80%
>>> jednak było, przynajmniej w C.
>> Przez 99% czasu to napierdala DMA.
> W jakich scenariuszach używają tego DMA?

Sa 3 przypadki tak z grubsza:
a) urządznie wymaga powolnego odpytywania. Choćby przyciski na obudowie.
Tam może dzialać dowolnie wolny kod bo odpytania są tanie

b) urządzenie wymaga przesyłania ciagłych obszarów pamięci poprzez
bezustanne smeranie po rejestrach. Takie urzadzenie jest błedne z
definicji ponieważ opiera się o pooling. Stosowane powszechnie w latach
80-tych. Pierwsze DMA na komputerach osobistych to okolice blitterów gfx
i muzyki.

c) urzadzenie które posiada kanaly DMA. Dotyczy to wszelikich urządzeń
masowych takich jak dzwiek, zapisy na dysk/flash, grafika, sieć. W tych
przypadkach sterownik inicjuje tylko DMA a reszta dzieje się w tle. Nie
istnieje powód dla ktorego sterownik przyjmując przerwanie musi być w C.
Może być tak samo w czymkolwiek wliczając w to maszynę wirtualną.
Rozwiązuje to problemy ABI.

Obecnie linux jest systemem w którym ABI jest niestabilne i całość
Androida cierpi z tego powodu bo głupia naprawa sterownika pociąga za
sobą *łaskawe* skompilowanie kernela przez producenta lub gra w rosyjską
ruletkę przez communisty czy binarny modul nie uszkodzi systemu (i czy
nie zawiera wirusa).

a) i c) nie wymagają od sterownika żadnej prędkości. b) jest bledem
hardwareowym i raczej go nie napotkasz we współczesnym sprzęcie.

Już od dawna szybkośc sterownika nie ma za wiele wspólnego z szybkością
hardware. Sterownik ustawia jakieś porty i dalej robi się DMA. Do tego
nie trzeba C. Nie widze powodu dla którego sterownik dzwięku nie mozna
napisać w Javie która w tle translowana jest z bytecode do natywnego
kodu jeśli komuś bez sensu zależy na hiper prędkości tych
kilkudziesięciu outb.