lm@slovax.Eng.Sun.COM (Larry McVoy) (04/06/91)
The subject line says it all, I want to use mmap(2) from perl. I know I
can do:
sub mmap() {
local($fh, $len, $prot) = @_;
return (syscall(SYS_mmap(0, len, $prot, MAP_SHARED, fileno($fh), 0));
}
The problem is the return address. I need to fake out perl into
believing that the address is a string that is $len bytes long but
should not be freed. Is there an easy way of doing this short of
wacking on perl itself?
Feel free to post answers, I read comp.lang.perl...
Thanks in advance,
---
Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.comlwall@jpl-devvax.jpl.nasa.gov (Larry Wall) (04/09/91)
In article <535@appserv.Eng.Sun.COM> lm@sun.UUCP (Larry McVoy) writes:
:
: The subject line says it all, I want to use mmap(2) from perl. I know I
: can do:
:
: sub mmap() {
: local($fh, $len, $prot) = @_;
:
: return (syscall(SYS_mmap(0, len, $prot, MAP_SHARED, fileno($fh), 0));
: }
:
: The problem is the return address. I need to fake out perl into
: believing that the address is a string that is $len bytes long but
: should not be freed. Is there an easy way of doing this short of
: wacking on perl itself?
Mmm. Not that I can think of, though there might be some way of bootstrapping
an inplace modification of *name into a generalized poke routine. There
might also be something you can do with the 'p' pack/unpack specifier--I
haven't thought about that much.
Apart from that, you could use the usub hooks to link mmap into uperl.o as
a subroutine.
However, there's no way to guarantee that perl won't realloc a variable
unless you're careful about the operations you apply to it. Assigning
to a substr() of the same length is always safe. Some substitutions are
safe and some aren't. (The safe ones are the ones with a constant RHS
that is known to be shorter than the LHS.) read() and sysread() are safe
as long as you don't ask for more than the length of the string. Most
other operations are safe as long as the final length of the string is
less that what it thinks is currently allocated.
What you'd really kinda like is a way to mmap a particular variable, and
let Perl worry about it when it gets reallocated...
Larrychip@tct.com (Chip Salzenberg) (04/11/91)
According to lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall): >What you'd really kinda like is a way to mmap a particular variable, and >let Perl worry about it when it gets reallocated... If such a thing were done, we we would get shmat() for System V IPC almost for free. -- Brand X Industries Custodial, Refurbishing and Containment Service: When You Never, Ever Want To See It Again [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>
rbj@uunet.UU.NET (Root Boy Jim) (04/17/91)
In article <28046072.4CFC@tct.com> chip@tct.com (Chip Salzenberg) writes: >According to lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall): >>What you'd really kinda like is a way to mmap a particular variable, and >>let Perl worry about it when it gets reallocated... > >If such a thing were done, we we would get shmat() for System V IPC >almost for free. As it should be. I have already complained that shm{read,write} detach the shared memory segment between accesses. The implementor wrote back and said he did it that way just to get it to work, but didn't really understand how to do what Larry suggested. Which brings me to perl's code itself. Can anybody suggest how to approach perl's internals? What order should I read the files? It's a pretty hairy program, much harder to read than emacs. -- [rbj@uunet 1] stty sane unknown mode: sane
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/18/91)
As quoted from <129281@uunet.UU.NET> by rbj@uunet.UU.NET (Root Boy Jim): +--------------- | In article <28046072.4CFC@tct.com> chip@tct.com (Chip Salzenberg) writes: | >According to lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall): | >>What you'd really kinda like is a way to mmap a particular variable, and | >>let Perl worry about it when it gets reallocated... | > | >If such a thing were done, we we would get shmat() for System V IPC | >almost for free. | | As it should be. I have already complained that shm{read,write} | detach the shared memory segment between accesses. The implementor | wrote back and said he did it that way just to get it to work, but | didn't really understand how to do what Larry suggested. +--------------- Were I designing it, I'd arrange for strings (well, symbol table entries) to contain the "allocate" and "extend" function pointers for the strings. That way, you can do a whole bunch of things: extending strings enlarges the mmap() or shmat() area, or calls a function which arranges for a usersub to know what's going on (e.g. changes the projection list information for the Oracle usersubs recently posted), etc. (I'd mention "fixed-size" strings, but I can only think of one valid use for them: mmap()/shmat(). If there were a way to map device driver registers into user-mode code, this would also be a good application.) ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
tell@oscar.cs.unc.edu (Stephen Tell) (04/19/91)
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."