From owner-freebsd-hackers Mon Jun 23 05:25:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA01011 for hackers-outgoing; Mon, 23 Jun 1997 05:25:30 -0700 (PDT) Received: from aak.anchorage.net (ai-129.anchorage.net [207.14.72.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA01003 for ; Mon, 23 Jun 1997 05:25:25 -0700 (PDT) Received: from localhost (abc@localhost) by aak.anchorage.net (8.8.5/8.8.5) with SMTP id EAA23688 for ; Mon, 23 Jun 1997 04:14:05 -0800 (AKDT) X-Authentication-Warning: aak.anchorage.net: abc owned process doing -bs Date: Mon, 23 Jun 1997 04:14:04 -0800 (AKDT) From: Steve Howe X-Sender: abc@aak.anchorage.net To: freebsd-hackers Subject: Re: direct access In-Reply-To: <199706230608.PAA16120@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > 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 > 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. why is everyone telling me what i'm doing is no good for anything? either i'm crazy, or y'all know all possible uses of everything? hehe! i have code that lets me execute a function and will list all devices connected via PC ports, and that is highly desirable to me. maybe not to you, but to me it is. i don't have to open a PC to see what's in it. cuz sometimes my pc's are underground. so reading ports directly is important to me. > > > > it can read/write 1 RAM blocks > > > > 2 Port Addresses > > > > 3 Hard/Floppy Drives > > > > 4 Files > You are still thinking like a (bad) DOS programmer. You aren't a demo > coder by any chance are you? haha! no, but i have no need for flow control at 9600 bps in a 80x186 @ 8mhz with an 8250 in an "ethernet" type radio modem network. thanks though - i appreciate your valuable information. > 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. that's what i think i want - a bogus environment. whatever is simple & fast. in this application, i don't care about the code running on SunOS. i have specific apps, and they will run on low end PC systems, in highly controlled, 1 user 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. ok - then i guess i want OS services ... spiffo? hehe! this is not a problem, this stuff runs under very controlled, non-interactive environments. can't i create a lockfile like any other app that uses a device? > 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. i see a few generalizations about device drivers, but no solid instructions / rules for FreeBSD. > > 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. sounds good :). > How can you access an address that doesn't exist? by looking it up in the virtual/physical map. > How do you plan to coordinate your "visual I/O" with the "nonvisual" > I/O being performed by arbitrary other system functions? because i am dealing with unique hardware, a2d cards, parallel i/o cards, 8530's, that the kernel will know nothing about, and i need simple and effective ways of dealing with them. some people say UN*X is no good for embedded systems because drivers are such a hassle. maybe they are? i don't know. > > > "editing" device ports doesn't seem to be terribly useful to me. i'm sure there are some things you do that don't seem terribly useful to me either! :) > learn about what's going on, attach a debugger to the kernel and > look at both the source _and_ the data. thanks. > > 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. thanks. i've heard many others ask, but never saw an answer. i need something that will do a search on every block. > > as far as ports go, the code i'd like to port, detects and > > debugs certain devices. > This sounds like device-driver material. thanks. is there some instruction on them for FreeBSD? ------------------------------------------------- FingerPrint BA09868C 1B995204 58410FD3 A5E7B2DA http://www.geocities.com/siliconvalley/way/7747 -------------------------------------------------