> I don't have the previous messages, but I did grasp this much from the
> code. It might be that this is ultimately just a short-term hack for
> a tmpfs, however, and we have to hobble together what kludges work
> with it. I have some ideas about what the Right Thing would be; they
> all require interaction between the default pager and the tmpfs
> server.
If you are referring just to the question of tracking user send rights to
the memory object (i.e. io_map was called), then I can think of only one
approach that avoids interaction with the default pager. That is simply
never to drop the node, e.g. add a weak ref on the first io_map call and
have the dropweak function release it iff st_nlink==0. Then tmpfs files
that have been mmap'd always have "in-core" diskfs state until they're
removed. Sleazy, but basically harmless.
> It is perfectly kosher to go ahead and add such interfaces, as long as
> you don't hose the privileged threads of the default pager with them.
I'm not worried about kosher. I'm worried about breaking the thing and
being too much of a lame ass to want to debug it.
> Faults are, well, ok. We'll never be able to give them on a
> default-pager based interface, of course.
What I'd had in mind was new default_pager_object calls to fix the size of
a memory object (and clear pages past the new end). Those changes are
pretty simple, and make faults work right.
> Can you cite the Posix that you think is relevant?
But the book is two whole armlengths away, and it's ... so ... heavy.
Oh, alright. I went and looked. It's got a "shall" in the line;
I think I was right. 1003.1-1996 12.2.1 (mmap) p 274 ll 288-290:
[...] references [...] to whole pages following the end of an object shall
result in the generation of a SIGBUS signal.
In the context "object" means "file or shared memory object" (shm_open).
So I think "end of object" really does mean st_size of a file, and this
really is a binding requirement of the standard.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
