Sat Aug 24 03:06:01 2002
On Fri, 23 Aug 2002, Paul Fuqua wrote:
> Date: Thu, 22 Aug 2002 22:36:29 -0400 (EDT)
> From: Nyef <firstname.lastname@example.org>
> I've just pushed a new tarball to:
> I finally tried it; it compiles and runs without trouble on FreeBSD
This is good to hear.
> The only problem I had was that my load-band file was read-only,
> and your program wants to mmap() it read/write; until you get to the
> point of saving a band, I don't think you'll need to write to one.
It's mapped read/write and private. That is, the program can modify it,
but shouldn't be saving the changes back to the disk.
It's mapped read/write because if it were mapped read-only I'd have to
simulate the copy-on-write behavior of the VM, which would mean simulating
a lot more of the VM than I do currently (although this would mean that
I'd have the PHT done, and obviate having to fake up %PAGE-STATUS).
Both the Stevens book (Advanced Programming in the UNIX(R) Environment)
and the man page for mmap(2) say that you cannot use PROT_WRITE with a
read-only file, even if you use MAP_PRIVATE. No mention is made in either
location of possible interactions with mprotect(2).
> This release contains a couple new miscop handlers, and gets to the first
> invocation of %PAGE-STATUS (from deq-element in micronet/queue.lisp),
> I used a different band, which stopped in TRUNCATE-1 (undefined miscop)
> in SYS:%INITIALIZE-TV-SCREEN-MEMORY. It'll probably fetch up against
> %PAGE-STATUS itself once it gets past this one.
I have another band image which stops somewhere else, but I figured I'd
stick with the N928.LOAD that is supposedly the current E3 test candidate.
Thank you for your feedback. (sounds so trite and formulaic, doesn't it?)
All programming can be viewed as an exercise.