Portál AbcLinuxu, 5. května 2025 14:10
Jaderné noviny - 5. 9. 2007
Články
-
Jaderné noviny - 5. 9. 2007
Aktuální verze jádra: 2.6.23-rc5. Citáty týdne: 2× Andrew Morton. LinuxConf.eu: dokumentace a API pro uživatelský prostor. LinuxConf.eu: jak nenavrhovat jaderná rozhraní.
Obsah
Aktuální verze jádra: 2.6.23-rc5
link
Aktuální předverze je (k 5. 9. 2007) 2.6.23-rc5, kterou Linus vydal 31. srpna, těsně před odjezdem na kernel summit. Obsahuje slušnou řádku oprav; jádro se stabilizuje, ale než bude připraveno k vydání, bude ještě potřeba trochu práce.
Od vydání -rc5 přibylo do hlavního git repozitáře jen několik oprav.
Aktuální verze -mm stromu je 2.6.23-rc4-mm1. Mezi nedávné změny patří výrazné interní implementační změny v sysfs, změny API pro souborové systémy, patche pro odstranění sysctl() a patche pro regulaci využití paměti v kontejnerech.
Aktuální stabilní verze řady 2.6 je 2.6.22.6, vydaná 30. srpna s pár desítkami oprav.
Citáty týdne: 2x Andrew Morton
link
Chceme-li administrátorům systémů něco vzkázat, neměli bychom je nutit ten vzkaz hledat v gitu a diskuzích na LKML!
-- Andrew Morton
Soudě podle počtu a vážnosti hlášení o chybách, která tu létají, není 2.6.23 zrovna na spadnutí.
-- Andrew Morton
LinuxConf.eu: dokumentace a API pro uživatelský prostor
link
Michael Kerrisk, od roku 2004 správce linuxových manuálových stránek, přednesl během prvního dne konference LinuxConf Europe 2007 řeč o hodnotě dokumentace. Ačkoliv je dokumentace užitečná i pro koncové uživatele, na ně se Michael nezaměřoval; místo toho mluvil o tom, jak může dokumentace pomoci dělat lepší jádro. Psaní dokumentace podle Michaela odhaluje chyby a špatné návrhy rozhraní, než se stanou součástí vydaného jádra. A to může ušetřit spoustu nepříjemností jak vývojářům jádra, tak uživatelských aplikací.
Michael nabídl tři příklady na ukázku toho, jak může psaní dokumentace odhalit chyby:
- Rozhraní inotify bylo přidáno do jádra 2.6.13. Šlo o vylepšení způsobu posílání upozornění aplikacím při změnách adresářů nebo souborů. Kolem verze 2.6.16 se Michael dostal k napsání manuálové stránky pro toto volání, ale zjistil, že jedna volba (IN_ONESHOT) nikdy nefungovala. Jakmile byl problém objeven, oprava byla rychlá - ale nejprve se někdo musel pokusit rozhraní zdokumentovat.
- splice() bylo přidáno do 2.6.17. Michael zjistil, že bylo snadné napsat program, který zatuhne, aniž by ho šlo odstřelit; snadno šlo také zatuhlými procesy systém zahltit. Opět byl problém rychle opraven, jakmile se na něj přišlo.
- Rozhraní timerfd(), které bylo začleněno do 2.6.22, nefungovalo ta, jak mělo. Některé nedostatky byly popsány v článku timerfd() a kontrola systémových volání.
Podle Michaela je přítomnost vadných rozhraní ve stabilních vydáních jádra důsledkem nedostatečného testování -rc verzí během vývojového procesu. S tímto problémem může pomoci lepší dokumentace. Ta by ostatně mohla pomoci i při samotném návrhu API. Navrhování API je složité a ještě jej ztěžuje fakt, že chyby v návrhu musí být podporovány navždy. Takže cokoliv pomůže s vytvářením lepších API si zaslouží pozornost.
Dobré API se vyznačuje jednoduchostí, snadností použití, obecností, konzistencí s dalšími rozhraními a integrací s dalšími rozhraními. Špatně navržená rozhraní tyto vlastnosti nemají. Jako příklad nabídl Michael rozhraní dnotify - předchozí pokus o poskytnutí služby, která by informovala o změnách souborů. Dnotify mělo problémy kvůli používání signálů, což je vždy zárukou obtížně použitelného rozhraní. Mohlo sledovat pouze adresáře, ne jednotlivé soubory. Vyžadovalo také udržování otevřeného popisovače souborů, takže nebylo možné odpojit žádný souborový systém, kde bylo dnotify používáno. Množství informací poskytovaných aplikacím bylo také omezené.
Jako další příklad byla uvedena systémová volání mlock() a remap_file_pages(). Obě mají parametry start a length pro určení rozsahu ovlivněné paměti. Rozhraní mlock() zaokrouhluje parametr length na další stránku, kdežto remap_file_pages() zaokrouhluje dolů. Rozhraní se liší také v tom, kdy parametr length uplatňují. Výsledkem je, že volání
mlock (4000, 6000);
ovlivní bajty 0..12287, zatímco
remap_file_pages (4000, 6000, ...);
ovlivní bajty 0..4095. Taková nekonzistence vývojářům znesnadňuje práci.
O tom, jak jsou tato rozhraní špatná, by se dalo vyplýtvat hodně bitů, ale Michael položil i otázku, jestli je to vůbec chyba jejich autorů. Nepřispěla k těmto problémům také absence kontroly?
Mnohé potíže pramení ze skutečnosti, že ti, kdo rozhraní systémových volání navrhují (hackeři jádra), obvykle daná rozhraní nepoužívají. Ve snaze zlepšit situaci Michael navrhl formalizaci vývojového procesu rozhraní systémových volání. Uznal sice, že bude těžké něco takového prosadit, ale potřeba vytvářet bezvadná rozhraní z toho dělá nutnost. Takže by rád docílil zavedení formální povinnosti podepisování [signoff] API - i když neupřesnil, kdo by podepisoval. Než by mohlo k podpisu dojít, musela by proběhnout kontrola návrhu, musela by existovat kompletní dokumentace a sada testů. Testy by musely být alespoň zčásti od někoho jiného než vývojáře rozhraní, který si nikdy nedokáže představit všechny bláznivé věci, které by s novým rozhraním mohli chtít uživatelé dělat.
Dokumentace je důležitou součástí procesu. Při psaní dokumentace často vyjdou najevo chyby. Kromě toho je díky dokumentaci pro ostatní snazší navrhovanému rozhraní porozumět, takže je více kontrolováno a testováno. Bez testování ze strany vývojářů aplikací se na chyby v novém API často přijde až po zařazení do stabilního vydání jádra, kdy už je pozdě.
Při následné debatě se mluvilo tom, že přimět vývojáře aplikací, aby testovali systémová volání v -rc jádrech bude obtížné. Alternativou, která už byla zmíněna dříve, by bylo označovat po několik vývojových cyklů od přidání nová systémová volání jako "experimentální". Pak by bylo možné vyzkoušet nová volání bez provozování testovacích jader a pořád mít vliv na to, jak bude finální podoba API vypadat. Možná by bylo snazší vývojáře jádra přesvědčit k tomuto postupu, místo komplikovaného formálního schvalování. Jak tato diskuze dopadne, to bude záležet na tom, nakolik vývojáři považují současný způsob návrhu a nasazování nových API pro uživatelských prostor za problém.
LinuxConf.eu: jak nenavrhovat jaderná rozhraní
link
Následující den přednesl Arnd Bergmann řeč o tom, jak nenavrhovat jaderná rozhraní. Začal tím, že dobrá rozhraní jsou navrhována "vkusně"; ale rozhodování o dobrém vkusu není vždy snadné. Vkus je subjektivní a časem se mění. Některé charakteristiky vkusného rozhraní jsou však jasné: jednoduchost, konzistence a používání správného nástroje pro daný úkol. Je to samozřejmě velmi podobné tomu, co říkal Michael den předtím.
Jak tomu bývá i v jiných oblastech, návrhy rozhraní se nejlépe popisují pomocí poukazování na věci, které by se dělat neměly. Arnd začal systémovými voláními, která jsou primárním rozhraním jádra. Přidávání nových systémových volání není snadné; nejprve musí projít množstvím kontrol (ačkoliv, jak bylo zmíněno výše, pořád jich patrně není dost). Ale často může být alternativní řešení ještě horší; Arnd uvedl jako příklad hypotetické zařízení /dev/exit; proces, který dokončil svou práci, by se ukončil otevřením a zápisem na toto zařízení. Takové schéma by umožnilo odstranění systémového volání exit(), ale v žádném případě by se nejednalo o vkusnější rozhraní.
Systémové volání ioctl() je už dlouho terčem kritiky; není typově bezpečné, těžko se skriptuje a představuje snadný způsob, jak do jádra propašovat změny ABI, aniž by si toho někdo všiml. Na druhou stranu je dobře zavedené, snadno rozšiřitelné, funguje v modulech a může poskytnout dobrý způsob k prototypování systémových volání. A snaha o obcházení ioctl() může opět vést k horším věcem; Arnd představil příklad z kódu InfiniBand, který interpretuje data zapsaná do speciálního popisovače souboru, aby mohl spouštět příkazy. Výsledkem je v podstatě ioctl(), ale ještě méně přehledné.
Sokety jsou další dobře zavedené rozhraní, které by, podle Arnda, v současné době nebylo do jádra za žádnou cenu přijato. Jsou naprosto nekonzistentní se vším ostatním, pracují se zařízeními, která nejsou součástí stromu zařízení, mají volání pro čtení a zápis, ale nejsou to read() a write() a tak dále. Netlink, který rozhraní soketů ještě zkomplikoval, zrovna situaci v uživatelském prostoru nepomohl; podle Arnda je lepší se jejich použití vyvarovat. Ale podstatné je, že je lepší použít netlink, než jej vynalézat znovu. API bezdrátových rozšíření [wireless extensions] bylo uvedeno jako další příklad, jak věci nedělat; založení bezdrátových rozšíření na netlinku zkombinovalo do jediného rozhraní nejhorší vlastnosti soketů a ioctl().
"V módě" je teď navrhování nových rozhraní s pomocí virtuálních souborových systémů. Ale i s tím jsou potíže. /proc se stalo smetištěm nových rozhraní, dokud se na přidávání dalších věcí nezačali vývojáři dívat přísněji. Sysfs bylo zamýšleno jako řešení mnoha problémů s /proc, ale zjevně nebyl vyřešen problém se nestabilitou API. Virtuální souborové systémy jsou možná nejlepší způsob vytváření nových rozhraní, ale i tam číhají nepříjemnosti.
Nakonec se mluvilo o navrhování rozhraní, která by usnadnila emulaci ABI. Arnd navrhoval, aby byly datové struktury stejné v jádře i uživatelském prostoru. Je-li to možné, neměly by se používat long proměnné a ukazatele. K problémům může vést i vatování struktur [structure padding] - ať už explicitní nebo způsobené špatně zarovnanými poli. A tak dále.
Byla to zajímavá přednáška s velkou účastí publika. Součástí Linuxu je množství chyb v návrhu uživatelských rozhraní, která musejí být už navždy podporována. Je však také velký zájem se podobným chybám v budoucnu vyhnout. I s mnoha zkušenostmi jde však pořád o velmi obtížný problém.
Související články
Odkazy a zdroje
Další články z této rubriky
Diskuse k tomuto článku
18.9.2007 01:25
trekker.dk | skóre: 72
Re: Jaderné noviny - 5. 9. 2007
18.9.2007 07:22
cronin | skóre: 49
Dokumentovanie odhaľuje chyby
18.9.2007 14:41
lm
Re: Jaderné noviny - 5. 9. 2007
19.9.2007 10:34
Jirka
Re: Jaderné noviny - 5. 9. 2007
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
Michael Kerrisk, od roku 2004 správce linuxových manuálových stránek, přednesl během prvního dne konference LinuxConf Europe 2007 řeč o hodnotě dokumentace. Ačkoliv je dokumentace užitečná i pro koncové uživatele, na ně se Michael nezaměřoval; místo toho mluvil o tom, jak může dokumentace pomoci dělat lepší jádro. Psaní dokumentace podle Michaela odhaluje chyby a špatné návrhy rozhraní, než se stanou součástí vydaného jádra. A to může ušetřit spoustu nepříjemností jak vývojářům jádra, tak uživatelských aplikací.
18.9.2007 10:09
