Darling progress report - listopad 2012

6.12.2012 11:00 | Přečteno: 1470× | Linux | | poslední úprava: 6.12.2012 11:02

Abyste si nemyslel, že jsem Darling vzdal...

Tohle je postup prací od posledního zápisku z října:

• Základní (neozkoušená) struktura IOKitu zatím jen pro enumeraci hardwaru (používá libudev). Do budoucna bude potřeba napojení na libusb a další.
• Lepší nástroj v C++ pro spouštění testů. Používá můj nový šikovný C++ wrapper nad libssh.
• Rozjel jsem build server na jenkins.dolezel.info, hlavně pro běh testů.
• Podpora výjimek Objective-C na x86 32bit (na bázi setjmp/longjmp).
• Podpora výjimek Objective-C na x86 64bit (Itanium ABI exceptions).
• Různé opravy v zasílání zpráv v Objective-C - odhaleno testy.
• Podpora fcntl() a dalších funkcí.
• Plná podpora Mach lockset + semaphores okolo linuxového syscallu futex().
• Podpora konstantních řetězců CoreFoundation (CFSTR(...)). Spolupráce s autorem gnustep-corebase (CoreFoundation) na integraci s gnustep-base (Foundation).
• Podpora lazy binding na x86 a x86-64.
• Pár funkcí do Core Services kolem správy souborů a práce s časovými údaji.
• Práce na dialogu oznamujícím pád GUI aplikace.
• Nedokončená snaha zkompilovat Grand Central Dispatch pro Linux.
• Přemýtání nad implementací Mach IPC a Apple Events.

A teď pár převážně kritických témat

Mach je bléfuj

Mikrokernel Mach je velmi, velmi pomalý. Je natolik pomalý, že synchronizační nástroje (lockset, semaphores...) běží řádově rychleji pod mou emulací daných volání na Linuxu než na původním systému. Zatímco na Linuxu proběhne test s 30 000 uzamčeními v několika vláknech stabilně za 0,13 sekundy, na OS X to trvá náhodně mezi 2 a 8 sekundami.

Přemýšlím nad implementací Mach Ports (IPC; popis v GNU Hurd). Musel by to být jaderný modul, už mám jakousi kostru, která vytvoří /dev/machipc, nad kterým lze dělat volání pomocí ioctl(). Otázka je, jestli to má smysl, protože moc aplikací asi pro vlastní komunikaci Mach Ports nepoužívá. On s tím hlavně nikdo moc neumí a je to takové poněkud zapeklité.

Sony je bléfuj

Přemýšlel jsem o podpoře platforem ppc a ppc64, neboť až do roku 2005 byl OS X provozován na PowerPC hardwaru. Hned jsem si vzpomněl na můj PlayStation 3, který je také PPC. Já blbec jsem ale někdy před rokem aktualizoval firmware na verzi 4.00, která nejde bez rozebrání a ručního přeflashování hacknout tak, abych z toho měl linuxový stroj.

QEMU bohužel není řešení. Emulace ARM mi pod QEMU funguje krásně, ale PPC a PPC64 mi ani jedno nefunguje (nebo to trvá tak dlouho, že jsem to po 2 minutách načítání jádra vzdal).

Kdyby tedy někdo z vás měl třeba nepoužívaný starý Mac Mini G4 a byl by ochoten ho darovat (protože peníze se mi za to dávat nechce), byl bych moc rád

Applí kód je škaredý

To jen taková samochvála. Kdykoliv najdete na opensource.apple.com hezký, přehledný kód, tak není od Apple. Jakmile je to totální slepenec, ve kterém aby se čert vyznal, tak je to jejich původní kód. Když se někdy podívám, jak to udělali oni a jak jsem to udělal já, tak se prostě musím pochválit, jak elegantní ten výsledek je :-P

Podpora ARM

Na úrovni dynamického loaderu bych rád podporoval i platformu ARM, ze softwarového hlediska tedy iOS (iPod/iPad/iPhone). Aby z toho bylo něco opravdu užitečného, tak by bylo nutné dopsat příslušná API v iOS SDK nad něčím jiným (Android?). Půjde tedy spíše o proof of concept.

Help needed

Práce je obrovské množství. Našla by se spousta práce, která není nijak obtížná, ale přesto je nutné ji udělat. Kdyby se našli zájemci, jistě by se našla témata (knihovny) pro volný čas, semestrálky, bakalářky apod. Třeba takové Apple Events se dají relativně snadno napsat nad libdbus.

       

Komentáře

[ewew]

Existuju nejaké vzorky kódu Applu a opensource verzie ?

