Re: Patch to retrieve send rights for shared memory objects

[Marcus Brinkmann]

At Mon, 28 Feb 2005 14:35:14 -0800 (PST),
Roland McGrath wrote:
> 
> > Ok.  Should we change diskfs_get_filemap to accept a flag that says we do
> > not want to create the memory object if it doesn't exist already?  That
> > seems to be an important optimization to me if we call it in io_stat.
> 
> diskfs shouldn't be assuming anything about the filesystem's memory object
> ports and how to guess how many mappers there might be and so forth.

Yes, I realized this too late after sending the reply, sorry about the fuzz.

> Probably the easiest thing to do is just have the filesystem set these
> st_mode bits directly itself in dn_stat.  It knows when it passes out the
> memory object in the first place, so it can clear S_IMMAP0 then.

Yes.

> If it's
> necessary to do an active check at stat time to figure out how many mappers
> there might be, then this can be a new callback made by diskfs_S_io_stat.
> e.g., diskfs_modify_stat called just before unlocking the node.
> The library can provide a no-op default definition of the function so that
> old filesystems keep linking if they haven't been enhanced to produce the
> new bits.

Yes.  I am not totally sure yet, but I believe it might be necessary
to notice when the number drops back down to 1.  This is the only case
which the filesystem can not keep track of by itself, so an active
mach_port_get_refs call would be needed to find this out.  I will know
more when I reviewed shm using code more closely.

I also thought that maybe it would be convenient to define this meaning:

IMMAP0  IMMAP1  Meaning
0       0       Not supported.
1       0       Exactly no user.
0       1       Maybe only one user (or more).
1       1       Definitely more than one user.

I don't have any objection folding "11" into "00" though, and leave
"11" undefined.  Still, I feel the above is marginally more useful.

This leaves the questions to which number this should be mapped in
nattach of the shm info structures.  "10" should be mapped to "0" of
course, and "01" to "1".  For "11" (and by transition "00") there are
three reasonable values: "2", "42" (or some other arbitrary value in
the middle) and "TYPE_MAX".  My guess is that choosing an arbitrary
high value would be the most compatible (but not TYPE_MAX, because
that could trigger overflow bugs).  I kinda like "42".

Someone at the conference (I think it was Olaf) pointed out that the
actual number of bits required for three states is ln 3 / ln 2 == 1.585,
not one-and-a-half.  I didn't want to leave this unmentioned ;)

Thanks,
Marcus