Mi az amit utálok a Linux kernelben?

Flame

Régi linux felhasználóként számtalanszor találkoztam olyan problémával, mely többé-kevésbé valamilyen módon a kernelhez kapcsolódott. Ezek egy része kódolási, probléma volt, míg a másik része inkább koncepcionális.
Ezen topikon belül az érdekelne, hogy "kinek, mi fáj a legjobban" a linux kernelben, és milyen megoldással orvosolná azt?

Uraim, kéretik az őrlángokat begyújtani!

  • 2450 megtekintés

( gyorsrizs | 2008. 07. 06., v – 09:23 )

subscribe :)
_______________________________________________________________
"Good news everyone! Those asinine morons who canceled us were themselves fired for incompotence!" Hubert J. Farnsworth

( Hiena v | 2008. 07. 06., v – 09:56 )

A számomra leginkább fájó pontok:
- A kernel méretének folyamatos növekedése és lassulása. Ugyanazon a gépen használtam 2.2-2.6-ig a teljes kernel családot, és ugyanazon opciókkal való fordítással, folyamatosan nő a kernel mérete, miközben számottevően lassul a bootideje a gépnek. Ez leginkább a 2.4 és 2.6-os között érezhető, bár panaszra nincs okom, mert a 2.6 számottevő javulást hozott stabilitás tekintetében a 2.4-hez képest. Ezen a részen egy alapos "ganyézás" lenne a megoldás, ami adott esetben egyes részek teljes újraírását jelentené.
- Monolitikusság. Ez Linus vesszőparipája. A monolitikus kernel stabilitásával nem vitatkozom, főleg nem szerver vonalon. Viszont egy-egy hibásan megírt modul miatt, számtalanszor állt be merevre a rendszer. Ismerve a linux hardvergyártók részéről történő támogatottságát, sokkalta jobb megoldásnak tartanám a kernel még jobban modulárissá tételét akár mikrokerneles szinten. Itt egy szupervizor modulra gondolnék elsődlegesen, ami figyelné a többi modul működését és kernel panic esetén, terminálná az adott modult.
- Hot-plug. Ez adódik az elöző pontból. Jelenleg a linux kernel és az aköré épülő hot-plug rendszerek jó közelítéssel a csapnivaló szintet ütik meg. Ez nem tisztán a kernel hibája, hanem a kiszolgáló kódoké (udev, hotplug, stb.) is. Viszont az már nagyobb probléma, hogy a kiszolgáló hibája esetén nem képes a kernel a hibát detektálni és megoldani.
- Sysfs. Itt kettősek az érzéseim. Egyrészt mert a korábbiakhoz képest jobb hozzáférést biztosít a vashoz, ugyanakkor nagyon él az adatok eldugása a userek elől. Amikor az alkönyvtár, linkelt alkönyvtárának, az alkönyvtárában kell túrkálni az nem épp felhasználóbarát megoldás. És itt problémásnak érzem azt is, hogy nem eszközazonosítók alapján, hanem hardveres hely alapján vannak az eszközök listázva. Emiatt egy változó környezetben (hello, hot-plug), redkívül macerás megfelelően konfigurálni az eszközt, ha első lépésben azt kell kivadászni, hogy hol is van.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

A mikrokernelt egyáltalán nem tarom jó ötletnek, sőt kifejezetten rossznak (hatékonysági vitáktól eltekintve, holott pont ez a lényeg). Egy fikarcnyival sem lesz jobb a támogatottság, ha monolit ha mikro. A mikrokernellel csak a zártkódú driverek lesznek könnyebben használhatóak szerintem, de ez csak a magánvéleményem, nem feltétlenül igaz, a zártkódú cuccok alá pedig fejleszteni marha kénylemetlen, hacsak nincs valami igen komoly leírás, de ha hibás a zártkódú cucc, akkor csak malmozhatsz míg ki nem javítják. A szupervizor modul, meg nem javítaná meg a hibás modult, csak kilőné. Egy hibás modult meg minek indítgatnék folyton, ha úgyis kihal. A szupervizor az legyen az ember. Én pont a monolitikusabbá tételt tartanám jobbnak. Szerintem a modularizáció túl nagy áldozat a sebességgel, és hatékonyságal, ja és a stabilitással szemben, azért hogy valamivel kényelmesebb legyen pár dolog.

Alapvetően a mikrokernel jellegű kernelt az alábbiak miatt tartanám jónak:
Folyamatos load-unload miatt nehezebb lenne egy memória injektálási támadást végrehajtani, mivel adott modul, mindig más helyen lenne a memóriában.
Erőforrás takarékosság, mivel a használaton kívüli modulokat kitölthetné a memóriából. A kicsi kernel miatt kevesebb erőforrással is beérné.
Rugalmasabb hardverkezelés. Jobb hot-plug, és egyébb kütyükezelés.
Egységes API az eszközkezelőknek, ezáltal könyebb a driver/modulírás. Hoszabb életű driverek és modulok, mert csak arra kell törekedni, hogy API szinten megmaradjon a kompatibilitás.
Gyorsabb bootidő. Mert csak kisméretű kernelt kell betölteni. Ez utóbbit akár bios szinten is lehetne integrálni.
Egyértelmű, követhető modul<->alkalmazás kapcsolat.
Jobb energiakezelés. Lehetőség az eszközök tiszta leállítására.
Modulok elszeparálása a memórián belül, ezáltal a biztonság javítása.
Elegendő csak a modulokat újraforgatni.
Lehetőség van on-the-fly modulokat cserélni. (Load_new->Redirect->Unload_old)
Zárt forrású eszközkezelők írásának a lehetősége. Ezáltal rávehetőek a gyártók, hogy linuxra is támogassák a vasaikat.
APIwrapper alkalmazása.

