AbcLinuxu:/ Články / Jaderné noviny 330

Štítky: AMD, e-mail, Eric, Git, hardware, IDE, KDE, kernel, komunikace, Linux, patch, PCI, programování, sběrnice, textové editory, USB, Version Control System, Vim

Jaderné noviny 330

25. 10. 2005 | Robert Krátký | Jaderné noviny | 4364×

uclinux portován na Blackfin CPU. Vytížení Andrewa. Linux 2.6.14-rc2-mm1. Správa subsystému I2C. Cogito 0.15.1 vydáno s důležitou opravou.

uclinux portován na Blackfin CPU, 8 e-mailů

20. zář - 27. zář

Luke Yang z firmy Analog Devices napsal: Portovali jsme uclinux na náš Blackfin procesor. Kód je teď aktualizovaný pro 2.6.13. Patch pošlu do konference. Zároveň se zeptal: Vím, že se blíží jádro 2.6.14. Mohl by být náš patch zařazen do 2.6.13? Deepak Saxena odpověděl: Ne. 2.6.13 je pro nové funkce uzavřeno, stejně jako 2.6.14 (pokud by nešlo o extra zvláštní případ, o kterém by Linus myslel, že je natolik důležitý, aby ho nechal ještě proklouznout). V tuhle chvíli je nejlepší poslat patche ke kontrole, provést požadované změny a být připraven poslat patch oproti 2.6.14 během prvního týdne po vydání, aby mohl být začleněn do 2.6.15. Luke tedy neváhal s patchem a Jesper Juhl navrhl pár technických věcí a rad k stylu.

Vytížení Andrewa, 28 e-mailů

20. zář - 26. zář

Eric W. Biederman poslal Linusi Torvaldsovi několik oprav týkajících se restartu a Pavel Machek řekl, že správný postup by byl to nejprve poslat Andrew Mortonovi, aby je začlenil do -mm stromu. Linus napsal:

Jedné věci se skutečně bojím. Že bude Andrew v jednu chvíli tam, kde já byl před pár lety - přepracovaný a vystresovaný díky hromadám patchů.

Sice napsal nebo upravil spousty různých nástrojů pro sledování patchů a začleňování pomocí gitu snad práci usnadňuje, ale i tak mi to dělá starosti. Kdyby Andrew vyhořel, zasáhlo by nás to velmi citelně.

Přemýšlím, jak tyhle problémy zmírnit. Vyhovuje mi -mm v roli pokusného králíka, takže cesta přes Andrewa je v tomhle směru výborná, ale má to své stinné stránky.

Andrew?

Andrew poznamenal: Patche jako takové moc času nezabírají. Hodně času ale vezmou patche, které nefungují - jeden špatný patch může zabrat hodiny a způsobit, že si o jeho původci začnu myslet ošklivé věci. A doplnil:

Zvládám to dobře.

Množství patchů nepředstavuje problém z hlediska prosté manipulace. V současné době je největší potíž s nedostatečnou kontrolou patchů. V této oblasti budu muset přitvrdit. Relativně málo vývojářů je ochotných provádět podrobné kontroly velkých patchů, takže by bylo fajn na to lidi trochu nasměrovat. Velmi oceňuji Christophovu práci, díky.

Říkáme to pořád, ale množství patchů skutečně jednoho dne opadne. Vlastně už u 2.6.15 se toho moc neděje.

Chyby jsou velký problém. Vydat -mm trvá nejméně 4 hodiny a jediná chyba může způsobit odsunutí na další den a pak musím začít znovu. Několikrát mi zabralo pár dní jen to, abych dal dohromady strom, který na čtyřech architekturách nabootuje a na sedmi půjde zkompilovat.

S chybami teď trávím více a více času. Máme stovky chyb, které lidi nahlásili, o kterých příslušní vývojáři vědí, a se kterými NIC NEDĚLAJÍ. "Nemohu to reprodukovat" není adekvátní odpověď, když jsou tu ochotní testeři, kteří mohou během odhalování problému pomoci. Jsou stovky počítačů, o kterých víme, že nefungovaly, a vývojáři si k opravování takových věcí prostě musí vyhradit trochu času.

Strom -mm filtruje velké množství chyb, aby se nedostaly do hlavního jádra - odhadoval bych, že proklouzne přibližně 10 procent. I když těch 90 procent jsou ty lehké věci - často jen kompilační chyby. Rád bych -mm vydával častěji a také bych byl rád, kdyby nemělo reputaci divokého a špatného kódu. Obojí by šlo, kdyby si autoři patchů dali více záležet na testování.

V jednu chvíli napsal Eric: Pro lidi, kteří jako já pracují na částech jádra bez správců, je to zvlášť problematické, protože často není k mání žádný prostředník, kterému bych patche mohl posílat. A Andrew napsal:

