From owner-freebsd-hackers Sun Jun 22 23:12:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA14503 for hackers-outgoing; Sun, 22 Jun 1997 23:12:29 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA14497 for ; Sun, 22 Jun 1997 23:12:20 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.5/8.8.5) id XAA14963; Sun, 22 Jun 1997 23:12:00 -0700 (PDT) Message-ID: <19970622231159.65374@hydrogen.nike.efn.org> Date: Sun, 22 Jun 1997 23:11:59 -0700 From: John-Mark Gurney To: Steve Howe Cc: freebsd-hackers Subject: Re: direct access References: <199706230209.LAA14132@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Steve Howe on Sun, Jun 22, 1997 at 09:12:17PM -0800 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Howe scribbled this message on Jun 22: > > > 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. how low-level can i get? i'd like the "driver" level. > is there specific documentation (other than source) about it? > what's /dev/io all about? /dev/io controls wether you can do io read/writes on the system... you really don't want to do much low level, because FreeBSD is a multitasking os, so you never know when FreeBSD might use the device... > 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. > > 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. ok.. take a look at /usr/include/machine/console.h.. you need to make sure that you tell syscons you are going to be using the console, then you can open /dev/io or KDENABIO to do direct io port writes... and you can also mmap /dev/mem to get access to the frame buffer... > 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. well... it depends on what it's for... I'd becareful, you don't know what FreeBSD might do next.. :) > > > 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? well.. you can if you happen to have read/write access to /dev/mem... but if you do allow it, then programs can easily crack the system, so you have to be VERY careful... > > This virtual:physical mapping provides numerous benefits - processes > > can be moved around in memory with impunity simply by changing their > > mappings and copying the physical pages. The mapping process also > > allows for virtual addresses not to be mapped to a physical address, > > and when an access occurs, the kernel catches the trap and can take > > such steps as copying the page in from disk, or performing a mapping > > as required. > > > What is a "device editor"? > > hehe. something that allows you to perform > visual i/o on any device in a system - ? :) what visual i/o? > > 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. well.. you need to take a look at the source... it's the best place to look... > as far as drives go, file recovery - searching for deleted HD data, > which i desperatley need, well.. take a look at fsdb for more info... > as far as ports go, the code i'd like to port, detects and > debugs certain devices. good luck... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD