Milion nových řádků v Linuxu (diskuse)

[pavlix]

Tak si říkám, kdy přijde čas na nějaké podstatně menší a podstatně čistší alternativní jádro...

[Salamek]

Nikdo te nenuti si tohle vsechno zakompilovat do jadra

[AlYoSHA]

Aj keby niekto nieco take zacal vyvijat, akonhle by sa to malo pouzivat v takych nasadeniach ako terajsi linux - zacne sa to komplikovat. Bud je kernel jednoduchy - ale uzko zamerany na nejaku HW platformu a riesenie uzkeho okruhu problemov, alebo je "takmer univerzalny" ale komplikovany.

[Jendа]

Neboj, již brzy bude hotový Hurd.

[xkucf03]

Hurd? (ale kdybys do něj portoval ovladače pro všechen ten hardware, tak by taky nabobtnal)

[|🇵🇸]

Prosím, můžeš mi vysvětlit, jak nabobtná mikrojádro při portu ovladačů?

[AlYoSHA]

Hmm. Z toho mala co o HURD jadre viem je, ze ovladace su samostatne procesy beziace v userlande. Takze mikrojadro nenarastie :). V monolitickom jadre ako je linux su ovladace sucasto jadra, ale ovladace nemusia nutne byt priamo v jadre zakompilovane resp. nemusia byt vobec kompilovane ak ich netreba. Len tak jedna otazka do plena: Vie niekto o njakom mikrojadre v produkcnom nasadeni? Nieco porovnatelne s linuxom? Mam pocit ze mikrokernely tak nejak neopustili akademicku podu. Aj ked ako napad sa mi myslienka mikrojadra paci.

[jb]

QNX

[mhepp]

Windows byly nějakou dobu postavené na mikrojádře a fungovaly dobře (Myslím, že to byly NT 4.0, možná i novější...).

[Vykook]

NT a stejně tak XNU z OS X jsou jádra hybridní.

[Luboš Doležel (Doli)]

Současné XNU není o nic víc hybridní než Linux.

[Vykook]

{{Citation needed}}

[xkucf03]

Asi podobně jako monolitické jádro u ovladačů, které do něj nezakompiluješ.

[Ivan]

Staci mit divoky HW. Napr. CDMA modem propojeny pres seriak (umulovany pres USB). Za normalnich okolnosti modem vyvola preruseni, to vlozi do fronty pozadavek, ovladac to vyzvedne a nejak na nej zareaguje. Pak se ale ukaze, ze tenhle pristup je prilis pomaly a ze je u nekterych zarizeni potreba aby obsluha preruseni "okamzite" neco zapsala nazpatek. A tak ma obsluha preruseni seznam pointeru na callback funkce, ktere je potreba "nekdy" zavolat. A najednou genericka cast kernelu resi nedokonalost HW.

Jeste zajimavejsi je to se sitovyma kartama. Cim chytrejsi karta, tim vic se toho off-loaduje(L2, L3) a genericka cast musi byt dostatecne obecna na to aby vsechny tyhle veci dokazala postihnout.

Anebo obycejna flash-ka. Na jednu strau se to tvari jako genericky SCSI disk, ale na druhou stranu jak urcim jeji velikost? Je to skutecne garantovane, ze muzu zjistit velikost USB disku, tak jako to je u opravdoveho SCSI?

Problem je v tom, ze se to neda uplne presne oddelit. A idealni design(mikrojadro) funguje pouze s idelanim HW.

[little.owl]

Ano, velky problem jsou efektivni genericka rozhrani.

s idelanim HW.

Spise s unifikovanym HW modelem, coz nemame a nejsem si jist, ze bychom krom urcitych kategorii mit vubec meli - mela by to pokryt flexibilita SW.

[Bedňa]

Je to ovládač a nie Kernel kód, ako väčšina pridaného kódu v hocijakom novom jadre.

[andree]

