Kernel Traffic #234 For 6 Oct 2003

/*
 * Pokud pro zásadní oblasti svého podnikání odmítáte závislost
 * na uzavřeném software, mohou se vám hodit tyto odkazy:
 *
 * rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.5/
 * rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.4/
 * http://www.cobite.com/cvsps/
 *
 * svn://svn.kernel.org/linux-2.6/trunk
 * svn://svn.kernel.org/linux-2.4/trunk
 */

Poskytujeme službu, která umožňuje všechny tyhle věci, a bez naší dobré vůlu je tato služba ohrožena. Ty se veřejně navážíš do poskytovatelů této služby.

Chceš-li to dělat, fajn, ale to nás vede k otázce:

• Nezněla dohoda tak, že my uděláme bránu a vy přestanete fňukat?
• Proč bychom tu službu měli poskytovat, když pořád fňukáte?
• Proč vás nezamkout za firewall, když fňukáte?
• A nebo, jestli firewall nebude stačit, pozdržet bránu o den nebo dva?

Ostatní by s tvým pohledem nemuseli souhlasit. Většina lidí si ten podpis přečetla a viděli v něm negativní komentář o BitKeeperu.

Lidé mi říkají, že mají za to, že pokud BitMover nemá žádný prospěch z volného používání BK, volný BK se zruší. Lidé nechtějí záviset na mé dobré vůli. Chtějí, aby měl BitMover prospěch, takže na mojí dobré vůli nebude záviset. Dávat BK je jen chytrý obchod.

Pokud je tohle opravdu to, co si tady lidé myslí, pak to znamená, že pro BitMover musí být nějaký prospěch. Takový prospěch je i to, že můžeme říkat, že tým kernelu ho používá a získat tak nějaké marketingové výhody. Prospěch se však snižuje negativními poznámkami.

Vzhledem k tomu, kolik práce a nepříjemností je s poskytováním BK, dává smysl, že se lidi necítí dobře když jsou na tom závislí. Nechápu, že jsem si to neuvědomil dříve. Je to nestabilní situace.

Vím, že existují lidé, kteří nebudou nikdy šťastni, dokud nebude vše pod GPL. Nemůžu těm lidem pomoci jinak, než jim poskytnout bránu. Na oplátku musí tito lidé přestat fňukat, brána musí stačit.

K těm ostatním se obracím pro návrhy, jak zařídit, aby byla situace stabilnější. Chilku mi to trvalo, ale už chápu, proč jste nervózní. Já bych byl na vašem místě taky. Já jsem nervózní z nějakého opravdového marketingového využití faktu, že kernel používá BK, protože by to jen vedlo k dalšímu napadání. Začínám si myslet, že kdybychom to dělali, možná by to vlastně znamenalo méně napadání, protože pak bychom my potřebovali, abyste i nadále měli BK zdarma. Máte-li na to názor, rád bych ho slyšel.

Požadujeme zařazení následujícího patche pro dodatečné hlášení o událostech kernelu [kernel event notification] do nadcházejího 2.6.x kernelu.

Současné profilovací háčky [profiling hooks] poskytují hlášení na konci života úlohy (tj. task exit, mmap exit a exec unmap). Rádi bychom měli další hlášení na počátku úlohu (tj. fork, execve, kernel image loads, a user image loads).

Máme za to, že profilovací nástroje jako Oprofile, Perfmon a VTune by z dodatečných háčků měly prospěch, protože by se zlepšila přesnost a kompletnost výkonových údajů, obzvláště při práci v prostředí, které může dynamicky vytvářet a rušit spustitelný kód (jako Java). Kromě toho by tyto háčky mohly být využívány k měření různých druhů výkonových údajů (např. "forks za vteřinu"), které teď nejsou jiným způsobem dostupné.

Náš patch dodržuje konvence používané stávajícími profilovacími háčky a je relativně malý.

Ocenili bychom váš názor/komentáře k našemu návrhu.

Náš testovací jaderný modul využívající tyto háčky je GPL a mohl by být zařazen do stromu kernel.org.

Současná verze ovladače (také GPL, ale s háčky sys_call_table pro 2.4.x kernely) je na

http://www.intel.com/software/products/opensource/vdk/

Počátkem příštího týdne plánujeme dát na tu samou stránku nový ovladač pro kernel 2.6.0-test5 (s aplikovaným patchem pro hlášení událostí) a jak IA-32, tak IA-64.

Jak všichni ví, není dobrý nápad nechávat kernel hádat, jestli na daném zařízení je tabulka oddílů a pokud ano, jakého typu. Přesto to však dělá téměř každý.

Až doposud se to řídilo pravidlem: diskety tabulku oddílů nemají, disky ji mají a u ZIP jednotek to nikdo neví. S USB máme další druhy blokových zařízení, které mohou, ale nemusejí mít tabulku oddílů (a pokud žádnou nemají, většinou tam bývá FAT filesystém s bootsektorem). V takových případech kernel očekává tabulku oddílů a pokud tam žádná není, je z toho zmatek. Je potřeba nějaká heuristika.

Je možné to zjišťovat různě (pro tabulku oddílů DOSového typu: boot ukazatel musí být 0 nebo 0x80, oddíly nejsou větší než disk, nerozšířené oddíly jsou navzájem nesouvislé; pro boot sektor: začíná skokem, počet bytů na sektor je 512 nebo alespoň mocnina dvou, počet sektorů na cluster je 1 nebo alespoň mocnina dvou, počer rezervovaných sektorů je 1 nebo 32, počet kopií FAT je 2, ...).

Zkoušel jsem minimální test a je dostatečný pro boot sektory a DOSové tabulky oddílů, které tu mám.

Takže: jsou mezi vámi lidé s tabulkami oddílů DOSového typu nebo FAT filesystémovými bootsektory, kterým připojený test dává chybnou odpověď? Rád bych získal kopii takových sektorů.

Předpoklíádám, že navrhnu nějaký test správnosti parsování tabulky oddílů DOSového typu a doufám, že pak ve většině případů rozpoznám přítomnost celodiskového FAT filesystému.

To říkáš teď a říkal jsi to už dlouho dobu. Ale tvrdit, že to "všichni ví", to prostě není pravda.

Především si myslím, že kernel, který nerozděluje na oddíly je od základu špatný. Jsem si jistý, že i jiní by souhlasili.

Máš-li neobvyklé případy (a přiznejme si, těch moc není - tradičně jsme měli _velmi_ málo problémů s dělením na oddíly), měl by být schopen je zvládnout z uživatelského prostoru a uživatelský prostor by měl být schopen říct kernelu o speciálních oddílech.

A víš co, překvapení, překvapení, přesně to lze provést.

A taky, překvapení, překvapení, skoro nikdo to nedělá. Protože výchozí nastavení je tak rozumné.

Opakuj po mně: udělej výchozí nastavení tak rozumné, aby o něm většina lidí ani nemusela přemýšlet.

Zkrátka si myslím, tvá první věta (na které visí zbytek tvého argumentování) je od _základu_ chybná.