On 2015-11-16 21:48, J.F. wrote:
>> 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 :-)

Dalo się zrobić bez ale ma kłopoty funkcjonalne z update. Jesli istniał
by motywator ekonomiczny to wszystko jest możliwe. Ale nie ma.

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

Te rejstry leżą obok w pamięci od 0x400000 w górę. W czym problem?

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

IOMMU pozwala na dowolne machloje głównie dlatego że powstalo do duzych
systemów. Do systemów małych, szczególnie typu SoC mozna wprost
zaprojektować hardware tak aby załatwiało to w całości MMU. Nie widze
żadnych przeszkód aby IOMMU w SoC nie istniało a system dalej mapowal
wszelkie rejestry i pamięc jakiegoś hardware w dowolne miejsce dowolnego
procesu.

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

I tutaj bingo: im mniejszy driver tym mniej do przestawiania w MMU. To
kwestia napisania tak kernela aby switch kontekstu do drivera dzwięku
był minimalistyczny. Kilka stron z rejestrami hardware, troszkę
sharowanej pamięci i do widzenia. Tak, cache pewnie się z lekka
uszkodzi, ale te kilkaset instrukcji sterownika to raczej duzych szkod
nie poczyni.

Ponadto jak mówie - CPU pożerają głównie aplikacje z userlandu. Drivery
nic nie robią bo czekają na przerwanie albo nikt ich nie chce w tej chwili.

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

Nie, ponieważ JIT kompiluje to do natywnego mov. To że coś w javie ma
skomplikowany zapis nie oznacza że po translacji do kodu maszynowego
dalej ma skomplikowany zapis.

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

Żaden problem. To dość proste zagadnienie.

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

Te uprawnienia ma proces drivera nadane przez kernel. W czym problem?

Na marginesie: wszelkie problemy z MMU i IOMMU tak naprawdę występują
rowniez w kernelu. To jest *dokładnie* to samo zagadnienie. Ja tylko
mówie że nie ma problemu aby przenieść drivery razem z ich hardware do
osobnych procesów. Nawet jesli to będzie kosztowac całe 0.1%[*] czasu
CPU na machanie MMU. A przeniesienie do osobnych procesów - żeby nie
zgubić o co w tej dyskusji chodzi - ma za zadanie umożliwić ich
aktualizację bez względu na dziadostwo prezentowane przez wytwórców
telefonów.

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

Ale nie musi na poziomie Javy. Wystarczy że na poziomie fake "pakietu"
os.driver.* znajdzie się zbiór metod "writeAtomic64BitLongInteger( ptr,
value ); itd. ktore translują się wprost do czego tam na aktualnej arch
trzeba. Atomowośc jakiejś operacji jest okreslana przez sterownik. Tak,
to oznacza że kod sterownika jest pisany głównie z użyciem wywołań do
jakiegoś os.driver i nie wygląda ładnie. Ale mało ktory sterownik
wygląda ładnie.

[*] Jest kilka prac z tej dziedziny, np:
http://choices.cs.illinois.edu/ExpCS07.pdf

PS. Nie na darmo współczesne CPU mają kilka rdzeni - to powoduje że nie
trzeba robić switcha kontekstu za każdym razem kiedy wołasz driver.