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

Štítky: CLI, e-mail, Git, Internet, KDE, kernel, komunikace, Linux, Mercurial, patch, programování, rsync, řadiče, SATA, SCSI, Version Control System

Jaderné noviny 308

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

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:

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