Jaderné noviny 308

11. 5. 2005 | Leoš Literák | Jaderné noviny | 4924×

Nový parametr kernelu kvůli x86_64. Status Serial ATA. Nový projekt Kernel Mentors. Navržen Mercurial Version Control System. Vývoj SCSI přechází z BitKeeperu na git.

Nový parametr kernelu kvůli x86_64, 3 e-maily

14. dub - 18. dub

Hariprasad Nellitheertha napsal:

Abychom mohli portovat kdump na x86_64, potřebujeme parametr kernelu memmap=. Důvodem je, aby dump-capture kernel mohl být nabootován s vlastní mapou paměti [custom memory map]. Přiložený patch přidává tuto funkčnost do kernelu x86_64. Byl sestaven oproti 2.6.12-rc2-mm3. Provedl jsem řadu testů a funguje v pořádku.

Andi Kleen odpověděl:

Měl bys někam přidat __setup, jinak si bude kernel stěžovat ohledně neznámých argumentů nebo vytvoří proměnnou memmap ve svém prostředí. Parsování čárky by bylo pěkné. Jinak to vypadá v pořádku.

Hariprasad reagoval s tím, že přidá __setup a parsování čárky.

Status Serial ATA, 12 e-mailů

15. dub - 16. dub

Jeff Garzik informoval o tom, že aktualizoval zprávu o stavu podpory SATA pod Linuxem. Pokud vás zajímá, jak jsou jednotlivé kusy hardwaru či určité vlastnosti specifikace podporovány, zamiřte na stránky http://linux.yyz.us/sata/.

Nový projekt 'Kernel Mentors', 1 e-mail

15. dub

Matt Mackall napsal:

Snad nejtěžším krokem na cestě stát se vývojářem jádra je zaslání první větší funkce. Je nutné překonat technické i sociální překážky a tento proces může být odrazující pro někoho, kdo je v komunitě nový. Proto navrhuji neformální projekt, kde by zkušení vývojáři dohlíželi nad novými vývojáři a trénovali je, jak nejlépe připravit kód pro zaslání.

Vývojáři zašlou popis svých projektů a aktuální stav, stejně jako odkaz na zdrojáky do emailové konference kernel-mentors. Rádci si sami vyberou projekty a vývojáře, se kterými by chtěli pracovat a nabídnout jim svou pomoc.

Rádce bude pomáhat svému vývojáři, aby jeho kód byl přijat:

• prohlížením kódu a návrhy, jak jej zlepšit
• obeznámením vývojáře s nejlepšími praktikami pro zasílání kódu
• informováním vývojáře, co má očekávat od procesu zasílání kódu

Od nových vývojářů se očekává, že použijí rady efektivně a časem se jím podaří začlenit svůj kód!

Adresa konference je kernel-mentors@selenic.com s webovým rozhraním http://selenic.com/mailman/listinfo/kernel-mentors. Pokud vás to zaujalo, přidejte se k nám.

Navržen Mercurial Version Control System, 2 e-maily

20. dub - 22. dub

Matt Mackall napsal:

http://selenic.com/mercurial/

April 19, 2005

Strávil jsem několik posledních týdnů prací na zcela novém prototypu SCM [source code management]. Cíle:

• z počátku být co nejjednodušší (a tudíž upravitelný)
• co nejvíce škálovatelný
• být paměťově, diskově a síťově efektivní
• podporovat "klon/větev a stáhni/synchronizuj" styl vývoje

Vývoj je sice na samém začátku, ale myslím, že mi to jde překvapivě dobře. Nyní mám něco, co dělá zajímavé věci, když se v tom správně šťouráte, takže jsem uznal, že je na čase vypustit to ven. Tady je, co zatím mám:

• O(1) souborové ukládání a čtení revizí s efektivní delta kompresí
• efektivní rozhraní pouze-k-připojení [append-only layout] pro rsync a http
• holá kostra pro commit, checkout, stat, history
• funkční "clone/branch" a "pull/sync"
• dostatečně funkční na to, aby hostil sám sebe (nicméně formát repozitoře je stále ve vývoji)
• vše zabírá méně než 600 řádků v Pythonu

Když říkám, že "pull/sync" funguje, mám na mysli, že můžu:

hg merge other-repo

a ono to stáhne všechny "changesets/deltas", které jsou v other-dir a které nemám, začlení je do grafu historie changesetu a totéž udělá pro všechny soubory změněné těmito rozdíly. Zavolá to uživatelem určený slučovací nástroj, jako je tkdiff, pro správné třícestné sloučení s nejbližším společným předkem v případě konfliktů.

Aktuálně "cloning/branching" je jednoduše ekvivalentem "cp -al" nebo "rsync" (mercurial ví, jak v případě potřeby rozdělit hard linky).

Pár benchmarků z mého laptopu:

• příprava na commit Linuxu 2.6.10: cca 1sekunda
• commit Linuxu 2.6.10: 27 sekund
• checkout Linuxu 2.6.10: 45 sekund
• plný strom statistik pro přidané/změněné/smazané soubory: méně než sekundu
• lokální klonování hardlinků: 1,5 sekundy
• prázdné sloučení mezi dvěma plnými stromy: méně než 0,1 sekundy
• triviální třícestné sloučení se změnami do Makefile: cca 1 sekunda

Zbývá dokončit:

• aspoň částěčně použitelné CLI nástroje
• podpora vzdálené (síťové) repozitoře
• generování diffu
• editace changelogu
• různé ruční zásahy do slučování
• zvládat přejmenování
• podporovat rollback
• řízení rozličných chybových stavů
• čištění, balíčkování, dokumentace a testování

Bill Davidsen reagoval s tím, že projekt vypadá zajímavě a že jej vyzkouší.

Vývoj SCSI přechází z BitKeeperu na git, 1 e-mail

21. dub

James Bottomley napsal, že projekt Linux-SCSI víceméně přinucen přejít na git, protože jádro 2.6.12-rc3 je založeno na gitu. Z toho důvodu již nebude udržován server linux-scsi.bkbits.net. Naštěstí díky administrátorům serveru www.parisc- linux.org nachystal podobnou funkčnost na adrese http://www.parisc-linux.org/cgi-bin/gitweb.pl, kde najdete dostupné SCSI stromy. Diffy naleznete na adrese http://www.parisc-linux.org/~jejb/scsi_diffs.

---

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

• Status Of Kernel Development Given Switch From BitKeeper
• Some Kernel Developers Using git
• Mercurial Version 0.2 Released
• Some Discussion Of Linus' Preferred git Usage

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

       

Komentáře

[egg]

s/by jsi/bys/

s/se jím podaří/se jim podaří/

s/dostatenčě/dostatečně/

[Vlastimil Ott]

První opraven, další nemůžu najít.

[Mortal]

skutečně tam jsou
možná pomůže v FF ctrl+f

[Michal Kubeček]

Zrovna ve Firefoxu je Ctrl-F zbytečné, jednodušší je hledat rovnou…

[smudla]

Dekuji, ze v prekladu nepouzivate slovo "funkcionalita." Dle meho soudu je totiz mimoradne odporne

[egg]

Jasně. Fíčura zní daleko líp. )