On 2015-11-16 20:48, J.F. wrote:
>> Nieprawda że dłubanie po hardware wymaga jakiś mitycznych wysokich
>> uprawnień. Od wieków stosujemy IOMMU:
>> https://en.wikipedia.org/wiki/Input%E2%80%93output_m
emory_management_unit
> A dostepne w telefonach ?

CPU do telefonów potrafi zrobić Apple. Jaki problem dodać dowolny
hardware? Do ARMów w zasadzie nie trzeba - tam nie ma separowanej
magistrali IO wiec nie ma potrzeby kombinowania z IOMMU. Tym bardziej że
gfx jest de facto częścią wszystkich cpu stosowanych w mobile.

>> Pozwala to za *przyzwoleniem* kernela przemapować wszelą przestrzeń
>> adresową gfx dowolnemu procesowi i od tej pory może on sobie dlubać
>> wprost po rejestrach gfx. Na przykład procesowi sterownika karty grafiki.
>
> Czekaj czekaj - bo na ile rozumiem, to dziala odwrotnie - pozwala
> zwirtualizowac adresy uzywane przez urzadzenie IO, np gfx.
> Urzadzenie siega do pamieci pod adres np C2000000, a IOMMU podmienia mu
> go np na A8000000.

Działa w dwie strony ponieważ gfx zazwyczaj posiada pamięć sherowaną
pomiędzy hardware i cpu. Uzycie IOMMU i MMU pozwala widzieć pamięć gfx
czy czegotam chcesz bez żadnych "uprawnień kernela".

> Do rejestrow urzadzenia/gfx nadal trzeba sie dostawac, ale jesli to ARM,
> to nie ma wydzielonych instrukcji, sa mapowane do pamieci, i tu zwykle
> MMU/protekcja pamieci wystarczy.

Tak, jesli mamy procesor bez udziwnień to zwykłe MMU tez się może nadać.
Ponadto w cpu w mobile mogą być inne rozwiązania, np. gfx jest na stale
w jakimś obszarze pamięci fizycznej i już.

>>> Jeśli piszesz ekstremalnie szybki system operacyjny to możesz
>>> przydzielić wszystkim procesom uprawnienia i kazdy sobie może
>>> grzebać. Twój (kernela) wybór.
> No ale z reguly nie chcesz, bo ani te procesy nie wiedza jak tam
> grzebac, ani nie chca grzebac sie w szczegoly roznych GFX, a namieszac
> moga, jak zaczna ustawiac urzadzenie w sposob niezsynchronizowany z innymi.

Dlatego obcina się część wydajności rozbiąc silne separacje. Teraz
trzeba policzyć ile kosztuje switch miedzy procesami. Stawiam że prawie
nic w porównaniu z javascriptem na facebooku. Ponieważ procesy, przy
masowej komunikacji, najzwyczajniej w świecie sharują pamięć RAM. Więc
znowu, rola sterownika sprowadza się do inicjacji hardware.

> Ale mi chodzi o to, czy Dalvik w ogole przewiduje operacje np "zapisz
> pod adres C2000000 w pamieci".

Nie musi. Wystarczy że może (a musi) wołać metody natywne. I wtedy w
javie widzisz os.raw.memory.write( address, value ) czy coś w ten deseń.

> W pamieci rzeczywistej, albo wirtualnej ale procesora, a nie pamieci
> przewidzianej przez Dalvik dla procesu w javie.

Co to za różnica, MMU przemapowalo Ci hardwareowy zestaw rejestrów GFX
pod adres 0x123456 i sobie po nich smerasz. Sterownik wie co i gdzie
należy przemapować. Może to zgłosic na inicjacji.

> Tudziez np funkcje poproszenia kernela o odpowiednie zamapowanie tego
> C20000xxx.

Tak.

> Jeszcze jakies inne rozkazy zostaja, typu np zablokowanie przerwan,
> sterowanie nimi, operacje atomowe itp.

To wszystko to są trywializmy. Przecież nikt nie mówi że API/ABI
sterownika zaczyna się od main(argc,argv). naprawde, nie ma roznicy czy
porty hardware smerane sa przez kod maszynowy czy przez ten sam kod
maszynowy wygenerowany z dalvika.