Nem, nem a warning miatt, hanem azert, mert kernel header userspace abban a legritkabb esetben fog mukodni, mert mindenfele egyeb magia szuksegeltetnek hozza, ami nem adott.
í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.
Kernelbol igen. Userspace a kernel altal biztositott felulet van erre. Nem hiszem, hogy az olyan lassu lenne - eleve a parhuzamos port nem egy gyors dolog. Ha azt userspacebol nem tudod full kihajtani akar 10 layeren at, akkor valoszinuleg egy 386oson vagy.
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.
/dev/lp0 nemjó, lassú.
Az I/O portok elérése pedig már anno is bonyolultnak tűnt, pedig akkor még jobban benne voltam kicsit.
-- Discover It - Have a lot of fun!
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 :).
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.
Számomra meg az hátborzongató, ha nem tudom elérni a fizikai réteget elemi utasítások szintjén. Például a méréstechnikában ez teszi használhatóvá a linuxot.
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.
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
Hozzászólások
http://kernelnewbies.org/KernelHeaders - ahogy a hibauzenet is mondja.
(Egyebkent mit akarsz forgatni? Mert attol is erosen fugg a valasz :P)
--
|8]
De az csak egy warning... Vagy attól hányja ezt a syntax errort is?
--
Discover It - Have a lot of fun!
Nem, nem a warning miatt, hanem azert, mert kernel header userspace abban a legritkabb esetben fog mukodni, mert mindenfele egyeb magia szuksegeltetnek hozza, ami nem adott.
--
|8]
Hát vagy 4 éve, mikor utoljára fordítottam, akkor ez még így ment :)
--
Discover It - Have a lot of fun!
Veletlenul :P
--
|8]
Nem, rendszeresen :)
--
Discover It - Have a lot of fun!
í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.
Benne van a pastelt uzenetben, hogy nem /usr/include/asm/io.h -rol van szo, hanem valami /usr/src alatt levo kernel forrasbelirol.
--
|8]
a kérdés rávezető-jellegű, pontosan az a kérdés, hogy miért. :)
Mert ott nincs olyan :).
--
Discover It - Have a lot of fun!
gcc -I/usr/src/linux/arch/x86/include/ -I/usr/src/linux/include/ -I./ -o oravez oravez.c
--
Discover It - Have a lot of fun!
ez egy kernel modul akarna lenni?
Nem, egy saját kis cucc, LPT porta írna outb-vel.
De mindegy, csinálsz egy a.c-t:
És már erre behányja ezt.
--
Discover It - Have a lot of fun!
Ezesetben a valasz az, hogy userspacebe ne akarj kernel headert includeolni, mert nem supportalt, sot.
Userspacebe minek neked asm/io.h egyebkent?
--
|8]
Mert azzal tudok az LPT portra írni...
--
Discover It - Have a lot of fun!
Kernelbol igen. Userspace a kernel altal biztositott felulet van erre. Nem hiszem, hogy az olyan lassu lenne - eleve a parhuzamos port nem egy gyors dolog. Ha azt userspacebol nem tudod full kihajtani akar 10 layeren at, akkor valoszinuleg egy 386oson vagy.
--
|8]
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.
/dev/lp0 nemjó, lassú.
Az I/O portok elérése pedig már anno is bonyolultnak tűnt, pedig akkor még jobban benne voltam kicsit.
--
Discover It - Have a lot of fun!
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!
Eléri.
Nekem a sys/io.h kell hozzá és a port elérés előtt
ki kell adni egy ioperm() utasítást.
> Sol omnibus lucet.
Így van.
--
Discover It - Have a lot of fun!
Nos, bevallom, tényleg nem találkoztam ezzel az orbitális hackkel még eddig.
Tegyük hozzá, hogy ez az IOPL emeléses megoldás SZVSZ életveszélyes, nem mintha a /dev/port nem lenne majdnem pont ugyanennyire az.
Például a speakerrel authentikusan tülkölni csak így lehet.
> Sol omnibus lucet.
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 asm/io viszont kernel header.
--
|8]
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.
Számomra meg az hátborzongató, ha nem tudom elérni a fizikai réteget elemi utasítások szintjén. Például a méréstechnikában ez teszi használhatóvá a linuxot.
> Sol omnibus lucet.
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]
Ki mivel szop, azt kerüli később.
> Sol omnibus lucet.
Próbáld ki a /dev/ports -ot.
http://hup.hu/node/56999#comment-585036
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".
Megoldottam, így talán még jobb is: http://hup.hu/node/102073#comment-1266994
--
Discover It - Have a lot of fun!
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
Pontosan így csinálta a régi kód :)
--
Discover It - Have a lot of fun!
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.
--
-1, több különböző distro alatt is évekig jól működött nekem (is).
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.
--
Én a /dev/rtc-vel jártam egyszer így.
> Sol omnibus lucet.
Ehhez sys/io.h is eleg, nem kell kernel header, es userspacebol megy a dolog. Ahogy az fentebb is emlitve lett mar tobbszor is. :P
--
|8]