Adjust door message size with door_setparam

[robertdfrench]

From u/jking13:

The door_getparam(3C) and door_setparam(3C) can be used to adjust the parameters (including the max message size). I suspect the limit you might be hitting on SmartOS could be related to the resource sizing of the zone -- since some of the results may end up having to use mmap, I believe that can also be a factor.

Would be interesting to compare the defaults on each system, or maybe even use door_setparam in the tutorial to make them equal, so that the message transfer lessons do not have to talk about message size in the abstract.

[robertdfrench]

Seems I have still got this wrong. Going to remove the door_setparam calls and set the message size back to 512K for the time being and figure out what those calls actually do, and take @jasonbking's comments about mmap into account before I take another swing at this.

[robertdfrench]

Specifically, what I am seeing is that the upper bound for a door_call message is -1 (unbounded?) on both smartos and openindiana, ulimit -s showed my stack limit to be ~10MB on both, and calling door_setparam with the arguments displayed in the current version of C0_payload_size/server.c is not sufficient to make the server door accept a 1MB message on openindiana.

I also am becoming skeptical that it is the distro which is the root of this behavior, as opposed to the zone config. I think I am in the global zone on my openindiana vm, but I need to verify that.

[robertdfrench]

W. Richard Stevens points out in Unix Network Programming vol. 2 that all of these fields can be modified independently. rbuf and rsize can be altered implicitly by the doors library if they refer to a too-small region in the recipient's heap. It seems we are guaranteed of these relationships after door_return:

• rbuf <= data_ptr <= desc_ptr < rbuf + rsize
• data_size + desc_num * sizeof(door_desc_t) < rsize