In D3654#85162, @kib wrote:

Yes, the restart problem is there. So, do you agree with having something along this lines (with or without the handling of timeout spent time) ?

Downside of this is that timeouts of the affected calls (kqueue/select/poll/nanosleep) are reset after a debug interrupt. If debug interrupts occur more often than the timeout, the calls will never time out. This is probably less harmful than the current [EINTR] but still a bug.

Reading the code, this looks OK, but in compilation an undesirable side effect can be seen. This is on amd64 with 11-current's default clang. The improvements to res_init() cause it to fall below a threshold and be inlined everywhere, leading to a 15% code size increase rather than the expected decrease (in the "text" column of size(1)).

Committed to head as SVN r288430 with the change to the man page. Thanks Warren Block for the review.

Fix bug in arglist handling.

Looks OK apart from minor style issues.

In D3043#68914, @kib wrote:

The diff is enormous and it pollutes a lot of unrelated places. E.g. the loader Makefiles changes or the forced undef fortify in libc/strings/stdio, as I understand, to avoid recursion.

Can the pollution be minimized somehow ? Can the patch be split into digestable pieces ?

In D2172#65244, @theraven wrote:

kmacy has been working on bringing over the notify(3) APIs from Darwin[1], which appear to provide a superset of this functionality. It would be worth comparing the two and seeing what can be shared between the two. Ideally, the file descriptor returned by notify_register_file_descriptor would be of the same kind as that returned by eventfd and, outside of the Linuxulator (where it needs to be a system call for binary compat), we might be able to implement the eventfd stuff entirely in libc using the same system calls as notify(3).

[1] https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/notify.3.html

Committed to head.

Looks good to me.

The code looks good to me.

The concept of allowing to set creation time looks good to me.

Is _fixtelldir() actually needed? I noticed a bug in it, and if loc_loc == 0, there doesn't seem harm in lseek() + getdirentries().

Looks good to me.

I have some small remarks that apply to all three but I only wrote them in chflags.

By the way, a workaround for the script is:

trap ' exit' INT

Looks good to me.

In D2316#17, @smh wrote:

In D2316#14, @jilles wrote:

If you're changing this, please make the interaction between -h and -R more sensible, as specified by symlink(7) and POSIX (though in the latter case not for chmod and chflags)
In that interpretation, it is never necessary to specify -h with -R; instead, -P implies -h, and -H implies -h for those files listed on the command line (not found in the tree walk).

Thanks for looking at this, I'm a little confused by your statement about "-H implies -h" as it seems to contradict symlink(7) specifically:
"The -H flag causes symbolic links specified on the command line to be dereferenced both for the purposes of the action to be performed and the tree walk, and it is as if the user had specified the name of the file to which the symbolic link pointed."

How I interpret that is that -H disables -h behaviour for the files specified on the command line only as they should already be dereferenced.

If you're changing this, please make the interaction between -h and -R more sensible, as specified by symlink(7) and POSIX (though in the latter case not for chmod and chflags). In that interpretation, it is never necessary to specify -h with -R; instead, -P implies -h, and -H implies -h for those files listed on the command line (not found in the tree walk). This may not be a fully compatible change, but it fixes confusing behaviour that commands like "chown -R u:g tree" leave symlinks alone.

The man page and the usage message still contain optional arguments for -i and -I.

I've reviewed the patch as if it's accepted to add this to the native API. I think it is possible to split the patch and first add the new fd type and kern_eventfd.c for the Linuxulator's use without committing to a new native API. This is definitely a required feature for the Linuxulator soon, if not now.

This is not really a lot of code, but I'm not sure it should be added as a fixed part of the native API, since it does not do much that is not already possible using pipe() or kqueue().

This may work better as a "command", i.e. IP_* thing. For one, unmounting parts of the jail and then running a stop command inside the jail is not a good idea. The code already has a concept of dependencies between commands and that should be taken advantage of.

Closed by commit rS279986 (authored by @jilles).

In D2020#3, @jhb wrote:

Looks fine to me.

Looks good to me.

Can you find out which file is returning [EAGAIN] while writing, and who is setting it non-blocking temporarily? It is also possible that a kernel bug causes [EAGAIN] on a write even though non-blocking mode is off.

I think getting rid of the cast is a win regardless of -Wcast-qual.