Dôvod portovania linuxu na hardvér applu ?

[Luboš Doležel (Doli)]

Existuju nejaké vzorky kódu Applu a opensource verzie ?

opensource.apple.com a git.dolezel.info. Tohle není úplně 100% ukázka, ale první díl tohoto souboru (až po #else) a tento můj soubor to také trochu ilustrují. Nebo třeba masochismus Applu, který se dá nahrazovat minimem assembleru pro snazší portování.

Hodně věcí v Applu se šije horkou jehlou, bez rozmyslu. Pak jsou výsledkem hacky kvůli zachování ABI, nahodile vlepované kusy kódu do jiného kódu, duplicity apod.

Dôvod portovania linuxu na hardvér applu ?

Nejak jsem nepochopil otázku. Já Linux neportuju, Linux na ppc dávno chodí.

[Bedňa]

Tak to je hack, na iBook nainštalovať Linux a na ňom spúšťať aplikácie pre Apple

[ET]

ja bych mozna mel pixlu s ppc od macka za dovoz - ale je to starej desktop, procak ~400MHz, kdybys chtel tak se po nem kouknu...

[ET]

*za odvoz

[Luboš Doležel (Doli)]

To ale nebude s OS X, že ne?

[ET]

mno naposled tam byl debian, ale uloz.to to jisti ne? ;)

[smazáno]

ja bych nekde nasel Mac LCIII+ ale to ti asi moc nepomuze

[luky]

Nesly by ty Mach Ports implementovat v userspace pomoci posilani filedeskriptoru pres unixove sockety?

[Luboš Doležel (Doli)]

Ne úplně. Ports mají systém práv a různé vlastnosti, které nejde bez asistence jádra pořádně naimplementovat.

Příklad z mnoha: porty se při exec() nedědí, ale předává se tzv. bootstrap port. Další věcí je ale samotné posílání práv k portu, například send-once.

[kralyk z abclinuxu]

Rozepsal by ses maličko o těch výjimkách? Ta zmínka o setjmp/longjmp mě mírně děsí

[Luboš Doležel (Doli)]

Hehe, počkej si rok a půl a bude to popsaný v diplomce

Stručně jde o to, že zatímco 64bit ObjC výjimky používají "standardní" mechanismus výjimek na bázi libunwind a spol., takže to jde stejnou cestou jako výjimky C++, na 32bit to mají z nějakého historického důvodu jinak.

Každý vstup do try bloku se tedy mění na volání objc_exception_try_enter, kterému se předá výstup funkce setjmp() volané hned před tím, a výstup z try bloku se analogicky mění na objc_exception_try_exit. Je-li hozena výjimka, runtime si vezme poslední try blok, který má na interním stacku, a udělá na něj longjmp(). To vede k tomu, že se program vrátí na to volání setjmp(), ale tentokrát ta funkce vrátí jinou hodnotu, což indikuje, že bylo skočeno zpět - tzn. došlo k výjimce.

Na to vygenerovaný kód programu reaguje skokem do oblasti catch handlerů. Tam se kód ptá pomocí objc_exception_match(), jestli handler pro typ XYZ může handlovat výjimku, kterou si to získalo přes objc_exception_extract(). Pokud tam takový handler není, tak se opět - nanovo - volá objc_exception_throw(), které tu výjimku hodí přes try blok o úroveň níž.

[kralyk z abclinuxu]

Aha, takže oni to mají už v ObjC (na 32b) řešeno pomocí setjmp, já to ze zápisku špatně pochopil tak, žes nasadil setjmp z vlastního rozhodnutí. Takže to pak jó samozřejmě

No každopádně, "zajímavě" to mají v tom ObjC pánové vyřešeno, jen co je pravda

[luky]

Tak ono bylo ObjC pomerne dlouhou dobu implementovano jako preprocesor pro Ccko, takze to je vpodstate celkem primocare reseni.

[Salamek]

Pokud mas zajem mohl bych dodat iBook 4G s MAC OS X Tiger a Debianem (vice mene se tu vali kolem)

[Luboš Doležel (Doli)]

Tohle by bylo úžasný

[Salamek]

Jabber at se muzem domluvit ? :)

[Luboš Doležel (Doli)]

lubos@dolezel.info

[Bedňa]

A už si slávny

[Luboš Doležel (Doli)]

A bylo to i na Slashdotu

[Bedňa]

Tak to gratulujem.

[kotyz]

Dneska už ho probírají i na Google+ v Archlinux community.

[Luboš Doležel (Doli)]

Jen je smutné, že když už lidi nechtějí pomoci, tak tě od toho aspoň zrazují, co to jen jde.

