Date: Mon, 23 Jun 1997 02:36:37 -0800 (AKDT) From: Steve Howe <un_x@anchorage.net> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: freebsd-hackers <hackers@FreeBSD.ORG> Subject: Re: direct access Message-ID: <Pine.BSF.3.95q.970623002024.21409A-100000@aak.anchorage.net> In-Reply-To: <19970623100142.PK61527@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
"man io" - I/O privilege file The special file /dev/io is a controlled security hole that allows a pro- cess to gain I/O privileges (which are normally reserved for kernel- internal code). Any process that holds a file descriptor on /dev/io open will get its IOPL bits in the flag register set, thus allowing it to per- form direct I/O operations. This can be useful in order to write user- land programs that handle some hardware directly. The entire access control is handled by the file access permissions of /dev/io, so care should be taken in granting rights for this device. Note that even read/only access will grant the full I/O privileges. > > what's /dev/io all about? > RTFM... Did you ever try ``man io'', to the least? Apparently not. yes - but i didn't learn too much. can't say i learned enough to do anything with it. thanks though. i searched through the maillist archives, handbook, and faq, and didn't see much on c-programming i/o basics. i'm sure it doesn't take an einstein, but of course, i'm basing that on my limited knowledge. i've only been programming since 1981, not 1945, and i only know about 10 languages, not 100, and i've only been hacking FBSD for 2 years ... not 20. > > for example, i need char i/o to the vga screen. > No, you don't need it. You _think_ you need it. This makes your > application totally unportable, and people will really hate you for > this crap then. (You will even hate yourself two years later, believe how do you know i don't need it? i have special needs with embedded hardware FreeBSD doesn't support, and that i don't expect FreeBSD to support, and i'm sure i'm not alone. and i don't have time to re-write everything from the ground up right now. how do you know my timelines, my priorities, or if i will even give it out for other people to use, or if i will ever use it on non-pc based computers? > portable back to a CP/M machine connected via Kermit emulating an ADM3a > or VT52 terminal. If your terminal supports colors, you can also get this is the 90's - i don't care about adm3a/vt52's. i care about BSD's/Linux/POSIX and hardware i/o testing. and i don't want to be 90 before i port some 'drivers' to use for myself. and i don't want my trees of development to split too far between my embedded systems code and UN*X code. it will become too much to maintain for now. for example, i read the slang lib may be faster than ncurses... but i can't find any docs on slang i/o. maybe there's even faster alternatives? > colors. You read the character back from a backup buffer curses > maintains inside the program's address space. i can't find any info on this backup buffer in ncurses. i tried "apropos buf", "apropos back", ... i tried the manpages on ncurses stuff, couldn't find anything. i can find what a current pair color is. and curses.h doesn't compile well with c++. besides, from what i read, curses is out of date. > > > > unsigned char * p = (unsigned char *)0x000b8000; > > > You cannot directly access the physical address 0x000b8000. > > is that an absolute? no peek-ing or poke-ing ... at all? > inside the kernel address space), thus you always need a mapping. The > kernel provides for mappings in the ``ISA IO memory hole'', but for > anything else, you're responsible yourself. so - i just match the virtual addresses to physical, by reading this map, then i turn off some flag, and i can read ram ... > > as far as ram goes, i like to watch whats going on > > in physical ram to learn about systems. > Impossible. On a typical 16 MB system, there are 4096 different > physical pages of memory, which can be arbitrarily mapped into the > virtual address spaces. So, your address 0x0000 of your program might > be unmapped, address 0x1000 is mapped to physical address 0x133000, > address 0x2000 is mapped to 0x57000, and so on. What would it give > you to display physical memory? Nothing, i'd say. what would it give us to explore anything? maybe unique things exist that we all don't know about. > > as far as drives go, file recovery - searching for deleted HD data, > > which i desperately need, > Impossible. That's not DOS, our filesystems aren't so simple as a > lame FAT file system. Your data blocks that once belonged to a file > might be scattered throughout the entireq partition, and once you've > lost the block pointers, you stand no chance to reassemble them into > one file (at least, not realistically). no it's not, my files are small, i had few small messages on a drive with keywords, and the drive hasn't been written to since i disconnected it minutes after the deletion. one of many uses for a block editor. > > as far as ports go, the code i'd like to port, detects and > > debugs certain devices. > Leave this to kernel code. Write LKMs with device drivers. i would like to use FreeBSD for embedded systems, and the kernel doesn't support devices i need to use. maybe lkm's -are- what i need? > soon make it obvious to you that all your questions were no-brainers > from the beginning. Sorry for sounding harsh. sorry for being a so stupid. i do appreciate your knowledge. > cheers, J"org ------------------------------------------------- FingerPrint BA09868C 1B995204 58410FD3 A5E7B2DA http://www.geocities.com/siliconvalley/way/7747 -------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970623002024.21409A-100000>