minimal halokartya driver keszitese

Egyéb: Assembly, Ada...

Assemblyben irnek egy minimalis meretu es tudasu halokartya drivert.Olvastam ilyen temaju cikkeket es lattam a linux forrasban a drivert.
En valami sokkal egyszerubbet irnek. Egyetlen tipusra, raw packetekhez. Ehhez kellene alkalmas dokumentacio es/vagy minimal peldakodok. Tudtok ajanlani szakkonyvet/eloadasjegyzetet/irc csatornat?
Koszonom.

( wachag | 2015. 01. 07., sze – 08:33 )

Van-e oprendszer alatta?
Milyen chiphez?

+1

Tényleg, minek szívni assembly-vel, ha ott van a C? Noha ismerem egy kicsit az x86/x64 assembly, eszem ágába se jutna ebben kódolni drivert. Főleg nem az posztoló helyében úgy, hogy még semmi tapasztalata nincs a témában.

Nekem már volt szerencsém x86/x64 architektúrán drivert fejleszteni, és ez alapján mindenképpen lebeszélnélek az assembly-ről. Sőt, a fejlesztés során a kis lépések elvét javasolnám figyalmedbe: először legyen egy működő változatod például C-ben. Ha a tesztek során nem elegendő a teljesítmény (és mindenképpen szoftveresen akarod javítani), profilozni kell a kódot/a rendszert, megállapítva, hogy éppen hol a szűk keresztmetszet. Ha a te kódodban, akkor a kritikus részt (és csak azt) írd át assembly-be.

( tovis v | 2015. 01. 07., sze – 13:50 )

Nem tudom hogy nem-e ütközik a HUP etikettbe, de a cím már szinte vészesen azonos az én kérdésemmel, kérlek bocsássátok meg.
Nézegetem a neten mivel és hogyan is lehet Linux alá device drivert írni.
A legfrissebb könyvnek ezen a téren a "Linux device drivers" 3 -ik kiadása tűnik, de ha jól értem ez is a 2.6 -os kernelre alapozódik és most valahol a 3.1x -nél tartunk. Elég ez a régi könyv egy driver megírásához a mai kernelhez?
Ha devise driver akkor óhatatlanul felmerül bennem az assembly használata a driveren belül, vajon ez lehetséges? Ha igen, akkor az I386 és továbbiakhoz vajon csak azt az szörnyűnek tűnő AT&T szintaxisú izét lehet használni? Külső, mondjuk nasm -al fordított assembly routint nem?
Az igazság az hogy először ártom magam ilyen szinten a Linux -ba, nincs tapasztalat és az eléggé elavult windows -os ismeretek után elég ijesztő kásahegynek tűnik. Szerencsére példa programokban nincs hiány :))

* Én egy indián vagyok. Minden indián hazudik.

Robert Love könyve frissebb amúgy.
Követelmény a kerneles dolgokhoz: userspace ismerete, párhuzamos és eseményvezérelt programozásban rutin. Utána egyszerű driverek írása relatíve egyszerű (bár a kernel dokumentációja C nyelven íródott...), de persze rengeteg szívás lehet.
Meglepő módon már a debug is túllépett a printk-záson, elég sok lehetőség van.

A Robert Love az a kernel fejlesztésről szóló könyv - most húztam le a harmadik kiadást :)
Ez is a 2.6 kernelre alapul, viszont 2010? Mindenesetre minden segítséget köszönök!
Ha már olyanra leltem aki konyít a témához megkérdezném, hogy létezik a "user space device driver" is - legalábbis mint fogalom. Kicsit fából vaskarika, de pl. fejlesztéshez jónak tűnik. Az első ami megfogalmazódik, hogy tud-e direkt IO kezelést és vajon tud-e interruptot kezelni? Ha ezeket tudja, és nem kell nagy késleltetésekkel számolnom a kiszolgálásban akkor lehet ez is elég nekem.
Miért kell elfelejteni az assemblert? A készítendő driver sosem lesz a main stream része, csak egy antik furcsaság, egy "stand alone complex". Elvileg a nasm -al írt kód linkelhető a gcc -vel.

* Én egy indián vagyok. Minden indián hazudik.

Ha a /dev/mem -et bemmapeled, akkor a memory mapped IO eszközökkel kb. azt teszel, amit nem szégyelsz. Nem néztem meg túl mélyen, de mintha az Android driverek is valami ilyet csinálnának, ezzel kerülve meg a nem GPL kernel modulok maceráit.
Elvileg megszakítást is tudsz user space-ből kezelni valahogy, sosem próbáltam.

Nem éri meg az assembly. Van egy varázsa, de driverhez ma már csak nagyon alacsony szinten: platform init, boot. IMHO.
Mit nyernél vele?

Én még így se tenném.
De ha mindenképp így szeretnéd, akkor relatíve egyszerű, assemblertől függetlenül: tárgykódot fordítasz, és azt linkeled a programhoz. Persze a hívási konvenciókat betartod.

Viszont ha kernelbe rámolod, akkor szerintem mindenképp érdemes a kerneles szokásokat betartani. Ki tudja, mikor írsz olyat, ami bemenne a mainlineba. Érdemes az elejétől kezdve hozzászokni a dolgokhoz.