Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!taco!mcnc!borg!oscar!tell
From: tell@oscar.cs.unc.edu (Stephen Tell)
Newsgroups: comp.lang.perl
Subject: Re: anyone gotten mmap to work w/ perl?
Message-ID: <3297@borg.cs.unc.edu>
Date: 18 Apr 91 21:20:09 GMT
References: <28046072.4CFC@tct.com> <129281@uunet.UU.NET> <1991Apr17.235656.10193@NCoast.ORG>
Sender: news@cs.unc.edu
Organization: University of North Carolina, Chapel Hill
Lines: 34

In article <1991Apr17.235656.10193@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA) writes:
>As quoted from <129281@uunet.UU.NET> by rbj@uunet.UU.NET (Root Boy Jim):

>Were I designing it, I'd arrange for strings (well, symbol table entries) to
>contain the "allocate" and "extend" function pointers for the strings.

Hmmm, sounds like virtual functions to me!
Of course, we should be able to use this in our perl programs (perl++? :-)
...
>If there were a
>way to map device driver registers into user-mode code, this would also be a
>good application.)

You can do just that on SunOS - we do it all the time.   Your board
has to respond to user-mode accesses;  different address modifiers on
the VMEbus.
No problem when you're designing your own boards.  Probably just a PAL
change on many others if you can get the vendor to cooperate

It is much easier to write "drivers" that live in user mode this way.
The kernel driver is almost identical for different projects; it only
has to support open(), mmap(), and close().  It gets to do a little
work if you need interupts.

I'd love to be able to write drivers for our projects in perl.

>++Brandon

Steve
-- 
Steve Tell       tell@cs.unc.edu    H: +1 919 968 1792   #5L Estes Park apts
CS Grad Student, UNC Chapel Hill.   W: +1 919 962 1845   Carrboro NC 27510
Duke Blue Devils:  1991 NCAA Basketball National Champions! We're Number 1 !!
UNLV 90-91 record:  "34 and DUKE."