On Thursday 15 November 2001 01:09, you wrote:
> Mda
> Za System.map si prav
> Predi vreme imashe diskusia na tazi tema.
> System.map __NE__ okazva nikakvo vlianie na symvolite eksportirani ot
> kernel-a ili moduli.
>
> Ne se kosi da si pravish eksperimenti s CONFIG_MOD_VERSIONS.
> Shte se opitam tuk nakratko da poiasnia deistvieto mu.
> Ako si compilirash kernel s CONFIG_MOD_VERSIONS
> za vsi4ki exportirani simvoli shte bydat generirani t.n. VERSIONED symbols.
> Naprimer:
> register_chrdev_R44f5bc97
naprimer ot sourceto na nvidia kernel modula
grep -r register_chrdev ./
./nv.c: rc = register_chrdev(nv_major, "nvidia", &nv_fops);
./nv.c: unregister_chrdev(nv_major, "nvidia");
./nv.c: if ((rc = unregister_chrdev(nv_major, "nvidia")) < 0)
Binary file ./nv.o matches
Binary file ./Module-linux matches
Binary file ./NVdriver matches
imeto na kernel modula e NVdirver.
za sravneniqto nqma da postvam ot 2.4.10ext3patched source-to tuka :)
> e VERSIONED imeto na exportnata f-iq register_chardev()
> Dobavkata kym imeto e md5sum, koito se formira ot parametrite na
> exportiraniq symbol. Ako naprimer funciata chardev priema kato edinstven
> parametyr ukazatel kym struktura, koiato v dve razli4ni versii na kernel-a
> ima definicii koito ne sa ekvivalentni syotvetno i VERSIONED imeto na
> exportiranata f-iq register_chardev() shte e razli4no.( Vij po dolu ).
> VERSIONED imeto e dobra garancia za tova, 4e niama da se opitvash da
> polzvash exportirana funkcia koiato v deistvitelnost ne priema takiva
> paramemtri kakvito si misli 4e triabva da izpolzva modula koito izvikva
> vyprosnata f-iq. Izpolzvaneto na binary modul koito ne se insmod-va zaradi
> unresolved VERSIONED symbols ne e e jelatelno. Osven ako si siguren 4e
> izpolzvaneto na vyprosnite strukturi s promeneni definicii e __safe__.
> Obi4aina praktika e ot definiciite na strukturite da ne se premahvat
> "nenujnite" poleta, a
> ako se dobaviat novi takiva te da sa v kraia na definiciata. Taka, 4e
> binary modul compiliran da polzva struktura
> struct X {
> type field1
> type field2
> .......
> type fieldn
> }
> moje spokoino da si raboti sys danni s tip
> structX{
> type field1
> type field2
> ..............
> type fieldn
> type field_new_field;
> type field_new_field2;
> }
>
Blagodarq za obqsnenieto, sega mi svetna pone malko otnosno tezi stranni
simvoli sled funkciqta, znaeh 4e ima nqkakva zastrahovka otnosno loadvaneto
na kompilirani za drug kernel moduli, no ne znaeh 4e tova e mehanizma na
realizaciq. BTM insmod s force v moq slu4aj ne pomagashe ... a i kernela ne
kazvashe 4e tezi moduli sa compiled za druga versiq na kernala. To drugata
versiq v slu4aq e 4e e patched s ext3 ... ama qvno patcha smenq nqkoj ot
parametrite na funkcij polzvani ot nvidia modula , raz4itam 4e e _safe_ .
> Ako kernel-a ti ne e kompiliran s CONFIG_MOD_VERSIONS se polzvat
> normalnite imena na symbolite. Oba4e ako modul kompiliran za dadena versia
> niama da se __insmod__ -ne za kernel s druga versia. ( V tvoia sl. NVidia
> drivera niama da mojesh da go polzvash s linux-2.4.11 naprimer a shte
> triabva da si namerish binary modul-a NVidia compiliran za 2.4.11 ).
driverite na nvidia idvat s source (ima i banaries, licence e malko
ograni4avasht oba4e de, ama ne pre4i mnogo ;) , i ne mi dava warrnings ili
err pri compilaciqta za kojto i da e kernel , dava samo unresolved symbols
pri modprobe/insmod ... ama raz4itam 4e e _safe_ :) .
btw machinata ba4ka ve4e 3-ti den s patchnatiq s ext3 i "CONFIG_MODVERSIONS
is not set" na volume na max, sprqh i toka s load, ama si4ko e OK, nqma
neobi4ajno povedenie.
P.S. basi mamata, i az si mislq 4e pone malko poznavam kernela , tc tc tc :)
10x again za free kernel lesson-a :) , vse pak pishesh driver za kernela.
--
Greets,
fr33zb1
===========================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers)
http://www.linux-bulgaria.org/ Hosted by Internet Group Ltd. - Stara Zagora
