Portál AbcLinuxu, 29. dubna 2024 06:32
2.6.24-rc1, "Jeden z největších -rc v historii". Kvalita kódu sjednocené architektury x86. Zlepšení správy paměti. Subsystém distribuovaného úložiště míří do -mm. DMA framework. Infrastruktura upozorňující na asynchronní události. Víceúčelový vstupně/výstupní framework.
Následující obsah je © KernelTrap.
24. říjen, originál
Tenhle -rc patří mezi největší -rc v historii. Je obrovský. Obvykle má zkomprimovaný -rc1 diff kolem 3 - 5MB, občas jsou i menší a občas mají některé nanejvýš 6 M, nicméně tenhle má "jedenáct" mega. Takto Linus Torvalds ohlásil první release candidate nadcházejícího jádra 2.6.24. Shrnul některé ze změn: Ve zkratce jsme měli nejenom neobvykle velké množství novinek pro x86, ale také tuny nových ovladačů (nejvíc pro bezdrátové síťování, ale to rozhodně není jediné - připojují se dvb, normální drátové sítě, mmc atd.), značné množství záležitostí okolo architektur, souborových systémů, síťování atd.
Jinými slovy, ani nevím, kde začít. Velká a nepřehlédnutelná záležitost je sjednocení x86 a myslím si, že si všichni moc a moc přejeme, aby to nezpůsobilo žádné problémy. Zatím to byla klidná plavba (zaklepat na dřevo). Méně hladké byly změny rozsyp-sesbírej [scatter-gather] v blokové vrstvě, ale ty už jsou doteď snad také v přijatelném stavu. A změny ve VM? Upřímně doufám, že si jich ani nikdo nevšimne. Totéž platí pro nějaké změny ve VFS vrstvě, které ovlivnily v podstatě každý souborový systém (nicméně většinou velmi zřetelným způsobem).
24. říjen, originál
Mohli bychom, prosím, trochu více dokončit tohle začlenění předtím, než zmrazíme 2.6.24? To, co zbylo po arch/i386 a arch/x86_64, je v porovnání se stavem po sloučení jiných architektur noční můra, ptal se Christoph Hellwig, což vedlo Ingo Molnára k sepsání vysvětlující odpovědi: Abychom mohli odpovědět na tuto otázku, je nejprve třeba mít v patrnosti základní problémy s kvalitou kódu, které sjednocená architektura x86 zdědila od i386 a x86_64.
Následně použil skript checkpatch a vytvořil tabulku chyb stylu programování na tisíc řádků zdrojového kódu. V jeho tabulce mělo arch/i386 77,3 chyb na tisíc řádků a arch/x86_64 96,0. Nová sjednocená arch/x86 měla méně - 74,1 - což je ale stále hodně. Je dost zjevné, že kvalita kódu architektur x86_64 a i386 byla před sjednocením ve strašném stavu. Byla řádově horší než jádro jádra [core kernel] a významně horší než několik porovnatelných architektur.
Takže k odpovědi na tvou otázku: plné sjednocení není jednoduchý úkol a rozhodně to není automatické. Kvůli jejich nelogickému a vynucenému oddělení a následné degeneraci se během pěti let strom x86_64 odlišil od stromu i386. V obou architekturách se objevily různé sady problémů s čistotou a různé sady funkcí se zbytečnými rozdíly, které často pokrývají stejnou funkčnost. K tomu všemu se přidává fakt, že 64bitový kód je v horším stavu než 32bitový, takže nemůžeme jen tak vzít 64bitový kód a použít ho jako unifikovaný. 32bitový kód je také používán 8 až 10× častěji než 64bitový, takže žádná "prostě to sjednotíme" cesta neexistuje.
27. říjen, originál
Nedávné hlášení na LKML naznačovalo zlepšení výkonu IO/writeback v nedávno uvolněném jádře 2.6.24-rc1 v porovnání se staršími jádry 2.6.19.2 a 2.6.22.6. Zásluha na tom je přisuzována patchům od Petera Zijlstra. Ingo Molnar reagoval: Wow, opravdu hezké výsledky! Peter ví, jak věci zrychlit :). Pojďme zařadit také jeho další dříve nepřijaté patche :-). Ukázal na několik patchů pro začátek a zavtipkoval: Myslím si, že MM (memory management, správa paměti) by se měl dostat z režimu hlubokého zmrazení vlastností - je tam spousta prostoru ke zlepšení :-/
To jsou vtipy, odpověděl Andrew Morton, do 2.6.24-rc1 jsme zařadili okolo 265 MM patchů: 482 souborů změněno, 8071 vložení (+), 5142 výmazů (-). Spousta z toho byly nové funkce - je jednodušší přidávat než měnit něco, co dlouhodobě funguje, dodal. Peter poznamenal, že z patchů, na které Ingo poukazoval, zrovna pracuje na vylepšování patche pro swapování přes NFS. Brzo ho zašlu znovu... obzvlášť poté, co Linus řekl, že by se mu líbilo mít swap přes NFS. Rik van Riel se vyjádřil o kódu nahrazování stránek: V tuto chvíli mám hotovou jenom základní "instalatéřinu" rozdělené virtuální paměti [split VM] a opravuji v tom nějaké chyby. Ohledně toho v blízké době očekávejte sérii patchů, abyste mohli ten kód projít a říct mi, jak ho trochu víc dotlouct do správného tvaru :-)
27. říjen, originál
Andrew Morton přijal kladně nejnovější verzi subsystému distribuovaného úložiště [distributed storage subsystem] Evgenije Poljakova. Prošel jsem si a znovu přečetl diskuze z posledního měsíce a nevidím důvod, proč bychom neměli začít uvažovat nad začleněním. Potom se zeptal: Jak blízko je to k takovému stádiu? Nahlédnutí do tvého vývojářského blogu naznačuje, že věci se ještě střední rychlostí mění. Evgenij odpověděl:
Dokončil jsem vývoj ukládací vrstvy jako takové, jediná zbývající todo položka je implementace nového algoritmu redundance, ale to nevidím jako významný požadavek, takže pro teď to má malou prioritu. Jako transportní vrstvu pro distribuovaný souborový systém použiji DST, které pravděpodobně bude vyžadovat další funkce. Zatím nemám připravený žádný hotový design a právě teď nemám nic k začlenění do DST.
28. říjen, originál
Tento patch opravuje to, co, jak doufám, jsou nesprávné předpoklady o vrstvě DMA enginu. Nejenom že hardware od Intelu(r) umí DMA, ale DMA se dá použít i pro jiné věci než memcpy a snižování zátěže RAIDu (RAID offloading), popsal Haavard Skinnemoen svůj malý patch k popisu volby DMADEVICES v Kconfig. Dodal: Nechápejte mě špatně; myslím si, že si Intel zaslouží hodně respektu za vytvoření tohoto frameworku. Nicméně, to je také důvod, proč jsem byl trochu zklamán, když jsem zjistil, že se zdá být poněkud méně obecný, než jsem původně doufal.
DMA řadiče, které mohou podporovat čistou akceleraci memcpy dodatečně k tradičnějším slave DMA, jsou velmi běžné v SoC (system on chip, systém na čipu) zařízeních a já si myslím, že Linux pro to potřebuje společný framework. Existující DMA engine framework se tomu zdá být docela blízký, ale myslím si, že potřebuje víc vstupů z toho davu embedded zařízení předtím, než bude zcela použitelný pro velké množství embedded systémů.
29. říjen, originál
Jeff Garzik zaslal sérii dvou patchů zavádějící infrastrukturu upozorňující na asynchronní události [asynchronous event notification infrastructure], která zpřístupňuje SATA asynchronní upozorňování [asynchronous notification, AN] pro CD/DVD zařízení, která je podporují.
U zařízení, která podporují SATA AN (což umí jenom ta nejnovější), to znamená, že HAL a další uživatelské utility se nepotřebují opakovaně dotazovat CD/DVD zařízení, aby zjistily, jestli uživatel nevyměnil nosič.
První patch je pro ovladač SCSI. Je založen na práci Kristena Carlsona Accardiho, společně s pořádnou pomocí od Jamese Bottomleyho. Druhý patch aktualizuje libata, aby mohla použít novou infrastrukturu SCSI událostí.
30. říjen, originál
Víceúčelový vstup/výstup [General Purpose Input/Output, GPIO] je flexibilní softwarem řízený digitální signál. Tyto signály poskytuje mnoho druhů čipů a znají je vývojáři Linuxu, kteří pracují s embedded a zakázkovým hardwarem, začíná Documentation/gpio.txt.
K nedávné sérii čtyř patchů David Brownell poznamenal: Když jsme minulý rok sepsali Documentation/gpio.txt - Programovací rozhraní GPIO, objevilo se tam několik vlastností v kategorii "tohle bychom časem chtěli, ale prozatím bez toho budeme živi". V tomto postu následuje několik patchů, které některé z těchto vlastností přidávají. Potom pokračoval popisem dvou nových vlastností zavedených, které patch přidává:
1) Implementace frameworku v lib/gpiolib.c... rozhraní poskytované uživatelům GPIO se nemění, ale poskytovatelé se nyní mohou připojit [hook up] přes "gpio_chip", který umožňuje koexistenci několika typů poskytovatelů GPIO. Příklady: SoC-nativní GPIO, jaká poskytují FPGA, I2C, SPI GPIO expandery atd.
2) I2C ovladač pro GPIO expandery pcf8574/8575... Na embedded hardwaru jsou vcelku běžné a v externích stromech je obvyklé mít ošklivé, pro jednotlivé desky specifické hacky, které dané GPIO zpřístupňují ovladačům. Myslím si, že na rozdíl od takových hacků by použití standardních GPIO volání mělo být začlenitelné do upstreamu.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.