Date: Mon, 23 Jun 1997 10:31:43 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: un_x@anchorage.net (Steve Howe) Cc: hackers@FreeBSD.ORG Subject: Re: direct access Message-ID: <199706231731.KAA00897@phaeton.artisoft.com> 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
> > > 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?
If you open /dev/io, you are then permitted to read and write
port addresses via {in|out}{b|w} instructions (use the macros
in the system header files for best results).
> 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.
You will need to open the /dev/vga device and mmap() it as a
file. As long as you are talking about directly writing
video RAM, and not INT 10 I/O, there's not a problem. The
INT 10 I/O is problematic, since many card manufacturers
too cheap to spring for dual ported (video) RAM want to
avoid strobing except during the retrace interval (to
eliminate "sparklies"). They do this by waiting for the
vertical retrace before proceeding with the INT 10 operation.
Because the INT 10 operation is time sensitive, they disable
other interrupts while they are doing this. Like, oh, say
the serial port which your PPP connection is on or the net
card your LAN connection is on or the floppy controller
that your non-FIFO protected QIC-40/80 tape is on, etc..
User generation of hardware interrupts is not permitted.
> as far as ram goes, i like to watch whats going on
> in physical ram to learn about systems.
You would be much happier with opening /dev/kmem, /dev/mem,
or /proc for the process you want to watch. A virtual
memory system can be considered to be multiple machines
running on the same hardware. The memory mappings are
by kernel and per process page tables which references the
virtual address space for the "machine". This, in turn,
is backed by physical pages in 4k chunks. Looking at
the physical pages is not going to give you a lot of
information, but looking at the virtual pages can be
quite informative for a given process. Many debuggers
on UNIX work through /proc.
> as far as drives go, file recovery - searching for deleted HD data,
> which i desperatley need,
Use "fsdb". Be warned that if you lose data on a drive
while you are actively writing files, even temp files, on
the same drive, that data is probably gone forever. In
addition, the FS layout is significantly different than
the FS layout for DOS. Because of this, most DOS tools
will be completely useless.
> as far as ports go, the code i'd like to port, detects and
> debugs certain devices.
This is a mistake if the machine has a PNP BIOS, or if the
devices are EISA, PCI, or MCA (ie: anything other than ISA
and those VESA devices which don't pretend they are EISA
devices).
You would be better off looking at the kernel probe data
structures, which contain this information (this assumes
that you use a "PNP-aware" kernel, or apply Sujal Patel's
PNP patches to yyour kernel).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706231731.KAA00897>