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

Štítky: e-mail, Git, hardware, KDE, kernel, komunikace, licence, Linux, Mercurial, NTFS, patch, programování, souborové systémy, USB, Version Control System, Windows

Jaderné noviny 334

22. 12. 2005 | Robert Krátký | Jaderné noviny | 5100×

Stav podpory Sharp SL-C3000. NTFS začíná s nesmělou podporou zápisu. Tutoriál ke git/Cogito. Diskuze o správě 2.6. Čerstvý pokus o odstranění DevFS.

Stav podpory Sharp SL-C3000, 10 e-mailů

13. říj - 22. říj

Pavel Machek se zeptal na stav podpory PDA Sharp SL-C3000 (Spitz): Dnes jsem získal spitz. Myslel jsem, že oz3.5.3 pro spitz bude založen na 2.6, ale takové štěstí zase nemám. Ze seznamů změn vyčetl, že určitá podpora pro Spitz se dostala do jádra 2.6.14-rc2, ale stránka o portu pro 2.6 mu připadala stará. Konkrétně se ptal: Existuje jednoduchý způsob, jak poznat spitz od tosa (bez rozebírání přístroje)? Přičemž Tosa je SL-6000.

Richard Purdie napsal: oz 3.5.4 by měl vyjít brzy a snad bude obsahovat i podporu pro spitz s 2.6. Také potvrdil, že stránka o portu je skutečně zastaralá. A dodal:

Nedávno jsem také získal spitz, což by mělo portu na 2.6 pomoci kupředu. Podívej se na:

http://www.rpsys.net/openzaurus/

Tento soubor by ti měl poradit, v jakém pořadí které patche aplikovat: http://www.rpsys.net/openzaurus/temp/linux-openzaurus_2.6.14-rc1.bb

S touto sadou patchů chybí USB klient (USB hostitel funguje) a podpora zvuku.

Kód v hlavním stromě postrádá správu napájení a v současné době nelze bez mých patchů zkompilovat - ale pracuji na tom.

NTFS začíná s nesmělou podporou zápisu, 75 e-mailů

16. říj - 24. říj

Jedním z patchů v jádře 2.6.14-rc4-mm1 byla i aktualizace NTFS. Anton Altaparmakov napsal:

Hledám pro NTFS testery. 2.6.14-rc4-mm1 obsahuje téměř kompletně přepsanou podporu zápisu souborů, takže by bylo fajn, kdyby to otestovali kromě mě i další (než to nabídnu k začlenění do 2.6.15...).

Díky přepsání jsou teď u nekomprimovaného a nešifrovaného souboru podporovány následující funkce:

write(2) pro zápis do souboru, včetně zápisu za konec stávajícího souboru, soubor bude patřičně zvětšen. Jsou podporovány jak residentní, tak neresidentní soubory. Podpora hodně fragmentovaných souborů je pořád omezená, ale pokud na nějaký narazíte, dostanete pouze chybu EOPNOTSUPP. Oddíl bude i nadále v pořádku. Lze zapisovat i do rozptýlených souborů a mezery budou vyplněny podle potřeby.
truncate(2) a ftruncate(2) pro změnu velikosti souboru, včetně použití parametru O_TRUNC u open(2). Podobně jako u write(2) to je trochu omezeno u velmi fragmentovaných souborů, ale i tentokrát bude vše na oddílu v pořádku, pokud na nepodporovaný případ narazíte.

Znamená to, že můžete spustit svůj oblíbený editor na existujícím souboru. Např.: "vim /ntfs/soubor.txt" funguje bez potíží a můžete uložit změny. Měly by fungovat i věci jako editace MS Office dokumentů v OpenOffice.org, ale to jsem ještě nezkoušel (pokud OpenOffice.org nepotřebuje vytvářet dočasné soubory ve stejném adresáři jako je dokument, mělo by to fungovat).

Stále není podporováno vytváření/mazání souborů/adresářů a mmap(2) zápisy do řídkých míst souborů. (Podpora mmap(2) nebyla od minulého vydání změněna, přepsána byla pouze podpora zápisu write(2).)

Pokud to vyzkoušíte, dejte mi vědět, jak to dopadlo! - Předem děkuji za testování!

Alberto Patino kód zkusil, ale souborový systém to poškodilo natolik, že nemohl do Windows 2000 nabootovat; prohlédnutím dvou souborů, které editoval, zjistil, že části obou souborů byly vloženy do druhého souboru. Anton odpověděl:

Windows by snad mělo jít opravit nabootováním z instalačního CD a spuštěním chkdsk na daný oddíl ze záchranné konzole. Také můžeš zkusit spustit ntfsfix z ntfsprogs a pak do Windows nabootovat. Mělo by to stačit na to, aby na oddílu provedly chkdsk ještě než spadnou.

