Subject: Re: An unusual Scheme project
From: rpw3@rpw3.org (Rob Warnock)
Date: Sun, 02 Mar 2003 04:06:01 -0600
Newsgroups: comp.lang.scheme
Message-ID: <s1idnZr2fMQUSvyjXTWc-w@speakeasy.net>
Harri Haataja <harri.haataja@cs.helsinki.fi> wrote:
+---------------
| Rob Warnock wrote:
| > William Bland <news@abstractnonsense.com> wrote:
| > +---------------
| > | I agree for most things, but I can't see a kernel exploration system /
| > | rapid driver development platform working particularly well in user
| > | space ;-)
| > +---------------
| > 
| > Uh... It works *extremely* well, actually! And it's *much* easier to do
| > debugging when the code-under-test is in user mode! ...
| > Peeking (r32) and poking (w32) at those addresses, one could
| > put the device through all of its paces ...
| 
| Now this here looks insanely interesting. But I'm afraid I still have a
| long way to go before I can really appreciate that or even less do
| something like that.
+---------------

Just go for it! It's really easy to get started:

1. Run some O/S on your machine that allows you to "mmap()" PCI bus space
   into user mode (possibly requiring superuser privilege, but hey, it's
   *your* machine, right?).  Note: Some OSs don't provide "mmap()" access
   though device special files per se, but *do* let you use some other
   access path, such as /dev/mem, /dev/kmem, or /dev/mmem, etc., to map
   at least the memory space of I/O busses into use process space.

2. Run some Scheme on your machine that allows you to dynamically link in
   libraries at runtime (almost any of the popular ones, at least if the
   answer to #1 was some flavor of Unix or Linux), or use one of the ones
   that compile to C and let you link in stuff statically.

3. Find *some* card or chip whose memory register layout you know.
   (Older ones are sometimes easier to find documentation for.)

4. Hack up a peek/poke/mmap/etc. library for your Scheme, map in that
   card (or chip), and start poking around to see what you can see.

WARNING! It is *very* likely that you will crash the host several times
while getting this all to work. DO NOT USE A CRITICAL OR SHARED COMPUTER!

+---------------
| One of the particularly nice things in scheme is that if you can load
| your code and get a repl there, you can prod at it and rewrite parts
| on the fly...
+---------------

At this point I must confess that I before getting into Scheme, I had
been (in late 1994) using Tcl as my "REPL", since you can also do the
"dlopen()" hack easily enough in Tcl. Interaction with that version
looked a bit like this [modulo memory errors -- mine!]:

	puts "Loading libUmHw.so"
        puts [dlopen libUmHw.so init UmHw_Init]

        global mem
        set mem [malloc 100]
        d $mem 64			# d == a hex dump subr
	p $mem 1234			# p == poke
	p [expr $mem+4] 5678		# needed to use word addressing
        d $mem 64			# look at the changes
	set bpath /hw/module/1/slot/io3/pci/controller
	set brj [mmap $bpath 0 0x1000000 1]	# map in the Bridge

...and so on, analogously to the Scheme example I showed before.

But by early '95, I had gotten really tired of Tcl not having [in those
days] any datatypes other than string, and all the horrid conversions
back & forth from int to string that were needed to set up a simple
increment-a-register 'scope loop. (You know, polling a hardware location
with a PIO read or write loop so you can stick an oscilloscope probe on
some part of the circuitry to see what's going wrong.)

So I switched to Scheme [as shown before]. *Much* nicer...  ;-}  ;-}

Scheme versions of this toolbox (with slight variations for each
project, of course) were used for a half-dozen bringups of new
networking hardware (e.g., FDDI, Ethernet, ATM, HIPPI) between
1995 and 1998, with great success. (IMHO.)


-Rob

p.s. Doing "hardware stuff" in user mode isn't at all new. You could
already do it quite easily on the PDP-10 back circa 1970. TOPS-10
even had a whole bunch of support for doing *real-time* programming
in user mode!!

The idea of using a language platform that provided a built-in REPL
for hardware stuff wasn't new then, either. People were doing all kinds
of laboratory and process-control stuff on DEC platforms (PDP-11, PDP-8,
LINC-8/12) in the FOCAL interactive language (a descendent of AID/JOSS),
which had a BASIC-like REPL (by which I mean a built-in line editor),
so after I did a port of Doug Wrege's FOCAL/F from the PDP-8 to the
PDP-10 in early 1972, guess what...?  ;-}  ;-}

-----
Rob Warnock, PP-ASEL-IA		<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607