Jsem zvedavy, zda to bude mit lepsi kvalitu nez ty originalni ovladace / moduly.
Ja mam VirtualBox celkem rad, na desktopovou virtualizaci je to prijemny, user friendly nastroj. Ale jeho jaderne moduly mi prisly ponekud odflaknute. Tak zde, vzhledem k tomu, ze to je prace primarne RH, by to mohlo byt lepsi (ale na zdrojaky jsem se zatim nedival a v tuto hodinu se mi ani moc nechce :)) ).
Ale co by mi udelalo uplne nejvetsi radost by bylo, pokud by to nezustalo jen u guest driveru, ale zlepsili se i host drivery a to idealne tak ,ze by mohli koexistovat s KVM (za me osobne neni nutne, aby musela bezet KVM virtualka zaroven s VBoxem, ale aspon moznost mit nactene oba moduly - i kdyz je pravda, ze to je trochu issue x86_64 platformy - na soubeh hypervisoru moc nemysli).
vboxvideo
modul to, že se ho ujal Hans de Goede znamenalo zjednodušení z 52 861 řádek kódu na 7 275 (>14% původní komplexity) a to si zatím kladl za cíl jenom dostat to do "staging". To vypovídá hned o 2 věcech:
Ve firemním prostředí ne, ale na domácím serveru.
Aktuálně nad CentOS 7 běží 3 virtuální stroje s CentOS 6 z nichž jeden dělá firewall a router, další poštovní, DNS, WWW atd... server a ten poslední NAS na lokální síti.
Samozřejmě, je to maličké, takže těžko soudit, jak by se VBox choval při náročnějším nasazení, ale za mě - pokud potřebujete provozovat pár virtuálních strojů na malém serveru,funguje to velmi dobře a administrace je pohodlná.
Vlastně jsem nikdy nenarazil na problém,který by stál za řeč. Pro lepší výkon virtuálních strojů na síti doporučuju používat paravirtualizovaná síťová rozhraní.
Máte poněkud zkreslené představy. Dnešní procesory jsou vybaveny již dávno hardwarovou podporou virtualizace s čímž hypervisory počítají(včetně Virtualboxu). Paravirtualizace opravdu není nezbytná, pokud tedy neberu v úvahu např. výše zmíněný ovladač síťového adaptéru - v tom případě je lepší speciální ovladač, svázaný s virtualizační platformou než simulovat konkrétní síťovou kartu.
Domaci oddeleni ceho?? Wake up, je rok 2018. O tvoje oddeleni se snad stara krabicka od providera, poradny operacni system a zbytek jako majly, fajly mas v mracich ne ?
"Nenarocne aplikace" je zavadejici termin, proc mit na produkci neco 3x pomalejsiho s vetsi rezii? To je plytvani penezi i energii. Nevim jak zijes ty ale kdyz cisnik mi da uctenku na 1000 korun tak mu nedam 3000 jen tak protoze muzu.
To s těmi mraky je doufám ironie.
Pokud ne, nezbývá než se podivit nad tím, že se na root.cz stahuje klientela zive.cz a podobných.
Opravdu vše běží na serveru doma, na vlastní doméně. Když to umím, proč bych měl být závislý na nějakých profízlovaných službách "zdarma", že ano... To ponechávám těm méně obdařeným.
Koneckonců mě provozování čistě privátní IT infrastruktury baví.
Zaplať Bůh za OpenSource, bez něj by to bylo daleko méně radostné.
hm, jde primárně o logické oddělení z důvodu bezpečnosti a správy. Ztráta výkonu při pár instrukcích za minutu je sice relativně pořád 20 %, ale prakticky nemá dopad, pokud je potřeba zvyšovat efektivitu, půjde se samozřejmě asi jinou cestou.
Jseš naivní, proč bych měl spoléhat na krabičku od providera? Proč bych se měl vázat na jednoho providera? Na jednu domácnost? Jsem člověk na cestách, člověk, který nevěří providerům, člověk který nechce, aby někdo zasahoval do provozu protože si ho umí řešit a kontrolovat sám.
Stejně jako muf, provozuji si veškerou infrastrukturu sám, na svém železe buď doma nebo v pronajaté racku v DC. Bavíme mě to, učím se tím a chci to mít pod kontrolou.
Ano, my to pouzivame a sme velmi spokojni. Nastroj je to dobry s celkom dobrym API, takze sa to da lahko zakomponovat do existujuceho ekosystemu. Bezia nam na tom produkcne virtualne masiny ako aj rozne testy a simulacie. Co sa tyka stability, nikdy sme s tym nemali problem (pocnuc verziou 5.0, teraz sme uz na 5.2). Vo virtualke nam vacsinou bezia linuxy, ale mame aj niekolko windowsov. Sme naozaj spokojni.
No, nejsem žádný kernel hacker :-), ale nebylo by lepší udělat to jako modul do jádra, který bude součástí nějakého pěkného balíčku, který si těch pár lidí, kteří potřebují provozovat linux ve virtuálu, doinstalují, než aby se to tahalo úplně všude jako zbytečná zátěž a potenciální zdroj děr? Onehdy jsem zkoušel nainstalovat Raspbian na 2GB sd kartu, chtěl jsem jen úplně čistou příkazovou řádku, webserver (Apache, php, MySQL), ssh server, mc, vim a konec. Měl jsem smůlu. Tak tak se to tam vešlo, ale zabralo to v podstatě celou tu kartu...
Dobre rano, jak bylo v pralese? :D https://www.linux-kvm.org/page/Main_Page
To je nativní vlastnost Linuxu, že něco nefunguje. Myslím že je to přímo v podmínkách, kdo chce vytvořit vlastní distribuci, musí si vybrat několik důležitých funkcí a postarat se nejen aby nefungovaly, ale aby nefungovaly takovým způsobem, aby s nimi uživatel ztratil mnoho času a nervů. Součástí je zveřejnění návodů na řešení na fórech, které nefungují taky.
chapu ze se obycejnej tro(t)l, ale i tak otazka k zamysleni "kdyz instalujes Windows10 na ne(vubec/uplne/plne)podporovanej ARM HW, tak ti chodi vzdy vse? treba konkretne RaspberryPi, co instlacace Windows 10? (ne nemyslim vylestene Windows 10 IoT Core)... co kdyz to instalujes na Microsoft Lumia tedy HW primo od stejneho vyrobce jako OS? taky vse chodi? vcetne touchscreen, wifi, bt, gsm...? ;-)
@hawran diskuse: A je to tento případ? [build as module]
bylo by nelogicke aby to neslo, natolik nelogicke ze je logicke aby to nikdo svepravnej do mainline nepridal ;-)
zde konkretne mas jasne receno ze jako modul to jde a je doporucovano:
VBOXGUEST
[...]
help
[...]
Although it is possible to build this module in, it is advised
to build this driver as a module, so that it can be updated
independently of the kernel. Select M to build this driver as a
module.
viz (docvakano k tomuto ze zpravicky):
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next&id=0ba002bc4393dcfae031fc707b11c094b46a5048
[Filip Jirsák]
Ne vzdy je to mozne.
Sveho casu jsem byl nadseny myslenkou sestavit si naprosto monoliticke vanila jadro site co nejvice na miru pouzivaneho HW.
Ukazalo se, ze je s tim vic piplave prace a nervu, nez kolik to pri dnesnim stavu hw prinese uzitku. To diky zavislostem mezi jednotlivymi moduly. Nektere ovladace mohou za urcitych okolnosti zaviset na kodu v jinych modulech. Vyvojari nepouzivaji kristalove koule, proto nemohou dopredu urcit zda se tyto zavislosti projevy ci ne. A tak to zdratovaly napevno - aspon tak jsem to pochopil z vysvetleni jadernych vyvojaru.
Tudiz stejne musite natahat nejky ten (je ho docela dost) balast navic a nebo si s tim vyhrat rucne. Coz uz je vsak dost hardcore i na me (alespon ted, posledni roky - asi jsem uz moc zlenivel).
Tak jsem to nakonec vzdal...
Myslím, že možnost, že by kód v současném jádru závisel na kódu v modulech, které do teď nebyly součástí jádra, můžeme rovnou vyloučit.To, že nějaký kód závisí na jiném kódu, je normální věc, to není žádný balast navíc – bez té závislosti by ten kód nefungoval.
Většina kódu, která je ve zdrojácích jádra, nepoužívá většina lidí. Kdybyste tohle bral jako kritérium, musíte mít jádro pro jednu konkrétní hardwarovou sestavu. Že je ten kód ve zdrojácích ale ničemu nevadí, protože ho nemusíte do jádra zakompilovat, a i když použijete univerzální jádro, kde je to zakompilované jako modul, prakticky se vád to nedotkne do té doby, než ten modul případně do jádra nahrajete.
Myslím, že možnost, že by kód v současném jádru závisel na kódu v modulech, které do teď nebyly součástí jádra, můžeme rovnou vyloučit.To, že nějaký kód závisí na jiném kódu, je normální věc, to není žádný balast navíc – bez té závislosti by ten kód nefungoval.
Toto není tak docela 100% pravda. Dovoluji si srovnat linux před 10.-20 lety a součansot. Dnes je jádro plné modulů, jejichž přínos opravdu "není pro každého", ale závislosti vytvářejí. Také vytvářejí potřebu zachovávat vnitřní rozhraní. Proto dílem v linuxu je opravdu část kódu balastního (tedy: i když dané moduly nepotřebujete, tak v tom, co potřebujete, jsou části, které tam jsou "co kdybyste potřreboval"), a za druhé, mnohdy struktury jsou vedeny paralelně - starší a novější verze.
Tak jste psal, že si každý může vybrat, co v jádru chce, a co ne. To samozřejmě není možnost "pro každého". Tuto činnost abstrahují maintaineři distribucí, kteří vybírají, jaké funkce a jaký hardware bude ta která distribuce podporovat. Jejich prací je pak správným výběrem, byť i jen modulů, udržet jejich jádro co nejčistší a nejrychlejší. Většinou proto aplikují i vlastní patche, aby mohli odstavit ty části, které ani v modulech využívat nebudou.
Také si myslím, že podpora modulů pro VirtualBox je zrovna to, co by linux měl mít. Na druhou stranu ale souhlasím i s tím, že jádro linuxu už trochu heká pod zátěží funkcí a podpory kde čeho a je na místě, čím vůbec jádro zatěžovat.
Nechci vyvolat flame, ale linuxu velmi chybí spolehlivé a kompatibilní rozhraní pro přidávání binárních modulů třetích stran. Mnoho hardwaru nepotřebuje jít "na dřeň jádra", a bylo by i pro uživatele asi přívětivější, kdyby mohl mít pro svůj okrajový hardware binární ovladač, který bude fungovat roky beze změn, i po změnách jádra. Tak to známe i z jiných systémů. Ale to se samozřejmě nemůže týkat podpory VirtualBoxu, ta patrně naopak půjde do hloubky.
Všechno, co jsem napsal, mě po letech postupně odvádí od Linuxu k FreeBSD, protože tam je podpora běžného hardwaru, který používám (nebo který lehce používat mohu) stejně dobrá, ale jádro je mnohem čistší, jednodušší a vyvýjené konzervativně.
Toto není tak docela 100% pravda.
Je to 100% pravda. Vanilkové jádro můžete přeložit ve všech možných přípustných kombinacích, a nikdy nebudete muset přidávat nějaký patch, který ve vanilkovém jádru není.
Dnes je jádro plné modulů, jejichž přínos opravdu "není pro každého", ale závislosti vytvářejí.
Jenže to jsou závislosti napříč současným jádrem, nejsou to závislosti na kódu, který není součástí jádra. A když na tom modulu jiný modul závisí, tak ho asi k něčemu potřebuje – to, že vy nevíte, k čemu se používá, neznamená, že je zbytečný.
To samozřejmě není možnost "pro každého".
A jak byste si to představoval jinak? Každý bude mít své vlastní jádro operačního systému ušité na míru? Kdo se o všechna ta jádra bude starat, kdo je bude vyvíjet? Prostě když lidé mají různé potřeby, musí mít i různé možnosti, jak ty potřeby uspokojit. A linuxové jádro nabízí obě možnosti – kdo chce a umí to, může si sestavit jádro na míru. Ostatní mohou používat univerzální distribuční jádra, která samozřejmě musí být přeložena i se spoustou modulů, které dotyčný nepotřebuje – to je daň za univerzalitu. Ty moduly se ale nahrávají dynamicky když jsou potřeba, takže přítomnost těch modulů v systému není zas taková ztráta.
jádro linuxu už trochu heká pod zátěží funkcí a podpory kde čeho a je na místě, čím vůbec jádro zatěžovat
Zajímalo by mne, jak jste na to přišel… Zatím je pořád snaha veškeré patche, které se používají a jsou mimo jádro, dostat do jádra, aby se zjednodušila jejich správa. Jakmile by se začalo řešit, že něco lidé sice chtějí používat, ale raději to do jádra nepřidáme, abychom tam neměli moc funkcí, byl by to konec Linuxu. Protože ten je založen na přesně opačném principu, na přidávání nových funkcí, na experimentování.
linuxu velmi chybí spolehlivé a kompatibilní rozhraní pro přidávání binárních modulů třetích stran
Ano, chybí. Jenže cena za takové rozhraní by pravděpodobně byla příliš vysoká – zakonzervování jádra a omezení dalšího rozvoje.
Všechno, co jsem napsal, mě po letech postupně odvádí od Linuxu k FreeBSD, protože tam je podpora běžného hardwaru, který používám (nebo který lehce používat mohu) stejně dobrá, ale jádro je mnohem čistší, jednodušší a vyvýjené konzervativně.
Tak používejte FreeBSD. Ty systémy jsou vyvíjené různě, je to záměr, a neexistuje žádný důvod, proč by se měl způsob vývoje Linuxu změnit na model FreeBSD jenom proto, že se někomu ten model líbí víc – když je tu spousta lidí, kterým víc vyhovuje model vývoje Linuxu. Tak ať si každý vybere, co chce – konzervativci FreeBSD, experimentátoři Linux.
Jenže cena za takové rozhraní by pravděpodobně byla příliš vysoká – zakonzervování jádra a omezení dalšího rozvoje.
To si nemyslím. Jsou zařízení, která opravdu potřebují jít "na dřeň" systému, ale jsou i taková, která mohou být obsluhována ovladačem přes univerzální rozhraní. Linux není jediné jádro na světě, a je vidět, že to možné je.
Tak používejte FreeBSD. Ty systémy jsou vyvíjené různě, je to záměr, a neexistuje žádný důvod, proč by se měl způsob vývoje Linuxu změnit na model FreeBSD jenom proto, že se někomu ten model líbí víc – když je tu spousta lidí, kterým víc vyhovuje model vývoje Linuxu. Tak ať si každý vybere, co chce – konzervativci FreeBSD, experimentátoři Linux.
Ano, s touto tezí souhlasím, přesto si myslím, že je dobré čas od času si možnosti připomenout a zamyslet se, jestli se třeba doba neposunula někam dál a není možné hledat nějaké ještě lepší řešení. Měl jsem na mysli např. to, aby opravdu existoval jeden univerzální kernel, který by poskytoval i binární kompatibilitu. Domnívám se, že takové jádro by bylo s to obsloužit 80 % potřeb. A pro zbylých 20 % by zůstala možnost kompilace a absolutního přizpůsobení.
Nyní je jádro linuxu ochuzeno o univerzalitu ve prospěch okrajových případů, které s ním lze řešit. Je možné, že i to stojí za tím, proč není Linux úspěšným konkurentem v desktopových nasazeních.
Pochopil jste mě špatně, pokud si myslíte, že chci Linux měnit. Mně bohatě stačí to, že si mohu vybrat a používat právě to BSD, nebo třeba konzervativně RHEL/CentOS. Moje psaní bylo hlavně o tom, že za ty roky vidím, jak se linux vyvíjí, a vidím i to, že kromě nezpochybnitelného růstu musí bojovat s novými problémy. Mně, jako uživateli / správci pak není moc jasné, kam se to bude ubírat, a to mi trochu vadí.
Nechci tu věštit z křišťálové koule, ale mám dojem, že mnoho lidí by ocenilo, kdyby linux a jeho distribuce uměly hlavně špičkově běhat na aktuálním mainstreamovém hardwaru, nebylo potřeba řešit problémy s power managementem, rozlišením obrazovky, polohovacím zařízením; správcům pak většinou stačí podpora běhu ve virtuálních prostředích - tam je navíc hardware abstrahovaný o stupeň víc. Zbylé možnosti jádra jsou pak pro nadšence.
Aktuální situace tedy je, že Linux přitahuje právě jen ty nadšence, ale té zbylé většině spíš klade pod nohy překážky. A z podstaty věci - nadšenci jsou spokojení, ale ti ostatní nejsou nadšenci. Proto ti "nenadšenci'" raději linux nepoužívají, protože nemají energii, čas, zájem býti nadšenci.
Takže se prosím za moje názory nerozčilujte, nejsou myšleny jako srážení linuxu, ale jako zamýšlení se nad tím, jak mu pomoci o level dál.
To si nemyslím. Jsou zařízení, která opravdu potřebují jít "na dřeň" systému, ale jsou i taková, která mohou být obsluhována ovladačem přes univerzální rozhraní.
Nejde o to, co potřebuje zařízení, ale co potřebuje jádro systému od toho ovladače. Pro některé typy ovladačů existují univerzální rozhraní.
Linux není jediné jádro na světě, a je vidět, že to možné je.
Nikdo netvrdí, že to možné není. Akorát by tím Linux přišel o svou flexibilitu. A je otázka, proč by měl Linux napodobovat jiné systémy – není pak lepší použít rovnou originál?
Ano, s touto tezí souhlasím, přesto si myslím, že je dobré čas od času si možnosti připomenout a zamyslet se, jestli se třeba doba neposunula někam dál a není možné hledat nějaké ještě lepší řešení.
Myslíte si, že se to neděje?
Měl jsem na mysli např. to, aby opravdu existoval jeden univerzální kernel, který by poskytoval i binární kompatibilitu. Domnívám se, že takové jádro by bylo s to obsloužit 80 % potřeb. A pro zbylých 20 % by zůstala možnost kompilace a absolutního přizpůsobení.
Tomu nerozumím. Binární kompatibilitu napříč čím? Různými verzemi jádra? Že bych si při kompilaci jádra zvolil, zda chci stabilní ABI nebo aktuální ABI? Čím by se to lišilo od dnešních LTS jader?
Nyní je jádro linuxu ochuzeno o univerzalitu ve prospěch okrajových případů, které s ním lze řešit. Je možné, že i to stojí za tím, proč není Linux úspěšným konkurentem v desktopových nasazeních.
Linux se používá od hodinek po superpočítače. Proč by měl tato prostředí vyklízet a soustředit se na desktop, když na desktopu je operačních systémů dost?
Nechci tu věštit z křišťálové koule, ale mám dojem, že mnoho lidí by ocenilo, kdyby linux a jeho distribuce uměly hlavně špičkově běhat na aktuálním mainstreamovém hardwaru, nebylo potřeba řešit problémy s power managementem, rozlišením obrazovky, polohovacím zařízením; správcům pak většinou stačí podpora běhu ve virtuálních prostředích - tam je navíc hardware abstrahovaný o stupeň víc. Zbylé možnosti jádra jsou pak pro nadšence.
Rozlišení obrazovky a polohovací zařízení nejsou věcí jádra, ale grafického systému. Power management je problém zařízení, která fungují podivně nebo rovnou v rozporu se specifikací, a chybějící dokumentace těch zařízení.
Zrovna běh procesů v kontejnerech udělal v Linuxu za posledních pár let obrovský pokrok a stal se z toho nový průmyslový standard (přestože to není vynález Linuxu a třeba BSD v tom bylo pokročilejší než Linux). Přitom jsou to přesně ty věci, které dříve byly pro nadšence.
Aktuální situace tedy je, že Linux přitahuje právě jen ty nadšence, ale té zbylé většině spíš klade pod nohy překážky. A z podstaty věci - nadšenci jsou spokojení, ale ti ostatní nejsou nadšenci. Proto ti "nenadšenci'" raději linux nepoužívají, protože nemají energii, čas, zájem býti nadšenci.
Neřekl bych, že by si Linux vedl na serverech špatně.
Takže se prosím za moje názory nerozčilujte, nejsou myšleny jako srážení linuxu, ale jako zamýšlení se nad tím, jak mu pomoci o level dál.
Já se nerozčiluju. Jenom bych zvážil, jestli by místo zamýšlení se nad tím, jak Linux ohnout tak, aby vyhovoval vám, nebylo vhodné zamyslet se nad tím, jestli nepoužívat jiný systém, který by vašim potřebám vyhovoval lépe. Protože podle mne kritizujete věci, které jsou výhodou Linuxu.
Protože podle mne kritizujete věci, které jsou výhodou Linuxu.
Už jen krátce.
O mě nejde, já si dokážu najít použití jak pro RHEL, tak pro Debian, tak pro FreeBSD a jsem spokojený.
Spokojení jsou asi i ti výrobci ledniček, hodinek a dalších zařízení.
Chtěli by být, podle mě, spokojení i uživatelé desktopu, kde chybí dostatečně jakostní alternativa k macOS a Windows. Tito lidé se pravidelně ozývají, i pravidelně čteme o tom, že jsou snahy o nasazení pro desktop.
Já to beru, já vydržím bez Linux desktopu, jako vynikající kompromis jsem si pořídil macbooka. Přesto myslím, že podobných kvalit by mohl dosahovat i Linux, kdyby se trochu změnilo přemýšlení o něm.
Já si myslím, že ta změna přemýšlení by znamenala, že by Linux přestal být tak dobrý na serverech, routerech, hodinkách, ledničkách, superserverech a také jako systém, po kterém sáhnete, když chcete dělat něco nového. A tam dnes srovnatelná alternativa není. Takže pokud má desktop MacOS a Windows, pořád je to o jednu alternativu víc, než kolik jich mají ty výše uvedené systémy. Ostatně, tak ať se na desktopu snaží autoři těch dvou systémů. Přičemž je zároveň otázka, zda a v jaké podobě desktop vůbec přežije, a jestli zrovna to je ta správná nika, kam by se měl Linux hrnout.
Já si myslím, že ta změna přemýšlení by znamenala, že by Linux přestal být tak dobrý na serverech, routerech, hodinkách, ledničkách, superserverech a také jako systém, po kterém sáhnete, když chcete dělat něco nového.
A vidíte, já si myslím, že řešitelné by to bylo. Servery a routery - tam linux převládá, ale přiznejme si, že ze setrvačnosti. Technicky není moc důvodů rozlišovat mezi Linuxem a BSD systémy pro provoz většiny serverů. Těch, u kterých je opravdu Linux potřeba, je zase jen zlomeček.
Hodiny, ledničky, mobilní telefony - já myslím, že by se vývoj nezastavil, ani nezpomalil, kdyby se více chránilo "tuhé jádro" kernelu Linuxu a zbylé moduly držely víc od těla. Někdy mám pocit, že výrobce zbastlí hardware a poté to "dodrátuje" ovladačem v kernelu linuxu.
Ostatně, tak ať se na desktopu snaží autoři těch dvou systémů. Přičemž je zároveň otázka, zda a v jaké podobě desktop vůbec přežije, a jestli zrovna to je ta správná nika, kam by se měl Linux hrnout.
Víceméně souhlasím, ale všímám si toho, že zde jsou lidé, kteří si o budoucnosti linuxového desktopu myslí něco jiného. Jim v podstatě říkáte, ale velmi nepřímo, že linux pro ně zaměřený není. Budiž, ale pak se to nebojme vyslovovat!
[Filip Jirsák ]
Myslím, že možnost, že by kód v současném jádru závisel na kódu v modulech, které do teď nebyly součástí jádra, můžeme rovnou vyloučit.To, že nějaký kód závisí na jiném kódu, je normální věc, to není žádný balast navíc – bez té závislosti by ten kód nefungoval.
To je pravda jen z casti - ma cenu se zbyvat tim, jake nove zavyslosti vytvori kod modulu, ktere jsou nove do jadra pridany.
Zavyslosti kodu jsou samozrejme normalni vec, o tom zadna, ale jak jsem psal vyse, je dost pripadu, kdy danou zavyslosti mezi moduly ne vsude vyuzijete. Jinymi slovy nekde fungovat bude i bez tohoto propojeni. Jen je prilis slozite (mozna dokonce nemozne) vzdy spolehlive urcit zda dana konfigurace je tou kde se zavyslost uplatni ci ne. Coz proste jednoznacne popira vsebecnou platnost tvrzeni: "Proto je jádro konfigurovatelné a nepotřebné věci tam vůbec nemusíte zakompilovat, a nebo je můžete mít jako moduly, které nenahrajete." Neni to proste vzdy pravda. Mnohdy se kompiluji moduly jen proto, ze na nejake jine konfiguraci by je mohl potrebovat modul, ktery zrovna pouzivam.
Většina kódu, která je ve zdrojácích jádra, nepoužívá většina lidí. Kdybyste tohle bral jako kritérium, musíte mít jádro pro jednu konkrétní hardwarovou sestavu.
Vyse pisu : "Sveho casu jsem byl nadseny myslenkou sestavit si naprosto monoliticke vanila jadro site co nejvice na miru pouzivaneho HW."
Že je ten kód ve zdrojácích ale ničemu nevadí, protože ho nemusíte do jádra zakompilovat, a i když použijete univerzální jádro, kde je to zakompilované jako modul, prakticky se vád to nedotkne do té doby, než ten modul případně do jádra nahrajete.
To taky nemusi byt vzdy pravda: prikladem budiz konflikt mezi noveau a oficialnim driverem od nvidie. Nebo moji osobni zkusenost, kdy abych mohl rozjet pridanou zvukovou kartu, musel jsem vykopat z jadra ovladace integrovane zvukove karty. Protoze ji system z nejakeho duvodu neustale "videl" a uprednostnoval. Duvod neznam, vim jen, ze nepomahalo ani (IMHO) zakazani v BIOSu, ani nastaveni v Alse, ani zakazovani nacitani konkretniho modulu, ani ... nic. Vysledkem vsech snah bylo pouze to, ze system spravne detekoval int. zv. kartu a zvuk nefungoval. Az odebrani ovladacu primo primo z jadra a jeho nasledna rekompilace vyresila situaci a jadro zacalo nasledne akceptovat novou zvukovku.
Moje zkusenosti rikaji, ze orezani a setaveni noveho jadra, co nejevice prizpusobeneho hw konfiguraci daneho stroje, pozorovatelne zvysi vykon stroje (v pripade uspechu - samozrejme). Coz uz samo o sobe dost nabourava tezi o tom, ze pritomnost velkeho mnozstvi nepouzivanych modulu vykon jadra neovlivni. jsem presvedcen ze je tomu presne naopak. Na druhou stranu, toto jsou zkusenosti ze stroje ktery mel CPU i2core a 2GB RAM. U CPU s sesti jadry a 8GB RAM to ocislysne (asi) moc uz vyznam nema...
Nemluve o faktu, ze s pribyvajicimi moduly silne stoupa i zlozitost a narocnost nakonfigurovani jadra a jeho uspesne sestaveni ze zdrojovych kodu. Ale to je proste vedlejsi efekt, se kterym se asi pocitalo...
To je pravda jen z casti - ma cenu se zbyvat tim, jake nove zavyslosti vytvori kod modulu, ktere jsou nove do jadra pridany.
Ne, je to pravda zcela, protože dokud byl kód mimo jádro, žádný kód z jádra na něm zcela jistě nezávisel, a pouhým přidáním toho kódu do jádra se na tom nic nezmění. Teoreticky by mohly takové závislosti vzniknout v budoucnosti. Ale silně o tom pochybuju, jádro si nemůže dovolit špagetové závislosti všeho na všem.
Zavyslosti kodu jsou samozrejme normalni vec, o tom zadna, ale jak jsem psal vyse, je dost pripadu, kdy danou zavyslosti mezi moduly ne vsude vyuzijete. Jinymi slovy nekde fungovat bude i bez tohoto propojeni. Jen je prilis slozite (mozna dokonce nemozne) vzdy spolehlive urcit zda dana konfigurace je tou kde se zavyslost uplatni ci ne. Coz proste jednoznacne popira vsebecnou platnost tvrzeni: "Proto je jádro konfigurovatelné a nepotřebné věci tam vůbec nemusíte zakompilovat, a nebo je můžete mít jako moduly, které nenahrajete." Neni to proste vzdy pravda. Mnohdy se kompiluji moduly jen proto, ze na nejake jine konfiguraci by je mohl potrebovat modul, ktery zrovna pouzivam.
Na tohle jste přišel jak? Měl byste nějaký příklad takové závislosti? Já si moc nedovedu představit, jak by to vzniklo.
prikladem budiz konflikt mezi noveau a oficialnim driverem od nvidie
To je ale jiný případ – tady jste chtěl použít jinou implementaci téhož modulu, ne že jste ten modul vůbec nechtěl použít.
Moje zkusenosti rikaji, ze orezani a setaveni noveho jadra, co nejevice prizpusobeneho hw konfiguraci daneho stroje, pozorovatelne zvysi vykon stroje
Pochybuju o tom, že když sestavujete jádro přizpůsobené konkrétnímu hardwaru, vše ostatní necháváte nastavené univerzálně.
Coz uz samo o sobe dost nabourava tezi o tom, ze pritomnost velkeho mnozstvi nepouzivanych modulu vykon jadra neovlivni.
Já jsem přesvědčen o tom, že to neovlivňuje počet modulů, ale množství funkcí zapnutých v jádře. A pak také možná kompilace optimalizovaná pro daný procesor.
Nemluve o faktu, ze s pribyvajicimi moduly silne stoupa i zlozitost a narocnost nakonfigurovani jadra a jeho uspesne sestaveni ze zdrojovych kodu. Ale to je proste vedlejsi efekt, se kterym se asi pocitalo...
Jistě, ale to je daň za univerzálnost Linuxu.
Filipe, ctete vubec co jsem Vam psal?
Jasne jsem delklaroval, z ktere cinnosti moje zkusennosti vychazeji a jake byli. Psal jsem i o tom, co k tomu psali (na dotaz jineho uzivatele) vyvojari. Nemohu tu diskuzi najit (uz to bude rok, mozna rok a pul co jsem se tim zabyval. Takze stranka muze byt smazana, nebo momentalne pokladam vyhledaveci spatne dotazi). Nicmene, vyzkouset si to muzte sam : Zdrojove kody jadra jsou Vam dostupne stejne jako me, make menuconfig, localmodconfig, ci localysconfig muzete pouzit take.
Ale kdyz o tom tak pisu, vzpominam si na jeden clanek, ktery moje slova o zavislostech mezi moduly v jadre urcitym zpusobem potvrzuje: http://www.abclinuxu.cz/clanky/jaderne-noviny-5.-1.-2017-sledovani-funkcnich-zavislosti-mezi-zarizenimi. Je asi rok stary, co se od te doby zmenilo nevim - uz mam jine starosti.
Letem svetem :
Ad zavislosti novych modulu. Teorie. Nove moduly jsou staveny na stavajicim kodu jadra a mohou bez problemu vyuzivat sluzeb modulu, ktere jiz existuji. tim vznika potreba, aby zavisle moduly byli v jadre pritomy i s tim novym. S tim co jste psal a soucasnym stavem, by jsme byli v paradoxni situaci, kdy by vznikali zavislosti, ktere vznikat nemohou.
Ad. noveau vs. nv blob
Ja v tom moc jiny pripad nevidim. Pojkud existence nejakeho modulu pripojeneho do jadra jadro nijak neovlivni do doby, nez se zacne pouzivat, nemela by vadit jeho pritomnost. Moduly (by se mely idealne) chovat jako samostatne nezavisle jednotky - konec koncu, to je prece to co se mi snazite celou dobu vysvetlit, ne?
ad Já jsem přesvědčen o tom, že to neovlivňuje počet modulů, ale množství funkcí zapnutých v jádře. A pak také možná kompilace optimalizovaná pro daný procesor.
No a ty funkce jsou z vetsi casti kde? V modulech
ad Pochybuju o tom, že když sestavujete jádro přizpůsobené konkrétnímu hardwaru, vše ostatní necháváte nastavené univerzálně.
To tvrdim kde?
ad Jistě, ale to je daň za univerzálnost Linuxu.
To nezpochybnuji.
Jasne jsem delklaroval, z ktere cinnosti moje zkusennosti vychazeji a jake byli. Psal jsem i o tom, co k tomu psali (na dotaz jineho uzivatele) vyvojari.
Nikoli, napsal jste nějakou svou interpretaci – která moc nedává smysl.
Ale kdyz o tom tak pisu, vzpominam si na jeden clanek, ktery moje slova o zavislostech mezi moduly v jadre urcitym zpusobem potvrzuje
Spíš to potvrzuje, že to špatně interpretujete. Ten článek je o tom, že u konkrétní instalace na sobě zařízení nějak fyzicky závisejí. Když máte připojenou myš do USB hubu a chcete tato dvě zařízení uspat, musíte nejdřív uspat myš a až po té hub, protože když nejprve uspíte hub, ztratíte možnost komunikace s myší.
Nove moduly jsou staveny na stavajicim kodu jadra a mohou bez problemu vyuzivat sluzeb modulu, ktere jiz existuji. tim vznika potreba, aby zavisle moduly byli v jadre pritomy i s tim novym. S tim co jste psal a soucasnym stavem, by jsme byli v paradoxni situaci, kdy by vznikali zavislosti, ktere vznikat nemohou.
Jenže já jsem psal o opačné závislosti, o závislosti starého kódu na nových modulech (které v té době v jádře ještě nebyly). To je totiž ta závislost, která by vedla k bobtnání jádra i pro uživatele, kteří ten nový modul nepoužijí. Když uživatel ten nový modul nechce, a nový modul závisí na starém kódu, modul do jádra nezakompiluje – a výsledkem bude stejné jádro,jako kdyby ten modul ve zdrojácích vůbec neexistoval.
Pojkud existence nejakeho modulu pripojeneho do jadra jadro nijak neovlivni do doby, nez se zacne pouzivat, nemela by vadit jeho pritomnost. Moduly (by se mely idealne) chovat jako samostatne nezavisle jednotky - konec koncu, to je prece to co se mi snazite celou dobu vysvetlit, ne?
Já jsem ale nepsal, že jádro nijak neovlivní – psal jsem, že ho skoro neovlivní. Ten modul musí mít v jádru nějaký vstupní bod, a pokud jsou to dva ovladače pro stejný hardware, logicky se budou ty vstupní body navzájem vylučovat, protože nemohou jeden hardware spravovat dva ovladače najednou. Teoreticky by ty dva moduly mohly mít v jádru společné rozhraní, jenže to by se na tom jejich autoři museli domluvit. Což asi nebude případ těchto dvou modulů.
To tvrdim kde?
Netvrdíte to. Ovšem když sestavíte jádro s podstatně menším množstvím funkcí, nevím, co vás překvapuje na tom, že je pak rychlejší. Vůbec to nezáleží na tom, kolik modulů leží na disku, ale na těch funkcích v běžícím jádře.
Mimochodem, pokud to beres takhle, tak mas stesti, ze se o vyvoj jadra moc nezajimas.
Jinak by ti mohlo neklidne spani zpusobit to, ze v jadre uz existuji (para)virtualizacni ovladace napr. pro:
* VMWare
* Hyper-V od Microsoftu
* virtio (KVM)
Neco mi rika, ze kdyz k tomu pribyde VBox, ze se na tom nic moc nezmeni :-)
zkus to brat tak jak to je, tzn. jedna se o ovladace pro beh systemu nad (konktretnim) virtualizovanym HW...
v modulech mas logicky (pokus si sam nezkompilujes jadro na miru svemu hw) tisice veci ktere nemusis pouzit, ale jsou tam pripravene (a je to dobre) pro ty co to pouzit chteji/potrebuji...
nebo ti vazne vadi ze distribucni jadro si sebou pritahne (externi) moduly pro IDE radic (~40 ruznejch IDE ovladacu), pro BT (i kdyz to ty poustit na HW bez BT), a muzem jit i mimo ovladace jako takove, co podrpora sifrovani disku? kdyz ji ty nepouzijes nema tam byt? a ten kdo by ji chtel pouzit si ma stahnout jadro-with-cryptomodules? :)
Proc ne ?
To uz by me z puristickeho pohledu spis rozcilovalo tohle: https://github.com/torvalds/linux/blob/master/arch/x86/kernel/cpu/vmware.c
To neni ani modul :-)