Date: Mon, 23 Jun 1997 15:38:57 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: un_x@anchorage.net (Steve Howe) Cc: hackers@FreeBSD.ORG Subject: Re: direct access Message-ID: <199706230608.PAA16120@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.BSF.3.95q.970622201506.17548B-100000@aak.anchorage.net> from Steve Howe at "Jun 22, 97 09:12:17 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Howe stands accused of saying: > > > i wanted to port a hex/block editor from DOS. > > > This is not a very useful thing to do. There are several quite good hex > > editors already in the ports collection. I use 'beav' more often than > > hehe! it's useful to me, hehe, it's mine! and i like it! :) Well, that's as maybe. The point I'm making is that there's not a lot that makes sense to "edit" in that fashion. > > > it can read/write 1 RAM blocks > > > 2 Port Addresses > > > 3 Hard/Floppy Drives > > > 4 Files > > > A user process on any Unix system cannot easily edit 1, 2 or 3. > > that's what i'm finding out. but i want all the direct access and speed > i can get. You are still thinking like a (bad) DOS programmer. You aren't a demo coder by any chance are you? Direct access means you have to do all the work. Speed often comes from carefully layered and designed methods of access, and rarely from "raw metal" work except in the case of bogus environments. You will almost always get better performance by using the OS services provided than by trying to talk to the hardware yourself. On top of that is the issue of access control; what if you try to run two of your spiffo programs at the same time? Things are going to get very confused. > how low-level can i get? i'd like the "driver" level. > is there specific documentation (other than source) about it? So write a driver 8). There's nothing better than the source to learn how to write drivers; look for another one that's similar to what you want to do. In reality, I think you want to be one or more layers above that. > what's /dev/io all about? It's a disgusting hack to allow user-space programs access to I/O ports. Avoid it at all costs. Using user-space I/O to talk to a device that's also being talked to by the OS will usually result in a hardware lockup or crash. > i have all the libraries i need for coding, all i need is a few > simple low-level i/o routines moved to UN*X, namely > VGA-i/o, RAM-i/o, PORT-i/o, and DISK-i/o. Why? All of these are handled by the operating system, and at very different levels. Most of the time, the DOS routines you have will not be adequate for the unix environment anyway. > for example, i need char i/o to the vga screen. > i need to put a colored char on the screen at a fixed position, > and read the color and char at a position. thanks to r.nordier, > i got ncurses going, but it is too slow - i have to "refresh" > too often. i want access to the lowest level. If ncurses is "too slow", then you are not using it properly. You cannot think of a terminal as a VGA screen; what if I telnet into your system and want to run the program? There is no "VGA memory" for my telnet session, but ncurses knows that and will compensate; if your application is well-written, the fact that I am on a monochrome terminal won't affect the usability of the application either. > my code already exixt, except at the lowest level of i/o. > i have alot of hardware diagnostics i would like to > run on my freebsd boxes. Depending on the nature of your diagnostics, they are unlikely to work terribly well (or at all) at the same time that a real operating system is running. You might want to look at adding your diagnostics as components of the kernel or drivers that relate to the hardware in question however. > > > 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? How can you access an address that doesn't exist? > > What is a "device editor"? > > hehe. something that allows you to perform > visual i/o on any device in a system - ? :) How do you plan to coordinate your "visual I/O" with the "nonvisual" I/O being performed by arbitrary other system functions? > > You don't want to edit display memory; that will make the console > > driver unhappy. With the appropriate level of privilege you can use a > > binary editor on the disk devices in /dev and thus edit raw disk data. > > "editing" device ports doesn't seem to be terribly useful to me. > > as far as ram goes, i like to watch whats going on > in physical ram to learn about systems. This is an approach suitable for stupid operating systems like DOS and Windows where you don't have access to the source. If you want to learn about what's going on, attach a debugger to the kernel and look at both the source _and_ the data. > as far as drives go, file recovery - searching for deleted HD data, > which i desperatley need, Hah. 'fsdb' is your friend here. Don't expect to be able to cruise your disks looking for the magic bit to twiddle to "undlete" your files though. Aside from that, use something like beav on the disk devices, while they are unmounted. > as far as ports go, the code i'd like to port, detects and > debugs certain devices. This sounds like device-driver material. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706230608.PAA16120>