Našel jsem chybu, která poškození OpenOffice.org dokumentu způsobovala tak, jak jsi to popisoval. Připojuji opravu.

Tutoriál ke git/Cogito, 7 e-mailů

17. říj - 24. říj

V konferenci o git řekl Horst von Brand: Žádali mě tu o tutoriál pro git+cogito, takže jsem napsal skript, který simuluje několik spolupracujících vývojářů. Programování je simulováno patchováním, ed(1) skripty (merge nevrátí pokaždé stejný diff) a prostým přidáváním nových souborů. Nastavil jsem GPG klíč s prázdným heslem (komentář je "Experimental"), aby byly tagy apod. podepsány pohodlným způsobem. Cílem je vytvoření zajímavých historií (k prohlížení) a ucelené předvedení příkazů. Kdyby tak existoval rozumný způsob, jak spustit část (bashového) skriptu, podívat se na výsledky a pak pokračovat... Přidal odkaz na git repozitář svého skriptu a podpůrných souborů. Petr Baudiš byl nadšený a zeptal se, jestli by to šlo vydat pod GPL a začlenit k oficiální dokumentaci Cogita. Horst řekl, že by byl poctěn, a dodal: Uvědomil jsem si, že licence nebyla upřesněna. Mám to v TODO ;-) . Také kvitoval, že Petr zařadil do repozitáře Cogita nejen poslední verzi tutoriálu, ale celou historii vývoje.

Diskuze o správě 2.6, 32 e-mailů

29. říj - 31. říj

V rámci probíhající diskuze poznamenal Linus Torvalds:

Jednou z nevýhod nového přístupu, který se řídí pravidlem "začlenit hodně věcí na počátku vývojového cyklu", je fakt, že prvních pár denních snapshotů je obrovských.

Takže -git1 a -git2 patche jsou/budou opravdu velké.

Například patch-2.6.14-git1 měl komprimovaný megabajt. Teď právě je diff oproti 2.6.14 po pouhých dvou dnech komprimovaných 1,6MB.

Je pravda, že něco z toho mají na svědomí věci jako začlenění MIPS, ale jde mi o to, že jsou takto denní snapshoty daleko méně užitečné pro lidi, kteří se snaží zjistit, kde něco přestalo fungovat.

Přišlo mi několik kladných komentářů ohledně toho, jak snadné je používat "git bisect", a používal jsem to i sám. Ale je to poprvé, co byli uživatelé patchů skutečně odsunuti na vedlejší kolej. Je to škoda a možná velké mínus.

Nevykládejte si to špatně - osobně považuji nová začleňovací pravidla za jasné vylepšení, ale má to tuhle nevýhodu.

Jeff Garzik odpověděl:

Když jsem dělával BK snapshoty, občas jsem vytvořil snapshot pro polovinu dne - pokud bylo během 24hodinového úseku příliš mnoho patchů.

Kdyby se z toho "velkého -git1" stal problém, můžeme:

ti dát čudlík pro ruční vytvoření snapshotu
požádat správce, aby své patche rozdělili na více dnů - jako to dělám už teď
přesvědčit tě pro zavedení denního limitu pro uploady na kernel.org, po "naplnění" hlavní větve začleňovat další věci do větví "den1", "den2" atd.

Nic z toho není extra nepohodlné, ale ani jedna možnost není zrovna lákavá.

Čerstvý pokus o odstranění DevFS, 1 e-mail

1. lis

Greg KH napsal:

Posílám patche pro smazání devfs, které jsem navrhoval už do 2.6.12 a 2.6.13. Vyhodí z jádra celý devfs, a ušetří tak spoustu místa. Od chvíle, kdy vyšlo 2.6.13, jsem nezaznamenal žádné stížnosti kvůli tomu, že devfs už nešlo povolit. Hodně subsystémů už odstranilo podporu devfs a nikdo si nestěžuje (protože to nikdo nepoužívá).

Stáhněte prosím z:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/

Všechny ty patche už jsem posílal dříve, ale chcete-li se podívat, najdete je zde:
http://www.kernel.org/pub/linux/kernel/people/gregkh/ gregkh-2.6/gregkh-05-devfs/

Pokud si někdo doopravdy zamiloval devfs v jádře, tak jsem napsal patch o asi 300 řádkách nazývaný ndevfs. Jestli ho chcete používat, najdete ho v archívech (je snadné jej spravovat mimo jádro, protože potřebuje jen tři háčky [hooks] do hlavního stromu.

Nepřišla žádná odpověď.

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