Newsgroup: it.comp.os.linux.sys
Titolo: passare parametri al kernel

Ciao. Spesso capita che sia necessario passare dei paametri ad un modulo;
per esempio con una scheda TV basata su philips saa7134 occorre in molti
casi specificare il parametro card=n per far riconoscere la scheda, tuner
etc etc al sistema.
Se pero' compilo il supporto al saa7134 *dentro* ad un kernel monolitico,
senza cioe' moduli, esiste un modo per passare lo stesso parametro card=n
al kernel? Immagino si debba passare per il LILO e la direttiva append, ma
qual e' la sintassi esatta???
Per favore NON ditemi:
append="card=6"
dato che palesemente non funziona.
Per ora ho risolto modificando il kernel e settando come default la scheda
in mio possesso, ma e' un po' un rompimento :) ogni volta che si aggiorna
il kernel...!

 qual e' la sintassi esatta???
Se non vado errato, uno dei motivi per usare i moduli
e` proprio la possibilita` di passare parametri durante
il caricamento degli stessi.
Che problema hai ad usare il driver come modulo?
bye,
-- 
   Piergiorgio Sartor



palesemente un corno ...
a me funzia benissimo
riguardati il file di configurazione
la sintax è sbagliata
modinfo è tuo amico
man lilo pure
bye

 Che problema hai ad usare il driver come modulo?
che tutto sta in un file solo...! no dipendenze, no files di
configurazione, no modutils che occorre tenere aggiornati (vedi kernel
2.6.x) etc etc
Inoltre pensa ad un sistema embedded tipo computer da mettere a fianco del
televisore, che fa il boot da una compact flash 16MB... avere un unico
file che contiene tutto il necessario...!
ciao
as

 man lilo pure
:) potresti farmi un esempio???
nel kernel ci sono 17 moduli che prendono il parametro "card" come faccio
a specificare a quale driver e' rivolto il parametro?
ciao
as

 as
append="video=matrox:disabled"
esempio....
leggi la documentazione nel source tree e dai un'occhiata ai sorgenti....
a volte info si trovano anche la'
bye

 file che contiene tutto il necessario...!
Questo e` in contraddizione con quanto sopra.
Un sistema del genere, una volta fatto, si
aggiorna raramente.
E poi, tipicamente, usi initrd per queste cose.
bye,
-- 
   Piergiorgio Sartor

 E poi, tipicamente, usi initrd per queste cose.
hai ragione ma secondo me non si fa altro che aggiungere complessita' al
sistema senza reali vantaggi... alcune distro mettono addirittura il
supporto al FS in moduli! dai... in tutte le cose e' meglio non esagerare.
In ogni caso il problema non e' questo, indipendentemente dal fatto che
sia una cosa buona o no, come si fa (se e' possibile) a passare dei
parametri direttamente al driver da LILO???
ciao!
as

 a volte info si trovano anche la'
senza voler polemizzare, conosco molto bene il fatto che spesso molti
newbies chiedono info senza andare a cercare negli howto o simili.
Tuttavia non ho chiesto "kppp mi dice che la connessione e' caduta" oppure
"come configuro il modem adsl usb", ma una cosa relativamente piu'
specifica e di cui e' difficile trovare descrizione dettagliata. Forse
sono stato sfortunato, ma ne' dejanews, il kernel howto, ed alcuni canali
irc mi sono stati d'aiuto. Non posso dire di non aver guardato i sorgenti
dato che addirittura li ho greppati e modificati allo scopo.
Insomma ti ringrazio per i consiglio che mi hai dato :)
ciao!
as

 parametri direttamente al driver da LILO???
Per quello chiedevo.
Risolvi anche questo problema.
bye,
-- 
piergiorgio

 dal sito ed "appiccicato" al kernel corrente al volo.
La cosa e' molto interessante, tuttavia c'e' un fatto che io giudico molto
importante. Succede molto spesso, credo sia nell'ordine delle cose, che
una macchina abbia problemi di sopravvivenza ad un reboot. Se aggiungo un
nuovo modulo o modifico anche un componente software userspace, io faccio
sempre un reboot per controllare che tutto funzioni a dovere. Infatti
nulla di piu' facile che un comando lanciato da shell, con certe variabili
d'ambiente, funzioni a dovere mentre fatto partire da uno script di
inizializzazione non trovi paths e librerie.
Non per nulla in questo genere di esperimenti ho messo linuxbios che mi
assicura un boot che si misura in secondi e non in minuti, come succede
con le distribuzioni "grasse".
Procedendo per induzione, sto tentando di inserire tutto il possibile nel
kernel per saltare a pie' pari tutti i tempi "morti" che servono al
caricamento dei moduli ed anche all'autodetect eseguito da certi driver
(per esempio specificando gia' i parametri delle periferiche IDE etc).
Ora che ho capito come passare parametri ai driver compilati dentro al
kernel, vedro' di preparare un kernel che questi parametri li abbia gia'
integrati senza bisogno di bootloader ad hoc :)
PS sembrera' paranoico ma 1) linux e' bello perche' ognuno ci fa quello
che gli pare nella maniera piu' strana possibile, 2) se devo realizzare un
videoregistratore digitale questo dovrebbe idealmente comportarsi come un
videoregistratore: un bottone e si accende in pochi secondi, un altro e si
spegne in ancora meno tempo....!
ciao!
as

 inizializzazione non trovi paths e librerie.
Buona regola quando si fanno gli script è infatti dichiarare la
variabile di PATH necessaria all'inizio...
un bel:
#!/bin/bash
export PATH=/percorso/che/mi/serve:/secondo/percorso:/terzo/percorso
e poi via col resto.
A quel punto hai la *certezza* matematica che quello script non andrà
mai in crisi per il path.
-- 
Massimo Bacilieri AKA Crononauta 
ICQ:4005815

 variabile di PATH necessaria all'inizio...
si di solito io uso anche percorsi assoluti per tutti gli eseguibili ed i
files coinvolti etc
ciao
as

 (per esempio specificando gia' i parametri delle periferiche IDE etc).
Per curiosita`, quanto hai guadagnato de-modularizzando il tutto?
Sul mio sistema ho fatto qualche prova senza impegno tempo fa, 
e il guadagno non c'era.
-- 
 Francesco Romani - Ikitt  | Describe your vision, the meaning is missing |
