It looks like the copyright header is a leftover from some earlier copy-paste. If this is just your work based on @kib's it should presumably have a standard 2-clause BSD license.

In D7970#434733, @soutade_gmail.com wrote:

Hello,
This patchset has been created for FreeBSD 11. It has not been tested nor maintened since and I currently don't have time to work on it. I think we can drop it (it can be a base for new contributors).
Thanks

Upload rebased and updated diff - add arm linuxulator syscalls.conf and Makefile, from arm64

This patchset has been created for FreeBSD 11. It has not been tested nor maintened since and I currently don't have time to work on it. I think we can drop it (it can be a base for new contributors).

Oops, updated this review with the diff intended for D7972.

Reformat arm linux syscalls.master per current style

Reformat arm linux syscalls.master per current style

In D7973#164964, @imp wrote:

If this is just generated code, it doesn't need a code review :)

Oh I see @brooks already mentioned that.

We'll also want to switch this to the new style -- see rS347186 for arm64.

This should probably come at the end - add the source first, build infrastructure after.

Since this is a new file, you might want to consider formatting it in the new, more readable style used in sys/kern/syscalls.master.

For future updates (to this review, if any, or other reviews) please include context e.g. git diff -U9999

I believe that was superseded by D15857, which was committed quite some time ago.

In D13656#422012, @dchagin wrote:

ok, btw, what is the reason to create only 2 devices (eth0 and lo0)?

ok, btw, what is the reason to create only 2 devices (eth0 and lo0)?

updated patch to address style(9) issues.

Fixed latest style issue.

style (9)

Fixed style.

Committed in r473600

Downgrade dotnet from 2.1 to 2.0. Dotnet 2.1 uses Linux's /proc/$PID/maps output for various purposes, however FreeBSD has a but whereby output is truncated at 128KiB. This breaks the parsing of the output.

In D15823#335123, @yanko.yankulov_gmail.com wrote:

Just one more question. I can't figure out why we can't reparent the new proc in do_fork instead of waiting for its thread to do it? Any hint will be appreciated.

I am not sure about your question. Can you point to the exact piece of code which you want to move into do_fork ? If you mean proc_reparent() call from fork_return(), I put it there to have all code dealing with the attaching new child to the debugger, in single place. ptracestop() must be called from the stopping thread context, and proc_reparent() as part of the attachment code is naturally located nearby. But I may be mis-interpreting your question, and also I do not see why you are asking.

Yes, that the question. I was trying to figure out why we need the sleep in the fork path at all. Because if we can get rid of the sleep, there is no need to change anything else. So my reasoning was like this - it is either required by the ptrace interface/promises i.e. parent process will not continue execution before the child is attached, or it is part of the implementation of the interface.
I assumed it is not a ptrace requirement because there is no guarantees for the parent/child execution in non-ptraced mode, and went on to see why it might be needed. One thing in the current code is that we can't allow the parent process to exit before the child was reparented as we will not attach to the child.
So my question is if we reparent the child in do_fork wouldn't it be possible and desirable to drop the wait altogether?

Just one more question. I can't figure out why we can't reparent the new proc in do_fork instead of waiting for its thread to do it? Any hint will be appreciated.

I am not sure about your question. Can you point to the exact piece of code which you want to move into do_fork ? If you mean proc_reparent() call from fork_return(), I put it there to have all code dealing with the attaching new child to the debugger, in single place. ptracestop() must be called from the stopping thread context, and proc_reparent() as part of the attachment code is naturally located nearby. But I may be mis-interpreting your question, and also I do not see why you are asking.

In D15823#335084, @yanko.yankulov_gmail.com wrote:

I checked the rest of the RFSTOPPED use points and applying the change seems trivial. So if the general idea is acceptable I can apply the changes to all the places and upload a new patch.

Right now I think that this is working approach.