Allow CloudABI processes to create shared memory objects.

[ed]

Summary

Use the newly created kern_shm_open() function to create objects with
just the rights that are actually needed.

[kib]

What I _hate_ about these your commits is that they make the MFCs a major headache, to the level where it is simpler to not bother and declare that no merges are made.

Can you split the mergeable parts into the separate commits ? E.g., introduction of the kern_shm_open() is very well mergeable, even if struct filecaps become dummy arg on stable/10 (I do not claim that it is, just that the possible absence of the facility in 10 does not prevent introduction and merge of kern_shm_open() in 10).

Otherwise I am fine with the kern_shm_open().

[ed]

Remove changes that have been pushed in.

[ed]

In D3260#65994, @kib wrote:

What I _hate_ about these your commits is that they make the MFCs a major headache, to the level where it is simpler to not bother and declare that no merges are made.

My reasoning was that my changes can be merged back, as long as you just discard the changes I made to sys/compat/cloudabi*. I have no intent in merging CloudABI support back to a stable branch. My apologies if this causes too much churn; it was not my intent.

Can you split the mergeable parts into the separate commits ? E.g., introduction of the kern_shm_open() is very well mergeable, even if struct filecaps become dummy arg on stable/10 (I do not claim that it is, just that the possible absence of the facility in 10 does not prevent introduction and merge of kern_shm_open() in 10).

Otherwise I am fine with the kern_shm_open().

Sure! I've just committed the changes to sys/sys and sys/kern. All that remains is the change to sys/compat/cloudabi.

[kib]

Thank you for splitting. I do not have an opinion for the remaining bits.

The only question (not a note about the code) is why do you always enforce rw permissions ? Is there a way to get ro access to the shm segment ?

[ed]

In D3260#66027, @kib wrote:

Thank you for splitting. I do not have an opinion for the remaining bits.

The only question (not a note about the code) is why do you always enforce rw permissions ? Is there a way to get ro access to the shm segment ?

That's a good question!

On CloudABI you can only create anonymous shared memory objects. It wouldn't make sense to create read-only anonymous shared memory objects, as you wouldn't be able to write anything in there. You can, however, use dup() and cap_rights_limit() to create a second file descriptor that only has read access, which you can pass on to a child process, through a UNIX socket, etc.