Portál AbcLinuxu, 5. května 2025 19:05
Začleňovací plány pro ext4 v 2.6.25. Dm-band, ovladač šířky pásma blokového I/O. Jádro 2.6.24, "doufejme, že je dobré". Začlenění plánovače pro 2.6.25. Jádro [core] ovladačů - patche v začleňovacím okně 2.6.25. SCSI cíle. Vylepšení KVM v 2.6.25. Začlenění v x86 architektuře v 2.6.25.
Následující obsah je © KernelTrap.
22. leden, originál
Následující patche byly nějakou dobu v -mm stromě a plánuji je předat Linusovi, až se otevře začleňovací okno pro 2.6.25, řekl Theodore Ts'o a nabídl patche k posouzení předtím, než budou začleněny. Vysvětlil, že patche zavádějí některé z posledních změn formátu ext4 na disku. Ext4 by ještě neměl být nasazován na produkční systémy, ačkoliv vzdáváme poctu všem, kteří chtějí být pokusnými králíky a s tím kódem si hrát.
S touto sérií patchů se očekává, že se formát ext4 bude usazovat. Stále ještě odkládáme alokaci a defragmentaci za běhu, které nejsou zcela připraveny k začlenění, ale ty by formát na disku neměly ovlivnit. V tuto chvíli neočekávám ve formátu žádné další změny, ale i dřív jsme se mýlili... jakékoliv změny by teď měly mít Velmi Dobrý Důvod.
Vývoj jádra Linuxu není řízen lidmi, kteří tlachají o tom, co by v něm chtěli v budoucnu vidět, ale lidmi, kteří posílají patche.
Adrian Bunk, zpráva z 22. ledna 2008 na Linux Kernel mailing list
24. leden, originál
S radostí oznamuji, že jsem implementoval ovladač šířky pásma pro blokové I/O, oznámil Ryo Tsuruta. Dodal, že ho zamýšlel využít v kontrolních skupinách nebo prostředí virtuálního stroje. V současnosti je implementován jako ovladač device-mapper. Podrobněji popsal implementaci založenou na žetonech, které dm-band distribuuje různým skupinám - skupina předává I/O požadavky vrstvě pod ní, pokud jí zbývají žetony, a blokuje je, pokud jí žádné žetony nezbývají. Pokaždé, když skupina předá I/O požadavek, jeden žeton je spotřebován. Jakmile všechny skupiny spotřebují své žetony pro dané fyzické zařízení, dm-band je doplní.
Dm-band je ovladač šířky pásma I/O implementovaný jako device-mapper ovladač. Pokud několik úloh využívá stejné fyzické zařízení, musí se dělit o šířku pásma k tomuto zařízení. Dm-band každé úloze přiděluje pásmo odpovídající váze úlohy, kterou si každá úloha může nastavit. V tuto chvíli je úlohou skupina procesů se stejným pid nebo pgrp nebo uid. Je také v plánu, aby byly podporovány kontrolní skupiny. Úlohou může také být virtuální stroj, jako je KVM nebo Xen.
Takže si to ujasněme... navrhuješ zavedení zbytečného a ošklivého makra do jádra, protože ve vimu je chyba? *Buch!*
H. Peter Anvin, zpráva z 24. ledna 2008 na Linux Kernel mailing list
24. leden, originál
Jádro je venku (jak gitové stromy, tak tar archivy/patche) a během příštího týdne bude mnoho vývojářů na LCA v Melbourne (nebo v letadle na cestě tam/zpět), takže doufejme, že je dobré, řekl Linus Torvalds v oznámení jádra 2.6.24. Poznamenal, že od -rc8 se neudálo nic zemětřesného. Změny na úrovni zdrojového kódu si lze prohlédnout pomocí gitwebového rozhraní. Hezký přehled všech změn lze najít na Kernel Newbies.
V následující diskuzi Linus dodal: Protože už se mě dva vývojáři jádra ptali na začleňovací okno a jestli na něj bude mít vliv cestování lidí (včetně mě), plán je takový, že se pokusíme dopad co nejvíce omezit. Takže ano, okno bude pravděpodobně prodlouženo ze standardních dvou týdnů, ale doufejme, že ne o více než pár dní.
Byla jednou žádost o test
k vidění tak často, že nešlo to snést.
Označili jsme ji ignorovat,
ještě častěji však bylo ji pozorovat,
až všichni volali, "Ty jsi na pěst."
Darrin Chandler, zpráva z 29. ledna 2008 na OpenBSD -misc mailing list
26. leden, originál
Ingo Molnár zaslal požadavek na začlenění nejnovějšího gitového stromu plánovače - obsahuje různá vylepšení - kompletní zkrácený log [shortlog] je dole. 96 commitů od 19 autorů - vývojáři plánovače se opět snažili :-/. Plánovací chování jádra vůči běžným uživatelům se od v2.6.24 nemění, ale pod kapotou se zavádí mnoho nových vlastností. Ingo pokračoval výčtem některých z těchto vlastností:
Myslím, že by tě ohromilo, jak moc je mi to ukradené a, když nepočítám jejich humornou hodnotu, jak málo si cením právních posudků od kolegů programátorů.
Rusty Russel, zpráva z 30. ledna 2008 na Linux Kernel mailing list
29. leden, originál
V předmluvě k sérii 196 patchů Greg KH poznamenal: Kvůli nízkoúrovňové povaze těchto patchů a protože se dotýkají tolika různých částí jádra, mě několik správců subsystémů požádalo, abych je nechal začlenit, aby se zjednodušilo začleňování do ostatních stromů. Linus Torvalds souhlasil a rychle patche zařadil do svého. Greg změny shrnul:
struct bus_type
byla přepracována, takže teď řádně zpracovává pravidla životnosti [lifetime rules], stejně jako kobject je řádně dynamický;struct driver
byl také přepracován a nyní jsou řešeny záležitosti ohledně životnosti;struct device
, nikoliv čistý kobject;struct device.
Jsi polapen v bludišti malých a matoucích patchů dokumentace, z nichž všechny jsou pedantické.
Valdis Kletnieks, zpráva z 30. ledna 2008 na Linux Kernel mailing list
31. leden, originál
Jak pravděpodobně víte, v podnikových řešeních výpočetní techniky se objevuje trend používat síťová úložná zařízení. Dokládají to standardy jako SRP (SCSI RDMA Protocol), iSCSI (Internet SCSI) a iSER (iSCSI Exetensions for RDMA), které se objevily v posledních pár letech, začal Bart Van Assche svůj návrh, aby SCST bylo zařazeno do hlavní řady jádra. Dodal, že SCST je sice podobné projektu STGT, který je součástí jádra od 2.6.20, ale SCST převyšuje STGT co se týče vlastností, výkonnosti, dospělosti, stability a počtu existujících cílových ovladačů. Bohužel jaderný kód SCST žije mimo jaderný strom, což způsobuje, že je obtížnější ho používat.
Správce SCSI subsystému James Bottomley nebyl zcela přesvědčen: Tyto dvě cílové architektury provádějí v podstatě ty samé funkce, takže v jádře je skutečně místo jenom pro jednu. V tomto případě je to STGT. Problémy s STGT pocházejí z hranice uživatel<->jádro a dají se mnoha způsoby omezit. To ukazuje fakt, že grafy jsou na ne-IB (ne-Infiniband) sítích vcelku srovnatelné.
Skutečně potřebuji o hodně víc důkazů, než je v nejhorším případě 20% rozdíl ve výkonnosti, na to, abych jednu implementaci vyhodil a nahradil ji jinou. Obzvlášť v případě, že není žádný skutečný důkaz o tom, že STGT nemůže být poladěno tak, aby těch 20 % nedohnalo i na IB.
Bylo by těžké zbytečně moc zdůrazňovat, jak nevyváženou ekonomiku tady máme. Ušetřil jsi možná třicet člověkovteřin tím, že jsi přeskočil prohlídku toho patche a checkpatch. Nicméně cena (kdyby se chyba dostala do hlavní řady) by byla mnoho mnohotisíckrát větší než tohle.
Andrew Morton, zpráva z 1. února 2008 na Linux Kernel mailing list
1. únor, originál
Avi Kivity shrnul kvm patche připravené pro jádro 2.6.25: Změny zahrnují vylepšení škálovatelnosti a výkonu, dokončení prací na přenositelnosti (i když v tomto návrhu nejsou žádné nově podporované architektury), podporu pro nové vlastnosti hardwaru, používání obecné paměti uživatelského prostoru (což umožňuje swapování paměti hosta stejně jako sdílení paměti mezi hosty) a jako obvykle pročištění a opravy.
Projekt Jaderný virtuální stroj [Kernel-based Virtual Machine] - kvm - byl zahájen během roku 2006 a součástí jádra je od verze 2.6.20 vydané v únoru 2007. Nedávné změny lze prohlížet přes gitweb.
I podle vysoko nastavených standardů LKML, které občas vypadají, že z dezinformace dělají umění, čtyři špatné výroky v dvaceti sedmi slovech, to je vcelku působivé... klaním se ti!
James Bottomley, zpráva z 1. února 2008 na Linux Kernel mailing list
1. únor, originál
Ingo Molnár shrnul svůj požadavek na přetažení změn v architektuře x86, které mají být začleněny do hlavní řady v 2.6.25: Není to malé začlenění, skládá se z 908 commitů od 96 různých vývojářů arch/x86 (!) Mnoho základních souborů [core files] se mění také: nejvýznamněji percpu, detaily ladění, časovače, patch pro vzdálené ladění přes firewire a ... pahýl po KGDB vzdálené ladění v kernel/kgdb.c Pokračoval podrobnostmi o rozsahu testování, kterým tento strom prošel: V uplynulých několika týdnech byly přeloženy desítky tisíc náhodných x86.git bzImage, které nabootovaly na několika (běžných) 32bitových a 64bitových testovacích systémech. Také jsme to několikrát testovali v -mm.
Ohledně vzdáleného ladění jádra Ingo řekl: Podle testování je KGDB začleněníhodný do architektury x86 (to je prozatím jediná podporovaná architektura) a je lepší mít kernel/kgdb.c než arch/x86/kernel/kgdb.c. Kód je v rozumných mezích pročištěný a vystavení uživatelskému prostoru je minimální - jediné skutečné spojení je desítky let starý vzdálený [remote] GDB protokol. Rádi opravíme jakékoliv další věci ohledně čistoty, pokud budou nějaké připomínky, ale skutečně jsme chtěli někde začít a tuhle věc uvést do pohybu. A jako bonus navíc: konečně jaderný debugger, který lze číst bez přílišného zvracení ;-) (pamatuje někdo KDB?)
a ani az tak vtipne vystizne jako kdyz tu byly jenom tri na zacatku stranky.To si asi pleteš s JN od Roberta; tohle jsou překlady z kerneltrapu, tady byly citáty (od té doby, co je na kerneltrapu píšou) vždycky takhle.
deb http://ftp.cz.debian.org/debian jessie main contrib non-free
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.