trochu nechapem ako sa ten driver dostal v takomto stave do kernelu :-/

amdgpu/atom.c vs. radeon/atom.c

...mam obavy ze 2/3 z toho kodu a headerov budu kopia povodneho radeon driveru + prefix amdgpu_ :-/

[sonicpp]

No a někdo tvrdí že to není kopie?

[2X4B-523P]

nejak se ty backdoory musi maskovat, kdo by kontroloval milion radku

[R]

Najvacsie sracky sa do kernelu dostavaju spravidla priamo od nejakeho maintainera (typicky z velkej firmy), mimo mailing listov...

[martin]

napriklad?

[nobody]

no kdyz vypustis ten prefix amdgpu_, zustane tohle, tedy spis jde o 49/50 ;)

diff --git a/radeon-atom.c b/amdgpu-atom_NOPREFIX.c
index ec1593a..c4a4e80 100644
--- a/radeon-atom.c
+++ b/amdgpu-atom_NOPREFIX.c
@@ -35 +35 @@
-#include "radeon.h"
+#include "amdgpu.h"
@@ -105 +104,0 @@ static uint32_t atom_iio_execute(struct atom_context *ctx, int base,
-	struct radeon_device *rdev = ctx->card->dev->dev_private;
@@ -118,2 +116,0 @@ static uint32_t atom_iio_execute(struct atom_context *ctx, int base,
-			if (rdev->family == CHIP_RV515)
-				(void)ctx->card->ioreg_read(ctx->card, CU16(base + 1));
@@ -1220 +1217 @@ free:
-int atom_execute_table_scratch_unlocked(struct atom_context *ctx, int index, uint32_t * params)
+int atom_execute_table(struct atom_context *ctx, int index, uint32_t * params)
@@ -1241,9 +1237,0 @@ int atom_execute_table_scratch_unlocked(struct atom_context *ctx, int index, uin
-int atom_execute_table(struct atom_context *ctx, int index, uint32_t * params)
-{
-	int r;
-	mutex_lock(&ctx->scratch_mutex);
-	r = atom_execute_table_scratch_unlocked(ctx, index, params);
-	mutex_unlock(&ctx->scratch_mutex);
-	return r;
-}
-
@@ -1329 +1316,0 @@ int atom_asic_init(struct atom_context *ctx)
-	struct radeon_device *rdev = ctx->card->dev->dev_private;
@@ -1349,4 +1335,0 @@ int atom_asic_init(struct atom_context *ctx)
-	if (rdev->family < CHIP_R600) {
-		if (CU16(ctx->cmd_table + 4 + 2 * ATOM_CMD_SPDFANCNTL))
-			atom_execute_table(ctx, ATOM_CMD_SPDFANCNTL, ps);
-	}

[Michal Kubeček]

Tak se podívejte třeba na e1000, e1000e a igb - tam v těch druhých dvou u spousty funkcí zůstal i prefix "e1000_". Nevidím v tom problém: pokud ten kód má dělat přibližně totéž se stejným nebo velmi podobným hardware, proč by měl za každou cenu vypadat jinak? Koneckonců o amdgpu IIRC nikdo ani netvrdil, že to má být úplně nový driver, který nemá nic společného s tím původním.

[pavlix]

Chápu správně, že obhajuješ duplikaci kódu?

[Jindřich Makovička]

Jsou případy, kdy duplikace dává smysl, viz třeba přechod z ext3 na ext4. Teoreticky by se z kernelu dal ext3 vyhodit, protože ext4 s povypínanými funkcemi zvládne totéž. V praxi ale pro někoho opuštění léty prověřeného ext3 nepřicházelo v úvahu.

Nejsem si pravda jistý, jestli je ovladač pro radeon natolik kritický a superstabilní, aby oddůvodňoval podobný přístup :)

[Michal Kubeček]

Určitě ne obecně. Ale většina pravidel se nedá brát úplně stoprocentně. Drivery zařízení jsou často plné větvení typu "pro tuhle revizi je potřeba tenhle trik" nebo "pro tuhle revizi musíme použít trochu jinou hodnotu" a je obtížné určit hranici, kdy ještě důsledně oddělovat společné části a kdy je jednodušší a přehlednější mít tam dvakrát (skoro) stejný kód.

[little.owl]

+1

Problem s drivery je, ze vyvojar to po vyraznejsich zmenach neni schopen casto otestovat na dostatecnem poctu zarizeni, protoze je proste nema, a casto jen doufa, ze nic nerozbil. Takze kopie muze byt bezpecnejsi cesta jak zacit, nebot stary, funkcni a overeny driver tam stale je.

[andree]

Problem je, ze ten "stary overeny driver" je miestami stale dost fragilny... ked to teraz takto "usekli", tipujem ze stary driver uz nikto moc udrzovat nebude, a vsetky zmeny sa budu musiet zlozito backportovat.

Je to samozrejme rozhodnutie vyvojara toho driveru, a chapem ze to ma iste vyhody - ale aj tak by som dufal ze ked uz niekto do kernelu narve megovy patch, tak budu na to kladene trochu vyssie naroky na udrzovatelnost, aj ked je to "iba" driver...

[Michal Kubeček]

Původní driver (radeon) se bude udržovat dál, ale nebude se do něj přidávat podpora nových verzí GPU. Naopak, nový driver (amdgpu) podporuje v současnosti jen několik poslední verzí GPU a postupně se do něj budou přidávat další, ale jen nové. Takže překryv (množina GPU podporovaných oběma) je poměrně malý už teď a jeho význam se bude dál zmenšovat.

[andree]

Ano, ale ten driver+hardware nie je nejaky monolit - kopa casti je pomerne starych/generickych (uz len podpora toho atom-biosu). Takze napr. nedavno tam pribudla podopora novej spravy napajania, ktora evidentne funguje podobne napriec niekolkymi generaciami chipov. Pochybujem ze by teraz zmenili vsetko od zakladov - skor si fakt povedali, ze sa im nechce pridavat dalsie if-else bloky, prip. ako sa pisalo hore, testovat kod na starych hw.

Pochopitelne to je, ale az tam za 1-2 roky pribudne patch "improve power managerment performance by 50%", ci "add support for supercool feature", je dost mozne ze bude velmi netrivialne to backportovat do orig. driveru, aj keby to ten hw vedel. A miesta na zlepsenie tam vazne su (par clovekodni som ho musel debugovat...).

[little.owl]

Uzivatele jsou vice toleratnejsi k bugum v nove verzi, nez k regresim ve starsich verzi a tim je to dane.

[R]

Problem je, ze to casto netestuju na starsich zariadeniach vobec. Spominam si na bug v driveri na Intel grafiky, ktory sposoboval null-pointer dereference na starsich chipsetoch (len s jednym vystupom). Niekto vtedy prerabal velky kus kodu a neotestoval to...

Urobit kopiu je bezpecnejsia cesta pre vyvojara, ale vysledkom je zly stav: duplicitny kod, ktory postupne diverguje a kazdy ma ine bugy.

Takto kedysi skopirovali v kerneli architekturu x86_64 z i386 a dodnes ten bordel davaju dokopy...

[kralyk z abclinuxu]

+1, ten kód by se musel projít nějakým refactoringem, aby se dal použít pro dva trochu odlišné účely. Zkopírovat ho může šetřit čas. Na druhou stranu se ale pak někdo musí postarat, aby bugfixy v jedné 'kopii' byly uplatněny i v druhé.

[trekker.dk]

Na druhou stranu se ale pak někdo musí postarat...

Problém je, že se je kůže líná a vykašle se na to.

[little.owl]

A nebo se ta starsi necha vyhnit, pokud se nenajde nekdo, kdo to bude chtit udrzovat.