Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Jun 1997 23:11:59 -0700
From:      John-Mark Gurney <jmg@hydrogen.nike.efn.org>
To:        Steve Howe <un_x@anchorage.net>
Cc:        freebsd-hackers <hackers@FreeBSD.ORG>
Subject:   Re: direct access
Message-ID:  <19970622231159.65374@hydrogen.nike.efn.org>
In-Reply-To: <Pine.BSF.3.95q.970622201506.17548B-100000@aak.anchorage.net>; from Steve Howe on Sun, Jun 22, 1997 at 09:12:17PM -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
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970622231159.65374>