Új hozzászólás Aktív témák

• #16999 proximus senior tag ko9 #16985

  Új Válasz 2012-09-21 00:35:58 #16999

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  proximus

  senior tag

  válasz ko9 #16985 üzenetére

  "Ide pedig kell, mert ez tölti be a fő komponenseket. Ha érdekel itt van egy Ramdisk, igaz ez Arc meg ICS Alpha, de 1-2 sor különbséggel ugyanaz mint amit most használunk."

  Szerintem inkább csak azért használják itt is, mert így egy valamennyire generic full frissítést tudnak összehozni a fejlesztők és nem kell annyit reszelni minden egyes telómodellre. Ez valahol lustaság, vagy céges költségcsökkentés...

  Tényleg nincs rá szükség, ha minden -folyamatosan használatban lévő- hardverkomponensre beépítik a kernelbe a támogatást. Azoknál nincs értelme cicózni, meg még hátrányos is a modul betöltésének extra szükségessége miatt. +ott van még a RAM fragmentáció, ami óhatatlanul bekövetkezik ahogyan fut a rendszer, ezért nem mindegy mennyire korán és menyire "fizikailag előre", illetve "egy darabban" töltődik be az a modul. Ez is csökkentheti a teljesítményt, meg több erőforrást ehet fölöslegesen, habár fogalmam sincs, hogy egy ennyire vérszegény(normál PC arhitektúrához képest) hardvernél mennyire is.

  Valami nagyon furát látok annál a ramdisknél, amit linkeltél. Megvannak a szkriptek, megvannak az alap executable fájlok, de hol vannak a kernel-modulok? A root fs-é, meg ilyenek? Azt mégiscsak beforgatják a zimage-be? Egy asztali Linuxnál leginkább ennyi szokott lenni az értelme a ramdisknek. Telepítésnél ugye a disztróknál rengeteg fs közül lehet választani, de legalábbis több közül és nem akarják azt a (fölösleges) overheadet+ esetleges sechole-t bevállalni, amit az összes fs kernelbe forgatása magával hozhatna.

  "Ebben nekem segíthetnél A napokban kezdtem Arch Linuxozni, nagyjából kezdem átlátni, de a kernelmódosításig még nem jutottam el."

  Lehet róla szó, bár jó kérdés, hogy mennyire akarod testre szabni. Jómagam elég rendesen belenyúltam mind a kernelbe, mind pedig a boot scriptekbe. Fogtam a gyári rc-ket és alaposan kiheréltem őket, így aztán elég "üveghangon" tud menni a rendszer... De komolyan. Gyakorlatilag annyira közvetlenné tettem mindenféle komponens elérését/elindítását a boot során, amennyire csak lehetséges volt. Az Xorg is mindenféle bejelentkezés nélkül jön be, mint a windowsoknál szokás 1 felhasználóval. Jó ok, minden root hozzáférésű, de hát had legyek már én az... Aki meg be akar jönni kintről a net felől, az úgyis bejön... Szóval nálam a "teljesítmény mindenek felett" volt az elsődleges szempont, amikor összehegesztettem ezt a rendszert. Mondom 6-8 sec alatt vár az lxde desktop, a grub-ban nyomott enter után. SSD-vel meg bele sem merek gondolni... 1-2 secért cserébe elő tudom töltetni a firefoxot is pl., ha betanítom az e4rat-nak.
  Rengeteg Linux-buheráláson vagyok már túl és a mostani fölállás már egy nagyon letisztult konstrukció a részemről. Az Arch előtt sokáig Gentoo-ztam, de nagyon időrabló volt, meg retek lassú a csomagkezelője(portage), lévén hogy az egész "gombóc" python script alapú. Az Arch pacman-ja szélvészgyors ahhoz képest, node az C, vagy C++ nyelven is íródott... Meg a Gentoo elég sok "szemeteléssel" járt, a rengeteg forrás+devel cumó miatt is. Egyébként az LFS Linuxon is gondolkoztam egy darabig, de hallod az már nagyon elvetemült cucc... A legtöbbet adhatja tanulásban, de a legkevesebbet mindennapi használatban, a felhasználói rugalmasságát tekintve. Arra tutira jó, hogy megismertesse a/egy Linux "disztró" felépítését az alapoktól. A disztribúciók között egyébként az Arch egy nagyon letisztult rendszernek számít és ha valaki kicsit is szereti magának beállítgatni, meg finomhangolni az oprendszert, én tutira nem az Ubuntut, meg ilyen "bloatware"-kat ajánlanám egyiknek sem. Egy lépcsőt ugorva "egyszerűségben" még ott van a nagy öreg "pipás" Linux is, a Slackware. Jó érzés arra gondolni, hogy a Slackware szinte a kezdetektől fogva kézenfogja a Linuxot. Mondhatni a gyerekkorától kezdve.

  Egyébként az Arch Linux úgynevezett Hook-okat használ a bootoláskor és valamennyire "gyárilag" lehetőséget biztosít arra, hogy főbb területeket kikapcsolj a ramdiskben, de annyi. (Újraépíti automatikusan, miután beletesz, vagy kivesz "Hook-okat") Azt például már nem lehet a Hook alapú betöltésnél megcsinálni, hogy teszem azt csak egy bizonyos hangchiphez akarok támogatást, mert vagy "mindhez, vagy semmihez". A teljesen saját kernelt lehetetlenség űberelni, mert akkor "egy gyűrű mind felett" lenne a jutalom érte, de ezt nem lehet véghezvinni egy tömegeket célzó rendszernél. Kénytelenek Generic-re csinálni így vagy úgy.

  El tudom például küldeni azokat a szkripteket/fájlokat, amivel magamnak oldom meg a bootot +a mostani kernelem konfigját akár, ha gondolod.

  Tényleg, egy kérdés. Nyitott b.l. esetében azért mégiscsak a kernel mellett van a ramdisk a /boot-ban nem? Onnan gondolom, hogy végigformázhatok minden partíciót a CWM-ből, de az (maga a CWM) akkor is megmarad/megmaradt reboot után.

  "Pedig direkt megnéztem, és esküszöm nem láttam. Viszont akkor nagy hiba, hogy nem rakta be a RAMDiskbe."

  De látod érdekes, hogy többen nem rakják bele, mint ahányan igen. Nem tudom miért, ha már egyszer módosított(ák) a kernel(t) és nem eszi meg a stock ROM "gyári" moduljait...

  "Ez a "futtatni" zavar egy kicsit még, mert már rámásolni sem engedi a (zárt) b.l. a készülékre az aláíratlan kernelt, nem?

  Feltennie fel kell tudni, a futtatást tagadja csak meg."

  Pedig nem engedi/engedte a flashtool (szóval a zárt b.l.) fastboot módban rátenni a custom kernelt. Ez (volt) a hibaüzenet:
  The Device must be rooted first
  Szóval nem megy fel sem.

  "Az ördög a részletekben rejlik. Rendes, asztali Készülékek nagyrészén itt is törölhető futás közben - CWMből. Végülis ott is él a kernel, és fut. De nem a Sonynál
  Lehet itt is törölhető lenne, ha hozzá tudnánk férni."

  Áhááá...
  Szerintem is menne a dolog, csak ez a redves flasmode/fastboot/system load szeparáció...

  "Megérzi persze. Bírni bírná, de amikor azon vagyunk, hogy akksifogyasztást optimalizáljuk, akkor minden lehetőséget meg kell ragadni. Tervbe van egy teljesen modulos kernel, amiből kiszedek szinte mindent ami lehet modulként gyártani, és csinálok egy szkriptet, amivel a felhasználó kiválaszthatja, hogy miket akar használni, és azt indításkor insmodoltatom. Így akár elérhető a gyárinál jobb fogyasztás is."

  Hmm, nem rossz ötlet. Akkor erről a fajta kernelről beszéltél te korábban, amit össze akarsz hegeszteni.(?) Végülis ha tényleg vannak beolvasztott, de csak alkalmanként használt szolgáltatások/driverek a kernelben, akkor azokat tényleg ki lehetne dobálni modulba. Persze jól meg kell gondolni, mert könnyen a "kígyó a farkába harap" effekt jöhet össze belőle. Az asztali gépen ezt már vagy 100-szor biztosan átéltem, amíg gyomlálgattam kifelé a kernelt, de megérte az erőfeszítést a cserébe megszerzett tudás/tapasztalat. No meg a kész "csoda-bzImage".

  "Ezt még eddig nem is néztem, de lehet ránézek majd kernelkonfignál.
  Github lapomon megtalálod a kernelforrást, ránézhetsz ha érdekel."

  A .config megvolna valamerre? (Akár a gyári kernelé) Ja meg ezt a forrást mondjuk az Arch Linux alatt is tudom konfigolni/lefordítani, vagy kell hozzá egyfajta emuláció/virtuális gép?

  "Persze, hogy nem mai gyerek. Elég csak arra gondolni, hogy a Defy 2ndInitnek is az az alapja. Ott zárt teljesen a bootloader, nyitni se nagyon van lehetőség, és így oldották meg."

  Hmm, nem rossz. Mármint hogy ki lehetett kerülni. Akkor a Defy CM modjai akár már zsír új kernelekre is épülnek/épülhetnek ezzel a trükkel? (Ha van arra is CM)

  "Node magát a verziót ellenőrzi? Meg kell hamisítani azt is.
  Ilyen ötletet már hallottunk mi is. Kétlem, ha kicseréljük a Makefile-ban a verziót, akkor menni fog minden. Tuti ellenőrzi azt máshogy is."

  Hátha bénák voltak...

  "Igen, legfrissebb CM-ek erre."

  Huhúú, köszi szépen.
  Csinálok majd backupot a CWM-ben a Nightly-mról és megy is fel próbára...

Új hozzászólás Aktív témák