abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 16:11 | IT novinky

    Google ve spolupráci se společnostmi Samsung a Qualcomm představil (YouTube) platformu pro rozšířenou realitu Android XR. První zařízení s Androidem XR budou k dispozici v roce 2025.

    Ladislav Hagara | Komentářů: 1
    dnes 12:00 | Nová verze

    Byl představen CentOS Stream 10 s kódovým názvem Coughlan. Detaily v poznámkách k vydání. CentOS Stream 10 už neobsahuje balíček s Xorg serverem (xorg-x11-server-Xorg). O zobrazování se stará Wayland s Xwaylandem (xorg-x11-server-Xwayland). Odstraněny byly aplikace Firefox, GIMP, LibreOffice, Inkscape a Thunderbird. Ty jsou k dispozici ve Flatpaku z Flathubu.

    Ladislav Hagara | Komentářů: 8
    včera 15:33 | IT novinky

    Byly vyhlášeny výsledky The Game Awards 2024 (YouTube). Hrou roku se stal Astro Bot (YouTube) běžící pouze na PlayStation 5.

    Ladislav Hagara | Komentářů: 0
    včera 12:22 | IT novinky

    Na GOG.COM probíhá Winter Sale 2024. Při té příležitosti lze každý den do konce roku získat zdarma jinou počítačovou hru, viz kalendář uprostřed stránky Winter Sale 2024. Otevření balíčku se hrou vždy ve tři odpoledne. První hrou je The Whispered World: Special Edition.

    Ladislav Hagara | Komentářů: 4
    včera 02:22 | IT novinky

    Nezisková organizace Internet Security Research Group (ISRG) vydala Výroční zprávu za rok 2024 (pdf). Organizace stojí za certifikační autoritou Let's Encrypt, projektem Prossimo, jehož cílem je používání paměťově bezpečného kódu v kritické internetové infrastruktuře a službou Divvi Up řešící telemetrii respektující soukromí uživatelů.

    Ladislav Hagara | Komentářů: 2
    12.12. 15:55 | Zajímavý software

    Vývojáři PeerTube, tj. svobodné alternativy k videoplatformám velkých technologických společností, představili mobilní aplikaci PeerTube (Google Play, App Store). Zdrojové kódy jsou k dispozici na Framagitu.

    Ladislav Hagara | Komentářů: 3
    12.12. 13:55 | IT novinky

    Google představil Gemini 2.0, tj. novou verzi svého modelu umělé inteligence (YouTube).

    Ladislav Hagara | Komentářů: 0
    12.12. 13:44 | Nová verze

    Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.12. Přehled novinek i s náhledy a videi v oficiálním oznámení.

    Ladislav Hagara | Komentářů: 0
    12.12. 03:44 | Zajímavý článek

    Prosincové číslo časopisu MagPi od nakladatelství Raspberry Pi zdarma ke čtení: MagPi 148 (pdf).

    Ladislav Hagara | Komentářů: 1
    12.12. 01:55 | Nová verze

    Byla vydána nová verze 3.27 frameworku Flutter (Wikipedie) pro vývoj mobilních, webových i desktopových aplikací a nová verze 3.6 souvisejícího programovacího jazyka Dart (Wikipedie).

    Ladislav Hagara | Komentářů: 0
    Rozcestník

    Jaderné noviny - 28. 2. 2007

    22. 3. 2007 | Robert Krátký | Jaderné noviny | 6269×

    Aktuální verze jádra: 2.6.21-rc2. Citát týdne: Linus Torvalds. KVM 15. Threadlets. Vlákna nebo události?
    Aktuální verze jádra: 2.6.21-rc2. Citát týdne: Linus Torvalds. KVM 15. Threadlets. Vlákna nebo události?

    Obsah

    Aktuální verze jádra: 2.6.21-rc2

    link

    Aktuální předverze řady 2.6 je (k 28. 2. 2007) 2.6.21-rc2, vydaná 27. února. Obsahuje velkou aktualizaci Video4Linux a PA-RISC, začátek podpory "SMARTMIPS", ovladač pro USB ethernetové adaptéry Davicom DM9601, ovladač pro "IO Warrior" od Code Mercenaries a podporu využívání subsystému HID v Bluetooth. Několik patchů bylo také staženo kvůli regresím. Linus o této verzi řekl: Takhle by -rc2 vypadat neměla. Opravdu to potřebujeme zklidnit! Vizte podrobnosti v dlouhém changelogu.

    Od vydání -rc2 nepřibyly do hlavního repozitáře žádné patche.

    Minulý týden nevyšlo žádné -mm jádro.

    Jádra z větve -stable 2.6.19.5 a 2.6.18.8 byla obě vydána 23. února. Obsahují slušný počet oprav. Další aktualizace 2.6.18 už nejsou pravděpodobné; asi ještě vyjde jedna verze 2.6.19.

    2.6.16.42 vyšlo 26. února a obsahuje několik oprav, z nichž některé se týkají bezpečnosti.

    Citát týdne: Linus Torvalds

    link

    Protože jestli nechápeš, proč si stěžuju, nemohu od tebe stahovat [pull]. Můžeš mi posílat patche, ale abych si od tebe stáhl git patch, to bych si musel být jistý, že víš, co děláš. Potřebuji mít v ty věci důvěru, *aniž* bych musel každou jednotlivou změnu kontrolovat.

    -- Linus Torvalds

    KVM 15

    link

    Ve světě virtualizace to občas vypadá, že se věci moc rychle nehýbají. O Xenu už se v souvislosti s paravirualizací mluví roky - první "stabilní" vydání bylo oznámeno v roce 2003 - ale kód se pořád do hlavního jádra nedostal. Poslední dobou se projekt moc neozýval - i když programátoři Xenu na kódu pořád pracují.

    Naproti tomu KVM se zdá být pěkně rozjeté. Projekt se objevil v říjnu 2006 a o pár měsíců později si našel cestu do jádra 2.6.20. 25. února byla oznámena verze KVM 15; ta má zajímavou funkci: živou migraci. Rychlost, s jakou se vývojářům KVM daří přidávat poměrně pokročilé funkce, je úctyhodná; stejně úctyhodné je i to, jak jednoduchý je kód, který živou migraci implementuje.

    KVM má oproti ostatním virtualizačním projektům velkou výhodu: spoléhá na podporu v hardwaru, která je k dispozici jen u nových procesorů. Proto také nebude KVM fungovat na většině v současnosti nasazených systémů. Na druhou stranu - navrhování pro budoucí hardware je často výhodné. Budoucnost na sebe ve světě technologií nenechává dlouho čekat. Zaměření na hardwarem podporovanou virtualizaci znamená, že KVM se může věnovat vyvíjení zajímavých funkcí, které budou dostupné na teď nakupovaných systémech.

    Migrační kód je zabudován do emulátoru QEMU; Příslušný soubor se zdrojovým kódem má méně než 800 řádků. Živá migrace funguje takto:

    • S cílovým systémem je navázáno spojení. V současné době to lze provést prostřednictvím přímého TCP propojení na otevřený port (což není zrovna nejbezpečnější způsob) nebo pomocí SSH.

    • Na cíl je nakopírována paměť hosta. Tento proces je založen na prostém proběhnutí fyzického adresního prostoru hosta (což je na straně hostitele pouze virtuální paměť) a postupném odeslání všech stránek na cílový systém. Každá zkopírovaná stránka je pro hosta označena jako "pouze ke čtení".

    • Během kopírování host pořád běží. Kdykoliv se pokusí změnit stránku, která už byla zkopírována, bude zachycen a vrácen zpět do QEMU, který obnoví právo k zápisu a stránku označí jako nečistou. Kopírování paměti je tedy iterativní proces; jakmile je dokončen celý rozsah, vrátí se migrační kód na začátek a znovu zkopíruje všechny stránky, které mezitím host změnil. Předpokládá se, že s každým průběhem bude počet stránek, které je nutné zkopírovat, menší.

    • V okamžiku, kdy počet nečistých stránek klesne pod určitou úroveň, je host zastaven a dojde k překopírování zbytku. Pak už stačí přenést aktuální stav hosta (hlavně registry) a je hotovo; přemigrovaný systém může být restartován na novém hostitelském systému.

    Dokonce je možné bez problémů přesouvat hostované systémy z procesorů Intel na AMD a nazpátek. Není však možné přesunout 64bitového hosta na 32bitového hostitele; nevypadá to, že by se vývojáři KVM v dohledné době měli k řešení tohoto konkrétního omezení. O trochu více informací lze nalézt na stránce o KVM migraci.

    Další věc, která stojí za zmínku, je plánované zmrazení rozhraní KVM pro 2.6.21. Rozhraní se rychle vyvíjelo, přestože se jedná o API pro uživatelský prostor; takovou pružnost umožňovala skutečnost, že jde o nový, experimentální kód, který zatím nikdo v reálu nepoužívá. Zmrazení API naznačuje, že vývojáři KVM považují kód za dostatečně stabilní, aby mohl být brzy nasazen na produkční systémy. Možná to také znamená, že se brzy dozvíme, jak hodlá společnost Qumranet, která práci na KVM platí, vydělávat peníze.

    Threadlets

    link

    Vzpomínáte na fibrily? Ta vzpomínka asi nebude moc čerstvá, vzhledem k tomu, že se tu o nich psalo v lednu, ale práce inspirovaná konceptem fibril pokračuje. Poslední syslet patch od Ingo Molnara byl zveřejněn 24. února; přináší zajímavé změny v tomto přístupu k provádění asynchronních systémových volání.

    Koncept "atomů", který byl součástí prvního syslet patche, zůstává; atom je jednotka práce prováděné v jádře. Atomy mohou být zřetězovány pomocí jednoduchých operací, takže celá sekvence může být provedena bez opuštění jádra. Sekvence atomů bude - pokud možno - provedena synchronně; pokud se však atom zablokuje, bude pro navrácení do uživatelského prostoru vytvořeno nové vlákno. Díky tomu může být asynchronní kód spouštěn paralelně, ale režie způsobená vytvářením vláken se projeví, jen když je to nutné.

    API sysletů se však změnilo v reakci na obavy týkající se toho, jak budou řešeny události signalizující dokončení [completion events]. Uživatelský prostor teď musí vytvořit strukturu, která bude doprovázet sekvenci atomů:

        struct async_head_user {
    	unsigned long			kernel_ring_idx;
    	unsigned long			user_ring_idx;
    	struct syslet_uatom __user	**completion_ring;
    	unsigned long			ring_size_bytes;
    	/* tady jsou ještě další věci */
        };
    

    Struktura definuje kruh dokončení [completion ring] - kruhový buffer, který jádro naplní ukazateli na již dokončené atomy. Není už nutné tento buffer v jádře registrovat, protože struktura je předána v okamžiku předání atomů, které mají být provedeny:

        struct syslet_uatom *async_exec (struct syslet_uatom *atom,
                                         struct async_head_user *ahu);
    

    Z nového rozhraní vyplývá, že každá série atomů může mít - pokud o to stojí - svůj vlastní kruh dokončení. Tyto kruhy už nejsou drženy v paměti, takže jich může být libovolné množství. Návratová hodnota z async_exec() bude ukazatel na poslední atom, který má být proveden, běží-li série bez blokování, nebo NULL, je-li série blokována a uživatelský prostor běží v novém vlákně.

    Jens Axboe, Suparna Bhattacharya a další prováděli s aktuálním kódem sysletů výkonnostní testy. Mnohé z testů (i když ne všechny) ukazují, že syslety poskytují lepší výkon než stávající implementace asynchronního I/O. Příčiny rozdílných výsledků jsou stále zkoumány, ale ukázalo se, že se syslety nefunguje správně CFQ I/O plánovač [scheduler]. Plánování CFQ je orientované na procesy, takže není tak docela překvapivé, že změny procesního modelu způsobují zmatky. Ingo si je i tak jistý, že syslety přinesou lepší výkon:

    Podle mých vlastních měření (založených na FIO) jsou syslety rychlejší než nativní KAIO rozhraní - jak s keší (== hodně vláken), tak bez keše. Ten druhý výsledek jsem vůbec nečekal, protože kód sysletů zatím není vůbec optimalizovaný pro provoz bez keše. Předpokládal jsem tedy (mnohem) větší režii procesoru než u KAIO.

    To znamená, že KAIO je na tom hůř, než jsem si myslel - je toho prostě moc, co musí KAIO udělat, aby bylo možné provést paralelní IO. Protože optimalizace KAIO probíhají již několik let, je pravděpodobně na hranici svých výkonnostních možností.

    Asi největší změnou v nové verzi patche je však vytvoření konceptu pojmenovaného "threadlets" [vlákénka]. Threadlety do uživatelského prostoru přinášejí vytváření vláken na požádání. Threadlety jsou obyčejný kód, který bude, je-li to možné, spuštěn synchronně; pokud se však zablokuje, bude vytvořeno nové vlákno, které uživatelskému prostoru umožní pokračovat, zatímco threadlet čeká.

    Ingovo API vyžaduje, aby aplikace definovala, že má funkce běžet jako threadlet:

        long threadlet_fn(void *data)
        {
            /* Almost anything can go here */
    	return complete_threadlet_fn(event, ahu);
        }
    

    Jediný rozdíl je, že je nutné volat complete_threadlet_fn():

        long complete_threadlet_fn(void *event, struct async_head_user *ahu);
    

    Parametr event je uložen v kruhu dokončení - protože tu však není žádná struktura atomu, musí uživatelský prostor poskytnout hodnotu označující dokončený threadlet. Struktura async_head_user opět popisuje kruh dokončení.

    Aplikace může threadlet spustit pomocí:

        long threadlet_exec(long threadlet_fn(void *),
                            unsigned long stack,
    			struct async_user_head *ahu);
    

    Kromě výše popisovaného threadlet_fn() ještě toto volání vyžaduje, aby aplikace pro nový threadlet poskytla prostor ve stacku. Parametr stack je tedy ukazatel (navzdory svému typu unsigned long) na několik stránek běžné uživatelské paměti vyhrazených pro tento účel. Struktura async_user_head umožňuje hlášení o dokončení threadletu. Pokud threadlet_fn() doběhne do konce bez bloku, návratová hodnota threadlet_exec() bude 1; jinak je vrácena nula.

    threadlet_exec() je ale jen wrapper pro uživatelský prostor, který maskuje komplikovanost skutečného rozhraní. Funkce se okamžitě přepne na daný stack a zavolá threadlet_on(), což je to skutečné systémové volání, přičemž mu předá původní adresu stacku jako parametr. Volání uloží adresu stacku, ujistí se, že bude k dispozici vlákno pro případ selhání keše [cache miss thread], a označí proces jako asynchronní. Pak se vrátí do uživatelského prostoru, který spustí uživatelovu threadlet_fn(). Pokud se tato funkce zablokuje, vezme si jádro nové vlákno, nastaví ho na původní stack a pošle zpět do uživatelského prostoru. Threadletová funkce pak bude pokračovat v původním vlákně, jakmile se vyřeší to, co ji blokovalo.

    Není tedy překvapení, že complete_threadlet_fn() je také wrapper. Volá threadlet_off(), aby dal najevo, že je provádění threadletu dokončeno. Pokud threadlet_off() vrátí 1, znamená to, že threadlet běžel synchronně, a všechno už je hotovo. Jinak se zavolá:

        long async_thread(void *event, struct async_head_user *ahu);
    

    Toto systémové volání uloží event v kruhu dokončení. Protože vlákno běží asynchronně, není možné se vrátit uživatelského prostoru - ten si šel svou cestou ve chvíli, kdy došlo k prvnímu bloku. Takže async_thread() dá aktuální vlákno na seznam vláken, která budou k dispozici, až bude zase příště nějaké potřeba pro asynchronní spuštění.

    Uvedený popis vynechal několik detailů, především ohledně správy stacků v uživatelském prostoru. Stojí za povšimnutí, že na konci threadletového stacku patrně není žádná guard page [ochrana proti přetečení], takže je-li stack příliš malý, mohl by uživatelský prostor snadno způsobit přetečení. Výsledkem by pravděpodobně byly opravdu záhadné chyby, které by se těžko hledaly. Další změny API asi ještě přijdou, protože Ingo plánuje převést threadlet_on() a threadlet_off() na vsyscall, které by mohly být prováděny bez jakéhokoliv vstupu do jádra. To by samozřejmě výkonnost threadletů ještě zvýšilo.

    Přestože syslet API nabídlo zajímavé funkce, bylo hned jasné, že se s ním bude těžko pracovat. Nové threadlet API bylo navrženo tak, aby tyto problémy obešlo opuštěním celého konceptu "atomů" a umožněním co nejjednoduššího asynchronního spouštění uživatelského kódu. Mechanismus sysletů asi nezmizí, protože jde pořád o nejrychlejší způsob, ale pravděpodobně nebude používán jinde než ve speciálních jednoúčelových knihovnách, které zamaskují jeho složitost. Na všechno ostatní by se mohly hodit threadlety.

    Vlákna nebo události?

    link

    Pokračující diskuze o threadletech (nebo fibrilech nebo jak se budou jmenovat příští týden) přinesla také úvahy o přidání velkého nového API do jádra. Ta diskuze však vytrvale ignorovala důležitou otázku: a co patch kevent, který do jisté míry řeší stejné problémy? Motivací pro první patch s fibrily bylo poskytnutí ucelené podpory asynchronního I/O - a to byl i jeden z důvodů pro kevent. Takže je zvláštní, že si diskuze kevent nevšímala.

    Nakonec se však o kevent přeci jen začalo mluvit, což vyústilo v zajímavou výměnu názorů mezi vývojářem kevent Jevgenijem Poljakovem, vývojářem threadletů (a všeho možného) Ingo Molnarem a několika dalšími lidmi. Vzduchem létaly výsledky benchmarků ukazující výkonnostní charakteristiky obou přístupů, ale hlavní otázka zní takto: která metoda je nejlepší k tomu, aby mohly uživatelské aplikace škálovatelným způsobem pracovat s několika operacemi najednou?

    Jevgenij svoji argumentaci zakládá na tom, že přístup založený na událostech je přirozeně snadněji škálovatelný než použití vláken. Říká k tomu:

    Pokud něco znatelně snižuje výkon, je to špatné, ale je to také záležitost vkusu. Kevents jsou však každopádně malé, kdežto vlákna jsou velmi velká - a v obou případech je to záměr. Vlákna slouží ke zpracovávání jakéhokoliv kódu, kevents se používají k čekání na události - a IO je taková událost. Ke zpracování není potřeba velká infrastruktura - jen jednoduché kousky, takže to lze optimalizovat, aby bylo vše extrémně rychlé. S velikou infrastrukturou za každým IO (jako v případě samostatných vláken) to nejde udělat efektivně.

    Jinými slovy, používání vláken pro správu událostí je prostě příliš pomalé. David Miller také argumentoval tím, že vlákna nejsou vhodná pro síťové úlohy. Jednou z velkých výhod threadletů je to, že jsou velmi rychlé, když nedojde k blokování. Pří síťování se však blokování normálně očekává. Vícevláknová síťová aplikace by tak mohla v krátké době vytvořit obrovské množství vláken. Síťování je prostě činnost založená na událostech.

    Ingo nesouhlasí s tím, že by používání vláken a plánovače bylo pomalejší než udržování seznamů úkolů, které se promění na události:

    Podle mě je situace následující: fronta úloh plánovače [scheduler runqueue] je z koncepčního hlediska nahromaděná práce (pak jsou také registry, ale ty už jsou hardwarově optimalizované až na kost). Takže ať už je při plánování jakákoli režie, jde o čistě softwarovou záležitost...

    A teď si představte kevent jako model pro řazení do fronty. Nedává to do fronty 'úlohy', ale v podstatě nechává uživatelský prostor, aby do fronty zařazoval své požadavky v různém stavu. Ale koncepčně je to stále to samé: paměťový buffer s přiřazeným stavem. Pravda, není to ničím zatíženo, nemá to žádné priority ani připojené koncepty pro zařazování do fronty... zatím. Pokud by však rozhraní kevent začalo být používáno, vznikl by nátlak na začlenění 'pokročilejšího' řazení událostí do fronty a plánování událostí. Byla by potřeba podpora priorit atd.

    Jde o to, že plánovač byl během let brutálně optimalizován. Vlastní režie přepínání kontextu je docela malá - možná i menší než režie systémového volání pro správu událostí. Jediným opravdovým rozdílem je to, že paměťová režie při udržování vláken je o dost vyšší než režie kevents. Ale Ingo tvrdí, že by to neměl být neřešitelný problém.

    Hlavní věc je však náročnost programování - jak na straně jádra, tak v uživatelském prostoru. V uživatelském prostoru potřebuje klasická, na událostech založená aplikace centrální smyčku, která se zablokuje pouze při čekání na události. Veškerá opravdová práce v rámci smyčky musí proběhnout bez blokování; kdyby se smyčka zablokovala, nahromadily by se události, ale aplikace by při tom nic nedělala. Blokování na špatném místě může poslat výkon do kytek. Ale předcházení blokování za každou cenu je přinejmenším obtížné a někdy úplně nemožné. Threadlety vývojáři aplikace umožní, aby se o blokování přestal starat; pokud se operace zablokuje, aplikace prostě pokračuje v nově vytvořeném vláknu.

    Obecněji řečeno, programy psané jako stavové stroje - styl vynucený modely založenými na událostech - bývají pro mnoho lidí těžko srozumitelné. A existuje několik jaderných operací (například otevírání souboru), které se mohou zablokovat na mnoha místech, a které prostě nelze naprogramovat ve stylu stavových strojů. Vícevláknové programy mají pro programátory, kteří nejsou připraveni uvažovat o otázkách souběžnosti, také připraveny různé nástrahy, ale přesto bývají snáze pochopitelné. Threadlety by mělo být relativně snadné programovat, protože umožňují implementaci jakékoliv sekvence volání ve vláknovém modelu. Taková je alespoň argumentace.

    A týká se to i jádra. Snaha o přidání asynchronního I/O založeného na událostech zaměstnávala množství velmi schopných vývojářů celé roky - a pořád je daleko k cíli. Vyžaduje to přidání zcela nové infrastruktury a aplikaci technik stavových strojů na zjevně sekvenční série událostí. Komplexnost patchů s asynchronním bufferovaným souborovým I/O to dokládá: na tomto kódu se pracovalo roky (chvíli ano, chvíli ne) a pořád není v hlavním stromě. A navíc u některých operací stále závisí na worker threads [pomocná vlákna]. Naproti tomu o threadletech jejich proponenti tvrdí, že umožňují spuštění jakéhokoliv systémového volání asynchronně, ačkoliv nepřidávají žádné složitosti ani režii.

    Diskuze nakonec dospěla do bodu, kdy zasáhl Linus. Podle něj nejde o volbu mezi mechanismem založeným na událostech nebo vláknech, protože existuje místo pro oba:

    Pro události používejte select/poll/epoll/kevent/cojávím. Ale PŘESTAŇTE TVRDIT, že byste pro to používali threadlety/syslety/AIO... Mechanismy zaměřené na události jsou pro události *lepší*. Ale zároveň jsou k *ničemu*, když se nejedná o události, ale o spouštění kódu, který se může na různých místech zablokovat.

    Z tohoto pohledu nejde o vybrání jednoho nebo druhého, ale o poskytnutí obojího, aby mohl být pro každou práci zvolen nejvhodnější nástroj. Vypadá to, že tento názor sdílí mnoho lidí, což znamená, že asynchronní mechanismus se v nějaké formě zanedlouho do jádra dostane. Rozhraní založená na událostech budou i nadále podporovaná; velká otázka však je, jestli jsou stávající rozhraní (především epoll) dostatečná, nebo by bylo dobré začlenit i kevents.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    CIJOML avatar 22.3.2007 08:57 CIJOML | skóre: 58 | Praha
    Rozbalit Rozbalit vše Bluetooth HID
    "podporu HID v subsystému Bluetooth" je uplne spatny preklad a pochopeni o co jde. Je to totiz presne naopak. HID v systemu Bluetooth je jiz plno let (jinak by take nemohly fungovat modrozube mysi a klavesnice), co ovsem nebylo podporovane jsou takzvane hotkeys, pro ktere bylo treba zvlastni kod jiz obsazeny v systemu HID a nebylo zadouci takovy kod duplikovat/znovu implementovat v ramci Bluetooth. Cekalo se tedy na to, az bude HID stack upraven, aby se mu daly z Bluetooth posilat primo udalosti hardwaru a nasledne je sam HID subsystem zpracoval bez asistence Bluetooth. HID z Bluetooth byl nasledne odstranen a nyni slouzi Bluetooth jen jako jakysi "virtualni kabel" a vsechny udalosti zpracovava HID subsystem, coz ma za nasledek funkcni hotkeys, spravne scankody pro klavesy v pripade kdy existuje alternativa dratova a bluetooth a mnoho dalsich pozitiv. Aktualni kod je mozno stahnout i jako patch na jadro 2.6.20 a to -mh1.
    22.3.2007 09:12 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Bluetooth HID
    Díky za objasnění. Na svoji obhajobu však musím poznamenat, že překlad je to správný - v originále je totiž skutečný význam trochu zakamuflován. V changelogu stojí:
        [Bluetooth] Add support for using the HID subsystem
    ale v LWN to bylo interpretováno jako:
        HID support in the Bluetooth subsystem
    -------

    Opraveno.
    22.3.2007 22:12 jikos
    Rozbalit Rozbalit vše Re: Bluetooth HID
    Nejde jen o hotkeys, ale o obecne jakoukoliv informaci ziskanou parsovanim HID deskriptoru daneho zarizeni.

    Do 2.6.20 byl parser HID deskriptoru ve vanille napevno zaclenen do USB HID kodu. Kdyz ho Bluetooth stack chtel vyuzivat, musel si ho zduplikovat (viz -mh patche), protoze nebylo mozne tento kod sdilet mezi USB HIDem a Bluetooth. Takove silene duplikovani kodu samozrejme nebylo mozne udrzovat ve vanille, proto to Marcel mel v separatnich patchich. Ve 2.6.20 jsem z usbhid oddelil ten obecny kod (parser, nezavisly na pouzite transportni vrstve), a ten uz je ted vyuzivan jak usb hid kodem (tak jak byl doposud), tak i Bluetooth kodem (pro zarizeni ktera nad BT transportni vrstvou HID poskytuji).

    Coz umoznuje i takove veci jako sdileni quirku pro ruzna zarizeni (napriklad Apple Mightymouse potrebuje ten samy quirk jak v USB tak BT verzi), ale to zatim jeste neni implementovano.
    CIJOML avatar 22.3.2007 23:48 CIJOML | skóre: 58 | Praha
    Rozbalit Rozbalit vše Re: Bluetooth HID
    Ahoj, on to sice duplikoval, ale ne vse a projevovalo se to navenek hlavne tou nefunkcnosti hotkeys. Jinak mas samozrejme pravdu, nechtel jsem zabihat do takovych podrobnosti - chodi sem hlavne zacatecnici.
    23.3.2007 09:16 astray
    Rozbalit Rozbalit vše Re: Bluetooth HID
    Dík za tu námahu. Pomůže to hodně lidem.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.