Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:n2dcv5$k5r$...@n...news.atman.pl...
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?

Zaden, ale jesli (nie wiem) telefon sie dalo zrobic bez, to moze nie
ma potrzeby dokladac :-)

>>> 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".

Tak, ale to bedzie np pamiec video. Czy pamiec obiektow graficznych do
wykorzystania.

A sterowac tym gfx trzeba przez inne rejestry - tak, zeby wiedzial ze
zostalo do nich zapisane, bo przeciez nie bedzie stale zawartosci
pamieci sprawdzal.

A w tym IOMMU nie pomoze. Chyba, ze jakos sprytnie w dwie strony
bedzie dzialalo.

>>>> 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.

Mozliwe, tym niemniej switch sie wydluza, jak trzeba zachowac rejestry
(a przybywa ich), przestawic MMU, byc moze przestawic IOMMU itd.

>> 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ń.

i wydajnosc dalej spada :-)

>> 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.

No wlasnie o to chodzi - albo z poziomu kodu Dalvika musze miec dostep
do tego umowionego adresu w pamieci procesora, albo kernel musi
wiedziec jak mapowac aby ten dalvikowy kod dobrze trafial .

>> 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

Oczywiscie, ale moge wymagac wiekszych uprawnien.

>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.

Ale sam dalvik moze nie przewidywac np operacji atomowych, bo i po co
to na poziomie abstrakcji Javy.

J.