After reading all your comments and great suggestions, I will start incorporating them into the differential. As per Konstantin's suggestion, I will move everything to a separate module, ditch filesystem interactions and separate the namespace in a posixshm-like manner as Ka Ho Ng suggested, move thread pool logic to userspace and generally offload as much functionality as possible to userspace.
Thank you for your feedback and advice!

In D34097#771212, @khng wrote:

Do you think fattach binding to a file in the file system namespace is a necessary characteristic that we need to replicate as well? If not, I think another less-compatible approach is to separate the namespace all together, just like the posixshm facilities.

In D34097#771081, @kib wrote:

In D34097#771069, @bojan.novkovic_fer.hr wrote:

First off, thank you for taking the time to take a look at the patch!
This is my first patch and I greatly appreciate all feedback as I am overwhelmed by the vast complexity.
I am sure that there are more dubious lines of code lurking in the patch and I greatly appreciate all suggestions to rectify them.

As for the motivation, the project idea was listed on the IdeasPage which prompted me to write the patch in the first place.
This would make porting Illumos software which uses doors IPC possible and would also provide a fast and lightweight IPC mechanism.
For example, doors could be used instead of unix sockets for local communication.

Yes, proper implementation of this beast requires a lot of stuff. So you need to do some architectural work first, instead of hoping that ad-hock approach for hacking a lot of core structures would work.

For instance, AFAIR, Solaris has a concept of mounting over single vnode, which we don't, and which was used for doors. Do we want the same approach? If not, what is the right place to put doors-related data? This clearly depends on the desired lifecycle of the data, which needs to be defined explicitly.

Adding new vnode type has too much consequences for it to be worth the end goal. The fact that you have to somehow patch cd9660 and tmpfs is already a red flag.

How much of this code needs to live in kernel? Does the thread pool really have to be handled by kernel and not by userspace?
Another related question, why this cannot be pure userspace library? (I do not object against having some support code in kernel, but I believe it needs to be proven to be needed). Might be, some minimal kernel support would be enough, like an addition to umtx(2) operations, with the rest handled by userspace.

What should be the semantic of doors on exec? You clear all doors on fork, which is strange for fork, but leave it as is for exec.

How the server pool should react to the process stop/suspend requests?

Is it possible to make all of this non-intrusive, e.g. by containing all this code in a module? I do not mind if you need a pointer there and here, e.g. a scratchpad in struct proc, but scattering it all over the kernel, for an experiment, is too worrisome. Also see above about userspace implementation.

It seems you missed the MD files (amd64) in the patch.

Removed unused includes in door_machdep.c

First off, thank you for taking the time to take a look at the patch!
This is my first patch and I greatly appreciate all feedback as I am overwhelmed by the vast complexity.
I am sure that there are more dubious lines of code lurking in the patch and I greatly appreciate all suggestions to rectify them.

Removed redundant locks and a few errors.