Date: Mon, 23 Jun 1997 10:01:42 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG (freebsd-hackers) Cc: un_x@anchorage.net (Steve Howe) Subject: Re: direct access Message-ID: <19970623100142.PK61527@uriah.heep.sax.de> In-Reply-To: <Pine.BSF.3.95q.970622201506.17548B-100000@aak.anchorage.net>; from Steve Howe on Jun 22, 1997 21:12:17 -0800 References: <199706230209.LAA14132@genesis.atrad.adelaide.edu.au> <Pine.BSF.3.95q.970622201506.17548B-100000@aak.anchorage.net>
next in thread | previous in thread | raw e-mail | index | archive | help
As Steve Howe wrote: > is there specific documentation (other than source) about it? > what's /dev/io all about? RTFM... Did you ever try ``man io'', to the least? Apparently not. > 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 me.) This kind of programming is done in Unix using curses. Well, the name's a symbol, you'll learn to curse, but at least, it's halfways 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 colors. You read the character back from a backup buffer curses maintains inside the program's address space. > > > 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? It is absolute. You're going into kernel debugging otherwise. There's some documentation about kernel debugging in the handbook, but with your current level of expertise, i would strongly recommend you staying away from this, until you've got at least a basic idea of how things are working. In a VM architectur, it's not sufficient to have a physical address, since you can only access virtual addresses (even 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. > 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. > as far as drives go, file recovery - searching for deleted HD data, > which i desperatley 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 entire partition, and once you've lost the block pointers, you stand no chance to reassemble them into one file (at least, not realistically). > 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. Still, you should really read some basic Unix literature. This will soon make it obvious to you that all your questions were no-brainers from the beginning. Sorry for sounding harsh. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970623100142.PK61527>