kernel, boot e init

[djdas]

Ho capito!
Abbiamo tempi di startup del timer diversi
Io conto i secondi dal flash bianco, cioè DOPO che il kernel sia caricato, tu li conti prima comprendendo anche il tempo di caricamento. IMHO il tempo corretto è dallo splash bianco perché in ogni caso la distro in sé comincia da lì e solo lì possiamo ottimizzare, tanto più che ormai qualunque cell moderno praticamente ha un kernel da avviare e normalmente l'utente percepisce lo "start" dal flash.
In ogni caso direi che 5 secondi sono un dettaglio, ricordiamoci sempre che i mokousers sono abituati a 1,5-2,5 MINUTI!!!
Ciau!

[LeOS]

aaaaa ok
perche' se leggi nelle mie doc, i tempi di boot sono intesi: da quando appiccio l'oggetto, quindi da quando premo il pulsante di power!
che cmq (filosofie di funzionamneto a parte) sono i tempo fisici che si aspettano da quando accendiamo il telefono a quando e' up!
adesso e' chiaro volevo solo capire come mai questa differenza
certo che se si riuscisse ad ottimizzare quella parte iniziale sarebbe gran cosa ma io non so proprio dove metterci mano!

[djdas]

Beh sicuramente un kernel piccolo carica prima e parte più velocemente ma onestamente guardando anche il boot della FDTF con quello vecchio tutto modulare non è che la differenza sia poi così tanta, siamo sempre dell'ordine del secondo (ed è quasi un mega più piccolo), però sicuramente ne risente poi all'atto del bootstrap perché man mano che riconosce i dispositivi deve caricare i moduli....Sarebbe interessante (ma non è il momento, abbiamo troppe cose da fare) provare con lo stesso kernel nelle due versioni monolitico e totalmente modulare, sulla stessa distro per vedere cosa succede.
Diciamo in ogni caso che, come scrivevo prima, dal nostro punto di vista guadagnare 2-3 secondi è davvero irrilevante visto il salto di qualità rispetto a tutti gli altri possiamo pensarci anche dopo.
Una cosa che si potrebbe provare è, nel caso sia supportato, caricare una bzImage cioè il kernel compresso, magari i tempi lunghi sono nell'accesso alla flash e lo scompattamento accelera....boh!
Ciau!

[LeOS]

sai cosa sarebbe davvero bello?
invece che kernel e tanti spezzettoni di file, avere un unico filone che contiene tutto, e pompare al 100%la cpu durante il boot, metodo simile a quello utilizzato in LPC
ma questi sono fronzoli di cui ci occuperemo alla fine, quando avremo tutto l'ambiente pronto!

[Stemby]

Sì, anch'io credo che per l'ottimizzazione finale dovrete (io non sono in grado) trovare il modo per avere la CPU costantemente il più vicino possibile al 100%, ovviamente a fare cose utili.

[LeOS]

anche oggi penso ergo sum
ipotizziamo di aver terminato la neophys.
accendo il fr e il sistema parte, parte con tutto quello che serve di default, x, ofono, dbus, non penso debba partire altro, inteso come demoni
ogni demone viene avviato con il proprio script che sta dentro /etc/scripts
l'utente potra' cmq avviare altri servizi/demoni attivare funzioni (wireless, bluetooth, gps) autonomamente

per tracciare cosa c'e' UP in quel momento, direi che ogni script di avvio scrivera' anche un file ad esempio /var/run/running.apps
ogni demone avra' la propria entry, ad esempio, al momento in cui appiccio bluetooth, tirando ad esempio su il hcid, avro' la voce bluetooth (piuttosto che hcid) dentro il file running.apps

al momento dello spegnimento faro' un controllo di cosa c'e' dentro il file e spegnero' via via i demoni attivi per procedere correttamente allo shutdown

potrebbe essere interessante il metodo alla gnome dove ti permette di salvare le "running applications" quindi se ho impostato le preferenze con "ricorda lo stato del telefono" semplicemente questo file viene copiato, prima dello shutdown, all'interno del fs non volatile per poi essere ricopiato in /var/run al prossimo boot

cosa ne pensate?

[LeOS]

ho scritto queste due righe:

Code:

root@Apricot-RC2:~# cat /opt/bin/running.sh
#!/bin/sh
RUNFILE=/var/run/running.apps
CMD=$1
APP=$2

if [ ! -e $RUNFILE ] ; then touch $RUNFILE ; fi

case $CMD in
  add)
    mv $RUNFILE $RUNFILE.new
    echo $APP >> $RUNFILE.new
    sort $RUNFILE.new | uniq > $RUNFILE
    rm $RUNFILE.new
  ;;
  remove)
    mv $RUNFILE $RUNFILE.old
    sed /$APP/d $RUNFILE.old > $RUNFILE
    rm $RUNFILE.old
esac

eseguendo questo script con la sintassi:

running.sh add pippo
oppure
running.sh remove pluto

va a togliere e mettere nel file definito nella variabile RUNNING l'applicativo
facendolo eseguire dai vari script di partenza/avvio e' assai semplice togliere e mettere le voci dal file

[LeOS]

questo e' il risultato sulla apricot:

Code:

root@Apricot-RC2:~# cat /var/run/running.apps
dbus
dropbear
ofono

[nicola.mfb]

Se il filesystem è readonly ha senso fare lo shut pulito (kill -TERM) solo dei daemons che potrebbero avere delle write pendenti sulla partizione rw (ad esempio npd che riceve un messaggio da ofono e lo deve ancora salvare da qualche parte).
Dovresti gestire poi le dipenzende fra i vari sottosistemi da cui dipende npd (esempio eds, che va trattato dunque allo stesso modo), rimontare la rw partition in ro , se il remount fallisce miseramente avvisa l'utente e riprova n volte, dopo le n volte che il kill -TERM non è andato, vai in kill - KILL ed alla fine in ogni caso spegni definitivamente il device e "bonanotte"

Idea vaga, da elaborare.

ciauZ

    Niko

[LeOS]

corretto
al momento pero' non avendo NULLA di piu' ho cominciato a tracciare quel che era UP
lo script di shutdown terra' conto di quello in /var/run/running.apps

[djdas]

Uhm, credo che però non si debba fare il sort del file perché è possibile che qualche app da runnare "in sessione" dipenda dal fatto che altre siano già partite (vedi ofono <- dbus) quindi imho dovresti numerarle (magari usando il PID) o comunque tenere l'ordine di avvio nel file.
Per il resto l'idea mi piace, complimenti
Ciau!

[LeOS]

uhm il problema e' che:
appiccio un servizio, faccio >> file
se per errore lo appiccio due volte avrei un duplicato, risolvibile solo con un sort|uniq!

[djdas]

Scusa ma se fai un grep del nome del servizio nel file e lo trovi non lo memorizzi ed esci, o mi sono perso qualcosa?
Ciau!

[LeOS]

uhm quindi
if greppa allora esci e fai finta di nulla else echo >> file

confermo che ho bisogno di ferie

[djdas]

Confermo Per un attimo non ti avevo riconosciuto!
Ciau!