Should be able to more-or-less revive the one that was deleted in c57525f and update it to point to MNX.

In order to emphasize privilege separation, we actually need some of the processes to run as a different user. The setup guides should create one or more unprivileged users for the sake of demonstrating this feature.

Instead of copying payloads back and forth over doors, which incurs a performance cost, show how shared memory segments can be shared between the door server and the door client so that control can be passed back and forth without needing to copy large amounts of data.

As u/jking13 puts it:

The other bit that might be worth mentioning is that the advantage of a door vs. say a unix socket is that during a door call, the scheduler directly transfers control to the server thread -- so there is a very minimal scheduler overhead compared to other forms of IPC. There's a bit more to it, but probably a bit much for a tutorial.

It would be good to nail down the language as precisely as possible here. Is this the same as bypassing the scheduler? Do we avoid a context switch? Are we guaranteed that the server thread shares the same cpu timeslice as the client thread? Is it appropriate to make a comparison to cooperative scheduling, or has that got different implications

Looks like in server.c for step 1.8 (18?) has the server.c from step 2 (20?). This preemptively introduces some door specific code before explaining it. That step effectively introduces 2 new topics, of which only 1 is explained. Just a minor detail, and probably not an issue. Just something i noticed!

This tutorial is fantastic btw 👍

Suggested by u/jking13.

Github's table of contents is not rendered by default on mobile. You have to click the "show code" button. This is not necessarily an obvious place to hide the content, from the reader's point of view.

GitHub supports this now.

Suggested by @jack-morrison

The Makefiles all use GNU conventions, but don't have to. Porting them to illumos' make would allow the more natural make test syntax to work as expected. At the moment, if someone tries to do this (instead of gmake test), they get cryptic errors when illumos fails to parse GNU syntax.

Per u/jking13:

doing the stat(2) + creat(2) still leaves a window for something else to create the file between the two calls (and could potentially be a security issue) open(path, O_RDWR|O_CREAT|O_EXCL, mode) to create the path would be preferred -- it will fail if the path already exists.

On my SmartOS zone, I seem to be able to send door payloads that are about twice as big as I can on my VM running OpenIndiana. What is the difference?

• Configuration of the host?
• Hardcoded kernel parameters?
• Default ulimits?

I suspect this has something to do with stack size, but I am not quite sure what.

From u/jking13:

When you talk about passing a door through a door, it might be good to note that you're just using the feature that allows doors to pass file descriptors, just the descriptor in that case happens to be a door -- it could be a file, a socket, a pipe, etc.

This begs the question of whether there are other general means for passing descriptors to another process, and whether one could pass a door descriptor using those. If so it would be good to have a contrasting example so that I do not paint doors as more special than they really are.

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.

This is where we go over the data structures and conventions used for packing / unpacking arguments to / from door_calls, but there are no "Check for Understanding" questions at the bottom. It's a critical point for anyone wanting to work with the Doors API, so it's worth providing folks a way to convince themselves that they know what's going on. AND! Some of these structures are kindof subtle if you don't spend the majority of your time in C.

The idea being that the DNS server can host records for multiple different zones (belonging to different customers), and that each customer could update their records independently.

sequenceDiagram
  participant DNS Client
  participant DNS Server
  participant example.org Server
  participant example.org Admin
  example.org Admin->>example.org Server: door_call(SET a = 1.2.3.4)
  DNS Client->>DNS Server: udp(LOOKUP a.example.org)
  DNS Server->>example.org Server: door_call(GET a)

We call

door_call(door, &args);

but why? Can the server process modify args? I suspect that if the server returns fewer bytes than expected, the client will want to know, but can any other fields be modified?

For #12, we need to show that rpc calls have more latency with sockets than with doors. For #11 we need to show that you can pass a descriptor with the sockets library. Thus, we need an alternate implementation of some of these demos using sockets.

At least navigate folks through setting up a SmartOS zone on Joyent and connecting to it, and setting up gcc. That ain't obvious.

Per u/jking13:

Also illumos (note: it is supposed to intentionally be lowercase, don't ask me why), supports the BSD-style err(), errx(), etc functions via the inclusion of err.h. That could simplify all those perror(...); exit(1) bits. Not necessary, but can be nice.

Otherwise this thread won't be available for responding to door_calls.

This is the right way to clean up a door, and should be called when the server exits