Hátrányai:
Nagyobb overhead az API miatt.
Hibalehetőség a load-unload miatt.
Memóriakorrupciós lehetőség, ha a kernel nem megfellően takarít.

Monolitikusság előnyei:
Egyszeri töltés. Nincs töltögetés üzemközben.
Kicsi overhead.
Stabilitás.
Lehetőség a moduloknak megosztott memóriaterület használatához.
Könnyű debugolás, mert mindig, minden ugyanott van.
Nagyobb lazaság a modul/driverírásban, saját belső megoldások használata. Nem kell a teljes API-t implementálni, elég csak a szükséges részeket összedobni.

Hátrányai:
Korábban soroltam.

Ha már szóbakerült a sebessége és hatékonysága a mikrokerneleknek, arra ott van peldanak az Exec. Ami a maga idejében elég jó teljesítményt nyújtott.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( Oscon | 2008. 07. 06., v – 10:42 )

Túlságosan gyorsan változik a kód. Külső "kiegészítők" nem mindig tudják korrekten lekövetni. 3 kiegészítőt használok (grsecurity, lirc, nvidia-binaris modul).

- UTF8 kódolás felesleges erőltetetése bizonyos esetekben. Ha alapértelmezett kódolásnak nem UTF8at adok meg, akkor ne akarja rámtukmálni. (vt.default_utf8=0)val ki lehet ütni, de hát ha az az egyik cél pl. hogy linux alatt normálisan menjen a "desktop" használat, akkor ne keljjen már mindenféle mágikus kernel paraméter. SZvsz elriasztja a "kezdőket".

- TSC vs CPUFREQ. CPUFREQ használata esetén teljesen felesleges a tsc clocksource-ot erőltetni alapjáraton. Úgysem fog menni. Fölösleges destabilizációs tényező.

2.6.24.7et a következő kernelparaméterekkel kell indítanom a normális használathoz:

notsc vt.default_utf8=0 clocksource=hpet hpet=force.

Azért ez vhol röhely 2008ban, nem ?

- feleslegesen erőlködnek a különféle modulok suspend_to_ram képességein sok esetben. Teleszórják a kernelt a különféle külső driverekre mindenféle patchekkel, mikor programbeállításban (pl. powersave) szolgáltatás leállít+modul unload, resume nel vissza.Ezzel probléma magoldva a driverek nagy többségénél.

- libata PATA vs. generic IDE. Most akkor döntsük el hogy vagy az egyik, vagy a másik. Ez is a kezdők megtévesztésére való. Bejelöli generic IDE+chipset, és libata PATA ua. csipszet, oszt csodálkozik hogy IRQ ütközés és nem megy, és milyen szar a linux tessék. Pedig csak egy egyszerű Kconfig szabályozás kellene, hogy vagy az egyik, vagy a másik.

- vesafb vs. setterm -powersave powerdown . érthetetlen miért nem működik alapból, mikor vbetool dpms off meg megy. Igazából alap vesafb vel alig vmit lehet csinálni. se friss. freq állítás,stb. Vagy eresszék be az uvesafb-t, de valamit így 2008ban már illene csinálni vele.

Le vagyok maradva, mint a borravaló. :)))

- proc fs , sysfs. Döntsük már el hogy mi legyen, a rohadt életbe. :))

----------------------

r=1 vagyok, de ugatok...

Ezeken a vizeken már 50.milliószor eleveztünk.Nem az én többségtől nyílvánvalóan eltérő felhasználói szokásaimat, igényeimet kell kritizálni a kernelconfigban levő "ellentmondás" miatt. Ha már egyszer lehetőség van más default NLS-t belőni, akkor ne kényszerítsék ki a "hátsóajtón" az UTF8at.

Lehet hogy tényleg röhely, de nekem 2008ban még mindig az iso8859-2 a kényelmesebb, és praktikusabb.

--------------------

r=1 vagyok, de ugatok...

( bitumen | 2008. 07. 06., v – 13:08 )

Azt utálom benne, hogy blob-okra van szűkség, h rendesen vigye a hárdveremet...

( wladek1 | 2008. 07. 06., v – 16:35 )

Ujraforgatni, ha valami nem megy / emellett még szarrápatchelni, hogy a disztrómban ismert bugok és feature -k normailsan előjöjjenek ismét. :)
Amit szeretek, hogy még ez is kevesebb ideig tart, mint egy nem igazán támogatott hardverhez windowsra találni drivert*, vagy XP alatt HP PSC**** sorozatot telepíteni cdről 16,9 kb/sec-es sebességgel, amit a telepítő büszkén konstatál a folyamatjelzőben.

*tökéletes, gyári és nem paypalosfizetős

kötöjelkötöjel
//:wladek's world

( deejayy | 2008. 07. 06., v – 19:00 )

Nem tudom, hogy ez most kernel függő-e, de én kifejezetten utálom a konzolkezelést. Ha én egyszer CTRL+ALT+SHIFT+F12-t akarok nyomni, akkor had tegyem már meg, és működjék rendesen is.

Windoz-hoz vagyok szokva, ahol az abc 26 betűjével meg három funkciógombbal 182 dologra vagyok képes.

Hogyan lehet ezt elérni linuxnál?

(a "linuxot arra tervezték, hogy kenyérpirítón is működjön" című dolog hidegen hagy, lévén, hogy mondjuk desktopon akarom használni)

--
deejayy DOT hu

( turul16 v | 2008. 07. 06., v – 23:16 )

Kernel szintu audio keverest hianyolom.