*** mailserver: 
freemail.it
| Won't anybody listen?                        |

 (per esempio specificando gia' i parametri delle periferiche IDE etc).
Il tempo di boot di un kernel modulare e` piu`
basso di uno monolitico.
Il motivo e` che il kernel e` piu` piccolo (per
quanto poco) e quindi parte prima.
I moduli li carichi quando e se servono, quindi
i tempi sono piu` bassi.
Piuttosto mi interessa linuxbios, quanto e` stato
difficile installarlo?
bye,
-- 
piergiorgio

 difficile installarlo?
beh dipende dalla scheda madre che consideri. Una pcchips 810 lmr e'
banale basta scaricare l'immagine gia' pronta da 
ftp.cwlinux.com
 e,
compilati i tools per flashare il bios, sei a posto in pochi minuti. Se
invece vuoi iniziare il port per un nuovo chipset :D auguri. Nel caso
intermedio, ovvero ti vuoi creare un'immagine personalizzata per un
chipset supportato, il problema principale secondo me risiede in: 1)
linuxbios non ha documentazione e devi leggerti gli esempi ed
eventualmente i sorgenti per avere una lista dei parametri configurabili
2) il grosso problema e' il boot loader, si usa normalmente etherboot in
questi casi, e secondo me etherboot e' veramente ostico.
Il problema e' che le normali flash da computer sono 2Mbit ovvero 256KB di
memoria; cio' non permette di inserirci un kernel (vabbe' qualcuno c'e'
riuscito ma lasciamo perdere :) ) ma solo il linuxbios ed un bootloader;
il kernel vero e proprio deve essere poi caricato per esempio da una
periferica IDE. Con una piccola compact flash montata sul canale IDE
tramite adattatore puoi avere un dispositivo che non necessita di tempi di
spin-up per essere accessibile. Puoi cosi' bootare un computer in pochi
secondi. Linuxbios stesso credo faccia tutte le inizializzazioni
dell'hardware in alcuni decimi di secondo, poi viene caricato il kernel
che si decomprime e boota. In tutto boh saranno dieci secondi?
C'e' chi si puo' permettere un "disk on chip" che ha lo stesso zoccolo di
una memoria flash per BIOS ma contiene 16MB circa di memoria; in questo
caso ci si puo'; mettere linuxbios e direttamente il kernel desiderato ed
a questo punto anche un piccolo FS per il boot. Peccato che tali
disk-on-chip costino parecchio, mi pare 50 sterline o simili...
ciao
as

 e il guadagno non c'era.
attenzione: io come spiegavo sopra non mi aspetto tremendi vantaggi sul
TEMPO di boot usando un kernel monolitico invece di uno modulare; in
quest'ottica mi apsetto solo una semplificazione della gestione e la
non-necessita' di inserire le modutils ed altri binari in un filesystrem
magari contenuto in una memora flash o simili.
Invece volevo ricercare la possibilita' di guadagnare sul tempo di boot
specificando gia' tutti i parametri in merito al mio hardware, in modo che
(modulare o no) il mio kernel non debba perdere tempo per fare
l'autodetect delle periferiche.
ciao!
as

 disk-on-chip costino parecchio, mi pare 50 sterline o simili...
Link od info al riguardo?
Thanks,
bye,
-- 
piergiorgio

 Link od info al riguardo?
Una delle poche cose utili del sito e' il link alle esperienze degli
utenti, uno racconta appunto dove si e' procurato i DoC e tutta la storia;
mi pare abbia usato Linuxbios per creare un routerino composto a livello
hardware da schedina madre, processore, memoria e basta; infatti non ha
periferiche IDE o di memoria di massa tradizionali dato che tutto sta nel
DoC. C'e' da dire che e' indubbiamente interessante.
Poi c'e' l'ftp ed il web di cwlinux ( <ftp|www>.
cwlinux.com
 ) dove swi
possono trovare documenti e immagini linuxbios gia' pronte. Poi ovviamente
c'e' la mailing list.
Il fatto e' che, paradossalmente, linuxbios e' poco diffuso sulle macchine
di fascia bassa perche' il target reale degli sviluppatori sono i
grandissimi cluster di computer, ovvero schede madri biprocessore, etc,
c'e' tantissimo fermento sulle schede madri per Opteron dato che molte
usano in modo nativo una versione di linux integrata per il management
remoto della scheda stessa, etc.
ciao!
as

 se e' per questo);
Perché? Controllare un PVR via finger sarebbe il massimo della
geekiness. ;-)
wolverine:~ $ finger @pvr.homenet
  This is PVR (at) homenet
  The currently set timers are:
  * [0] - day: mon -> fri; time: [20:00-21:00]; channel: 6
  * [1] - day: sat;        time: [22:45-23:45]; channel: 4
  Status: -idle-
  Next timer-id: [0]
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://digilander.libero.it/ebassi/
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 quindi in generale si pone il nomeparametro=nomedriver:valore ???
No, l'esempio  di video  e` fuorviante. Inoltre dipende  dal kernel. Nei
2.6 si usa saa7134.parametro=valore. Con i 2.4 non ricordo...
Kronos
-- 
Home: 
http://kronoz.cjb.net
Non ho ancora capito se il mio cane e` maschio o femmina:
quando fa la pipi` si chiude in bagno

 2.6 si usa saa7134.parametro=valore. Con i 2.4 non ricordo...
ok infatti mi sembrava strano che non riuscissi a combinare nulla!
il problema non era banale
ti ringrazio molto kronos
ciao
as

 Beh su un videoregistratore non ci metterei certo xinetd (e nemmeno inted
Dimmi una cosa: questo e` un tuo progetto originale
oppure stai prendendo cose dalla rete?
Che SW usi per codificare?
Player? GUI?
CPU? MB?
Sono molto interessato, quasi quasi mi compro
un EPIA per lo scopo...
bye,
-- 
   Piergiorgio Sartor

 un EPIA per lo scopo...
fai attenzione dato che molti processori VIA non riescono a fare il
decoding dei divx, e la cosa e' piuttosto limitante...
ciao!
as

 decoding dei divx, e la cosa e' piuttosto limitante...
Azz, ma se ci riesco con il mio K6-3 @ 550MHz...?
Comunque thanks,
bye,
-- 
piergiorgio

 Azz, ma se ci riesco con il mio K6-3 @ 550MHz...?
beh non aspettarti troppo da quelle cpu cinesi... sembra vadano di moda ma
secondo me sono scarsissime. In ogni caso le piu' recenti dovrebbero
essere in grado di visualizzare mpeg4; le prime pero' non a caso avevano
un decoder hardware mpeg2 montato su scheda, dato che da sole non ce la
facevano...!!
ciao
as

 geekiness. ;-)
beh VDR ha un suo demone che permette il controllo via rete; anche se si
usasse un finger ;) io sinceramente non ce lo metterei nell'inetd ma
direttamente come demone. Credo che nei sistemi embedded di questo tipo
sia molto meglio favorire la bassa latenza che eventuali piccoli risparmi
di memoria occupata.
Un videoregistratore non deve prescindere secondo me dalla rete, tanto che
un amico sta progettando il suo sistema diskless che archivia le
registrazioni via NFS; btw, linuxbios e' veramente l'ideale in caso di
boot remoto e root FS via rete :)
ciao!
as