Jo. A soubor MAINTAINERS není zrovna kompletní. Já většinou vím, do koho šťouchnout, a když není po ruce zřejmý adresát, mám 26000 patchů, které mohu grepnout, abych zjistil, kdo by o daném kódu mohl něco vědět. S nízkoúrovňovým x86 je docela potíž, protože má hodně kuchtíků, ale žádného jasného šéfkuchaře.

Jednotliví správci odpovídají každý jinak rychle, liší se pečlivostí i procentem opuštěných patchů.

Zmatky nastávají také ve chvíli, kdy pošlu kopii zprávy o patchi správci. Mám pak patch Linusovi poslat já nebo chci, aby to udělal správce?

Má-li správce strom v -mm, tak patch automaticky nechám být, jakmile ho správce začlení, takže v takovém případě je vše jasné.

Když správce řekne "díky, začleněno", ale nemá strom v -mm, pak většinou patch držím donekonečna, až se konečně objeví u Linuse. Nebo na něj nakonec zapomenu a začlením ho stejně ;).

Když správce patch pouze schválí, pošlu ho Linusovi.

Když správce patch neschválí, tak ho buď vypustím nebo označím, že nemá být začleněn a podržím ho, abych si pamatoval, že máme chybu, kterou je potřeba opravit.

Má-li správce strom v -mm a patch nezačlení, ponechám si ho, abych jej mohl občas správci poslat, dokud nepřijde nějaká konečná odpověď.

Alexander Nyberg připojil: A navíc je bugme.osdl.org hodně nevyužitý (světlou výjimkou je ACPI) a Andrew se tam hodně angažoval. Na spoustu hlášení o chybách v té konferenci odpovídá pouze Andrew. Myslím, že by se mu mělo dostat daleko více pomoci, než v současné době dostává. Andrew odpověděl:

Ano, jaderný bugmeister je funkce úplně oddělená od honění patchů. Je to něco, co by mohl a měl dělat někdo další.

Uvažuji o tom, že vyvinu postupy, zjistím, co funguje, a pak se poohlédnu po jiném chudákovi, kterému bych to přenechal. Nebudu tvrdit, že se mi to v současné době daří. Možná proto, že tomu nevěnuji dost času, abych mohl ukázat, co funguje a co ne.

Neřekl bych, že bugmeister je na plný úvazek, ale na velkou část ano. Vyžaduje to někoho, kdo se nebude ostýchat, a kdo dobře rozumí jádru z hlediska kódu, procesů (heh) a lidí.

Musí mít schopnost udržovat si celkový přehled o tom, kde jsme, které chyby jsou vážné, a které ne. Schopnost výstižně tento přehled sdělit všem ostatním. Schopnost říct Linusovi "nemůžeš jádro vydat, dokud nebudou opraveny chyby A, B a C". Dovednosti a intuici potřebnou k tomu, aby rozlišil, který patch je ojedinělá záležitost a lze ignorovat, pokud se neobjeví znovu atp. Je to jedna z těch prací, která zabere všechen čas, který jí můžete věnovat.

Vývoj jádra je dnes profesionálnější než rádi předstíráme a vývojáři ocení, když to pro nás bude někdo dělat. Je to ale dost nuda.

Linux 2.6.14-rc2-mm1, 42 e-mailů

19. zář - 28. zář

Andrew Morton oznámil Linux 2.6.14-rc2-mm1:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/2.6.14-rc2-mm1/

Přidal jsem git strom `git-sas.patch': Ovladač a podpora SAS od Lubena Tuikova.
Různé další věci - nic zásadního.

Správa subsystému I2C, 36 e-mailů

22. zář

Greg KH poslal několik patchů pro USB a PCI v 2.6. Mezi nimi byl i jeden, který odstraňuje mé jméno z funkce správce I2C. Jean to teď vše zvládá lépe než já. Patch jako správce I2C stanovil Jeana Delvarea.

Cogito 0.15.1 vydáno s důležitou opravou, 1 e-mail

23. zář

Petr Baudis oznámil Cogito 0.15.1:

Oznamuji vydání verze 0.15.1 Cogita, uživatelsky přívětivého rozhraní pro Linusův GIT. Cogito najdete v:

http://www.kernel.org/pub/software/scm/cogito/

až bude zrcadlení kernel.org zase chvilku fungovat ;-) .

Posílám kopii do této konference, protože vydání obsahuje opravu chyby, která mohla způsobovat nepěknou ztrátu dat. A pravděpodobně se to týká všech uživatelů Cogita (byla tam od verze cogito-0.11.2). Pokud jste měli nějaké lokální necommitované změny a začlenili jste nové věci (buď pomocí cg-update nebo cg-merge), v některých případech cogito potichu zlikvidovalo vaše lokální změny. Způsobovalo to nesmyslné volání git-checkout-cache, na které upozornil Linus.

V originálu Kernel Traffic 330 vyšla navíc ještě tato témata:

Tento článek vychází ze seriálu Kernel Traffic (http://www.kernel-traffic.org) a je zveřejněn pod licencí GPL verze 2.