[megoldva] asm io.h hiba

C/C++

Miért hány nekem ilyen hibát a gcc egy sima include asm/io.h-ra?
http://paste.opensuse.org/87554779

  • 1970 megtekintés

( vl v | 2011. 04. 19., k – 21:11 )

írd már le, hogy milyen paraméterekkel próbálod futtatni a gcc-t...
nálam ugyanis nincs /usr/include/asm/io.h, szóval nem látom, hogy miért is kéne megtalálnia azt a header fájlt.

Az a probléma, hogy
- ha nem kernel modult akarsz fordítani, akkor semmi keresnivalód a /usr/src/linux alatti cuccok között
- azt a headert hiába is gyömöszölnéd, hogy leforduljon, a benne levő meghívható függvények csak a kernelen belül érhetőek el
- linux alatt az, amit szeretnél csinálni, az így nem megy, egy mezei program így nem érheti el az LPT portot.

4 lehetőséged van:
- a kernel által az LPT port elérésére biztosított felületet használod a port bizgetésére (/dev/lp0 device)
- a kernel által az I/O portok direkt elérésére biztosított felületet használod a port bizgetésére (/dev/port device)
- a programodnak csinálsz a kernelben egy új felületet (-> kernel modul írása), ami biztosít olyan felületet, amin keresztül meg tudod csinálni, amit szeretnél
- a programodat teljesen a kernelben futtatod (-> kernel modul írása)
Ez fentről lefelé csökkenő mértékben javasolt, és növekvő tudásszintet igényel.

Rootként fut a cucc, úgy eléri... Vagyis, eddig elérte.

Nem érte el sose.
Linux alatt _nem_ tudod a portokat elérni direkben assembly port in/out utasításokkal, csak kernel modulból.

Persze simán lehet írni egy library-t, ami az általam említett 2. megoldás (/dev/port) segítségével ezt transzparens módon megteszi, biztos vannak is, akik ezt már megírták.
De a /usr/src/linux/*/asm/io.h _nem_ az a header fájl, ami egy ilyen libraryhoz megfelelő header fájl lehetne.

/dev/lp0 nemjó, lassú.

Akkor hajrá, lehet írni kernel modult. Persze ahhoz azért érteni kell...

Hát pedig hidd el, hogy elérte, működött, tudok forrást és binárist is adni, csak a hardvert nem... De ha tényleg érdekel, ledekkel megnézheted. Vagy elmondom a "bonyolult" kapcsolását, és megépítheted :).

Azóta kész van egyébként, találtam egy jóságot: http://parapin.sourceforge.net/doc/parapin.html
--
Discover It - Have a lot of fun!

Ki beszélt itt IOPL emelésről?

Egyébként a hozzászólónak: én is csináltam ilyen proggit, ami userspace-ből kezelt lpt portokat. Arra emlékeztem, hogy inb/outb és ioperm, de most előkerestem a forrást, és én is asm/io.h-t használtam. Fordult gentoo, ubuntu 8.04, ubuntu 10.10 és tinycore alatt is. Igaz, hogy bunubtu alatt oda kellett másolni az /usr/include/asm/io.h-t, mert nem volt, de aztán ment, mint a karikacsapás. Az nem igaz, hogy kernel fgv-t hívogat, az inb/outb ioperm kifejezetten userpsace fgv-k.

Az iopermes megoldás pont egy hangyafingnyival biztonságosabb... ugyan CLI-t nem tud kiadni a kedves program, ellenben simán szétprogramozza a 8259A-t, aztán helló van mindenkinek a gépen.
Alapvetően hátborzongató az a gondolat, hogy egy userspace program random I/O portra kiírhat bármit.

Step 1) Megnez HW dokumentacio
Step 2) Ir pici kernel modul, ami userspacebol egyszeruen kezelhetove teszi
Step 3) ???
Step 4) Hatradol & elvezi

Meglepoen jol tud mukodni a dolog. A magam reszerol nem latom szukseget annak, hogy gyakorlatilag drivert lehessen irni userspace-bol... ha ez kell, akkor miert nem hasznal mikro-kernel alapu OS-t az ember? Szoval ha adott egy device amit meg kell hajtani, arra valo a kernel. Kiexportaljuk userspacebe egy magasabb szintu API-t, es mindenki jol jar: a driver a kernelben marad, a userspace meg tudja hasznalni, es nem kell neki kozvetlen HW eleres.

Tapasztalatom szerint nem egy nagy ordongosseg, es kevesebb szopas van vele, mintha pure userspace alapon probalja az ember megoldani a problemat. Persze ha nincs normalis dokumentacio, akkor megbukik az egesz, de az mar egy masik tortenet.

--
|8]

( uid_2716 | 2011. 04. 19., k – 22:44 )

outb(), ioperm(), iopl().

Tehát igenis írhatsz userspace-ből portra outb()-vel, és a szükséges header a <sys/io.h>.

E rejtett tanokhoz az alábbi mágikus ráolvasás vezetett el: "man outb".

végre egy értelmes ember, <3 hupszagértők
Mellesleg már régebben leírtam a megfejtést, igaz gpio kapcsán, de az elv ugyanaz mint lpt esetében.
Szóval utókornak megőrizve ha nem gpio-ra, hanem lpt-re keresnének, példaprogrammal:
http://hup.hu/node/98757#comment-1214981

Igen, csak te eroltetted az asm/io.h -t, amit pedig userspace-bol nem tamogatott hasznalni, sosem volt az. Elkepzelheto, hogy mukodik, de nem tamogatott. Eleve, userspace program gcc hivasaiban semmi keresnivaloja az -I/usr/src/linux/include kapcsolonak. Ha legkozelebb ilyet latsz, kezdj gyanakodni, hogy szopasoknak nezel elebe.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Egy dolog, hogy valami mukodik, egy masik, hogy tamogatott. Nekem voltak olyan tapasztalataim, hogy egy programom hirtelen elkezdett nem mukodni, mert nem tamogatott API-t kezdtem hasznalni. Volt meglepodes, utanaolvasas, facepalm, javitas.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal