|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
Table Of Contents
| 1. | 24 Feb 2004 - 26 Feb 2004 | (2 posts) | Marc-Christian Petersen je novým správcem řady 2.2 |
| 2. | 3 Mar 2004 - 18 Mar 2004 | (17 posts) | Nový souborový systém PRAMFS |
| 3. | 12 Mar 2004 - 18 Mar 2004 | (17 posts) | Stav softwarového uspání |
| 4. | 17 Mar 2004 - 22 Mar 2004 | (40 posts) | Stav fsync() |
| 5. | 22 Mar 2004 - 24 Mar 2004 | (21 posts) | Stav OSS |
Mailing List Stats For This Week
We looked at 1917 posts in 9538K.
There were 478 different contributors. 245 posted more than once. 192 posted last week too.
The top posters of the week were:
1. Marc-Christian Petersen je novým správcem řady 2.2
24 Feb 2004 - 26 Feb 2004 (2 posts) Archive Link: "Linux 2.2.26 aka "2.2 is not dead" released"
People: Marc-Christian Petersen, Alan Cox
Marc-Christian Petersen převzal od Alana Coxe správcovství řady 2.2 a vydal verzi 2.2.26:
Jsem velmi rád, že mohu oznámit toto vydání, protože obsahuje několik oprav bezpečnostních chyb, včetně toho posledního problému s mremap().
Doporučuji všem uživatelům 2.2 jader, aby upgradovali.
Pošlete mi, prosím, opravy/patche/atd., na které jsem zapomněl, aby mohly být začleněny do 2.2.27-pre/rc.
2. Nový souborový systém PRAMFS
3 Mar 2004 - 18 Mar 2004 (17 posts) Archive Link: "new special filesystem for consideration in 2.6/2.7"
Topics: FS: ramfs, Patents, Small Systems
People: Steve Longerbeam, Dave Jones, Mike Fedyk
Steve Longerbeam napsal:
MontaVista Software vyvinula nový filesystém zaměřený na embedded systémy. Rádi bychom jej prosadili do jádra 2.6 nebo 2.7. Nazývá se Protected and Persistent RAM Special Filesystem (PRAMFS). Původně byl vyvinut pro tři velké firmy vyrábějící spotřebitelskou elektroniku, aby jej mohly používat v chytrých mobilech a jiných spotřebitelských zařízeních.
Úvod do PRAMFS a také technické specifikace naleznete na SourceForge stránkách projektu http://pramfs.sourceforge.net/. Je tam také patch pro 2.6.3.
PRAMFS může být na desktopu testován pomocí rezervování určité části fyzické paměti příkazem "mem=". Například stroj s 512M by mohl rezervovat vrchních 32M příkazem "mem=480M". PRAMFS by se pak připojoval takto:
mount -t pramfs -o physaddr=0x1e000000,init=0x2000000 none /mnt/pramfs
Připojil několik úvodních dokumentů, ale Dave Jones poukázal na to, že "největším problémem, který brání začlenění této práce, je nejspíše poznámka o patentech na část kódu." Steve odpověděl: "MV sice čeká na schválení patentu, ale ten se bude týkat pouze případného budoucího využití technologie v _ne GPL_ operačním systému. Použití v Linuxu nebo jakémkoliv jiném GPL softwaru je bez jakýchkoliv patentových licencí nebo poplatků." Mike Fedyk řekl, že by se to mělo přeložit do právnických termínů a ponechat jako součást samotného patche. Tim Bird připomněl, že přesně takové upozornění už je na začátku každého souboru patche.
3. Stav softwarového uspání
12 Mar 2004 - 18 Mar 2004 (17 posts) Archive Link: "Dealing with swsusp vs. pmdisk"
Topics: Big Memory Support, Software Suspend
People: Pavel Machek, Theodore Ts'o, Jan Rychter, Benjamin Herrenschmidt
Pavel Machek napsal:
Skutečně se mi nelíbí dvě implementace stejno kódu v jádře. Jsou dva způsoby, jak to řešit:
odstranit z jádra pmdisk
odstranit z jádra swsusp, přejmenovat pmdisk na swsusp, opravit všechny chyby, které byly opraveny v swsusp ale ne v pmdisk
Co byste volili? Mohu udělat obojí...
Theodore Ts'o odpověděl:
2.6 je údajně stabilní jadernou řadou, takže je-li swsusp v tuto chvíli stabilnější, navrhoval bych swsusp ponechat a odstranit z kernelu pmdisk. Chce-li někdo spravovat samostatný BK-strom obsahující pmdisk přejmenovaný na swsusp a opravit všechny chyby, fajn. Na druhou stranu tu je skupina lidí, kteří dělají něco hodně podobného se swsusp2, a vypadá to, že se jich na testování a práci podílí hodně.
Takže pokud bychom mohli nějak snížit počet *tří* nezávislých implementací na méně než tři, a zvýšit úsilí věnované testování a vývoji zbývajícího kódu, byl by to pokrok.
Mimochodem, Pavle, co ty si myslíš o tom swsusp2 patchi? Mně nejvíce vadí, že vzhledem k tomu, že je to spravované vně jádra, tak je to pořád o nějakých 0,75 revize pozadu oproti aktuálnímu 2.6 kernelu. Množství vlastností - kdyby se někdy podařilo zbavit je všech chyb - je však impozantní.
Pavel odpověděl: "Na swsusp2 mi nejvíce vadí, jak je velké. Navíc, když jsem se naposledy díval, byly tam dost nepěkné hooky rozeseté po celém jádře. A pak to má funkce, které se mi nelíbí (grafické obrazovky s ukazatelem průběhu, escape ruší akci) a proměnnésnázvyjakojetento. Na druhou stranu to podporuje highmem a SMP." Jan Rychter odpověděl:
Také má tu výhodu, že naprosto spolehlivě funguje na 2.4. Nepodařilo se mi to shodit už několik měsíců, a to provádím několik uspání/probuzení denně.
Navíc jsou doby uspání/probuzení velmi krátké díky bezvadné komprimaci. Dokonce se mohou měřit se suspend-to-ram.
Myslím, že by bylo lepší nemíchat osobní preference (třeba tu věc s escape) s technickou diskuzí. Z praktického hlediska je swsusp2 jedinou implementací, která funguje spolehlivě a dobře a má komunikativního správce, který je ochoten opravovat objevivší se problémy.
Benjamin Herrenschmidt napsal, že také podporuje začlenění swsusp2 do hlavního kernelu:
Možná s tím nějaké problémy jsou, ale když to ponecháme mimo strom, je víceméně zaručeno, že se na ně nikdo z nás nepodívá a neopraví je ;).
Dostane-li se to do hlavního stromu, rád dokončím tu podporu pro PMac, kterou jsem rychle hacknul pro pmdisk, a pomohu s vyřešením i dalších problémů. Ale nechce se mi to dělat pro nezačleněný projekt.
Pavel se Benjamina zeptal, jestli si myslí, že by to začlenění mělo proběhnout během 2.6 nebo až v rámci 2.7. Benjamin odpověděl: "2.6. Pokud to není moc invazivní, tak nevidím důvod, proč to nezačlenit teď (na kód jsem se ale nedíval). Nezasahuje-li to jinam, pak je to skoro jako přidání ovladače." Pavel kód prohlédl a zjistil, že je velmi invazivní. Měl pocit, že dostat to do 2.6 by bylo hodně těžké a ani 2.7 se mu nezdálo příliš reálné. Další lidi začali diskutovat o tom, co by bylo potřeba změnit, aby byl kód lépe stravitelný.
4. Stav fsync()
17 Mar 2004 - 22 Mar 2004 (40 posts) Archive Link: "True fsync() in Linux (on IDE)"
Topics: Disks: IDE
People: Peter Zaitsev, Jens Axboe
Peter Zaitsev se zeptal:
Existuje v Linuxu nějaký způsob, jak provést řádný fsync(), který zajistí, že budou data zapsána na disk?
V současné době na IDE zařízeních fsync() pouze spláchne data do keše disku, což pro ACID záruky, které musí poskytnout databázový server, nestačí.
Řešením je prostě zakázat keš disku, ale to příliš snižuje výkonnost.
Stačil by mi globální přepínač pro jádro, který by povolil spláchnutí keše disku při fsync :).
Jens Axboe řekl: "Chris a já máme funkční fsync(). Pročistím to a pošlu patch pro vanilla 2.6.5-rc." Což bylo přesně to, co Peter a další chtěli slyšet.
5. Stav OSS
22 Mar 2004 - 24 Mar 2004 (21 posts) Archive Link: "OSS: cleanup or throw away"
Topics: Sound: ALSA, Sound: OSS
People: Jos Hulzink, Adrian Bunk, Diego Calleja Garcia
Jos Hulzink napsal: "Opravoval jsem několik problémů s "deprecated" v OSS ovladačích a říkal jsem si, jestli to má vůbec smysl, když je celé OSS označeno jako "deprecated" (zastaralé). Přežije OSS až do 2.7 nebo bude brzy odstraněno? (Jinými slovy, mám se o OSS ovladače starat nebo se neobtěžovat?)" Adrian Bunk odpověděl:
OSS zůstane ve 2.6 (2.6 je stabilní řada), ale s největší pravděpodobností bude odstraněno z 2.7.
Já bych s opravami starých hlášek v OSS kódu neztrácel čas. Byl by to čas zbytečně promarněný na kódu, který asi půjde ve 2.7 pryč.
Diego Calleja Garcia řekl: "Jako uživatel bych rád měl OSS ovladače, které nemají ALSA ekvivalent, pro svůj starý hardware. Existuje dost karet, pro které jsou jak ALSA, tak OSS ovladače a ALSA funguje v 99 % případů o moc lépe. Ty mohou být klidně odstraněny (i během 2.6), ale chtěl bych ponechat ty, ke kterým ALSA ekvivalent není (zvláště když teď máme strom -tiny ;), i když chápu, že nemají-li správce, budou odstraněny..."
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0. |