[ewew]

Je vidieť ako ľudia chránia vyvojárov pred super ultra mega užasným Apple systémom. Ktorý je tak úžasne súper, že si užívateľia nechaju diktovať čo je správne a čo nie. Alebo nemôžu zniesť, že by ich užasné MAC aplikácie fungovali na inom systéme ako len jedinom správnom systéme.

[Ovocníček]

Lidi myslí i dobře. Protože přece jenom, programovat velký problém člověku sežere hodně času, a když mu to aspoň neobstarává živobytí, tak je samozřejmě otázka, jestli to tak trochu není ztráta času. (Což platí o spoustě dalších hobby činností, nejen o programování FOSS věcí.)

Takže radím si z toho nic nedělat, pokud to máte promyšlené. Naopak si z toho vemte, že některým těm týpkům na vás v podstatě záleží, což je hezké. Naopak by se dalo říct, že lidi, kteří dobrovolníka povzbuzují, protože hodlají jeho práci používat, jsou tak trochu neupřímné potvory - chcou, aby někdo zabil spoustu času kvůli jejich pohodlí :D

[kotyz]

WTF? To ti tam píšou že to nemáš dělat? Místo aby byli rádi že se udělá něco užitečnýho...

[Luboš Doležel (Doli)]

Dozvěděl jsem se, že je to k ničemu a že to vzdám dřív, než z toho bude něco užitečnýho

[Ovocníček]

Jo mimochodem, viděl jsem na phoronixu tohle: "As for LGPL/BSD: I do not use the BSD or similar license for a purpose. You wan't to make money off this? You either give me a cut or share your code with others. I find it fair."

Jestli Luboš uvažuje o tom, že by to jednou mohlo mít komerční užití, tak by možná nebylo od věci se inspirovat u x264 (http://mailman.videolan.org/pipermail/x264-devel/2010-July/007508.html)

Jde v podstatě o to, že kód je GPL, ale pokud firma má komerční projekt a ráda by ho použila (to znamená, že chce knihovnu linkovat do uzavřené aplikace), tak si koupí licenci a dostane tím vyjímku. Podmínku je, že jakékoliv distribuované změny musí dát k dispozici upstreamu.

Pokud vím, tak úspěch tohoto licencování zdaleka předčil očekávání. Firmy mají očividně velký zájem - očividně raději platí, než aby se přizpůsobily GPL, byť by tou cestou dostaly ten samý kód zadarmo. Je to pěkné, komunita má všecko zadarmo, ale vývojáři zároveň můžou podojit komerční firmy (i dost velké). Třeba by si Luboš mohl takhle jednou vydělávat. Na druhou stranu nemám představu, jak velký je pro takovéhle věci trh (tj. jak moc je firem, které by na tom chtěly vydělávat a tzn. koupit si licenci). V případě x264 je trh dost velký, přirozeně.

Protože to komerční licencování odstartovalo dost pozdě, bylo třeba sehnat všechny autory kódu a dostat od nich souhlas. Taky přispěvatelé musí podepsat, že souhlasí s tím dvojím licencováním.

[Luboš Doležel (Doli)]

Přesně tak nějak jsem to myslel.

Jinak teď se mi ozvali z Ukrajiny, že se dřív už neveřejně pokoušeli o něco podobnýho a že bychom mohli spojit síly. Tak vida, evidentně se to musí dostat na Slashdot, aby se to rozšířilo

[Tomáš]

Při čtení jsem si vzpoměl na jeden velmi zajímavý článek implementaci vyjímek v C. Je založeno na této neuvěřitelné konstrukci, kterou si dovolím okopírovat:

   register n = (count + 7) / 8;      /* count > 0 assumed */

   switch (count % 8)
   {
   case 0:        do {  *to = *from++;
   case 7:              *to = *from++;
   case 6:              *to = *from++;
   case 5:              *to = *from++;
   case 4:              *to = *from++;
   case 3:              *to = *from++;
   case 2:              *to = *from++;
   case 1:              *to = *from++;
                      } while (--n > 0);
   }

Toto je validní C kód ( žádná chyba ).

[kralyk z abclinuxu]

V tom článku ale tuhle konstrukci nepoužívají, když se podíváš, tak oni mají switch vevnitř v do, ne obráceně jako v Duff's device. Duff's device slouží k ompimalizaci - částečnému rozbalení smyčky, kdežto v tom článku ten switch slouží k rozlišení výstupu setjmp(). Celej ten switch mají ještě obalen v do { ... } while(0), nejspíš proto, aby tím vznikl vlastní sub-scope pro jmp_buf.