Address suggestions (move a comment out of an if).

Be even more explicit about the possible values for the property capability that map to the real-time or idle classes.

Address suggestions (move a comment out of an if).

Fix the commit message.

Apply suggestions.

Refresh

Refresh

Delay removing LOGIN_DEFPRI in another commit (not to be MFCed now). Arguably, the removal didn't belong to this commit anyway.

Delay removing LOGIN_DEFUMASK in another commit (not to be MFCed now).

Fix inverted test after panicstr => KERNEL_PANICKED() conversion.

I was already pretty confident that nmount() has been accepting atime for a long time. I just checked to be sure, and it's effectively the case.

Update.

Address comments.

Address comments.

Add braces around a split statement. Update the commit message.

In D43466#990866, @dvl wrote:

I think you're saying why have a command-line switch when we have the in-conf-file option?

First, two high-level remarks:

1. About the purpose of this change: I've probably not evaluated enough if removing -c is a good idea, so I'm neutral on this topic. Having command-line switches for what can also be specified in a config file generally makes sense to me (with the command-line switch overriding the configuration file). On the other hand, if the program is not to be launched by hand frequently, there is no such necessity. I agree it's best that administrators tweak a common configuration file rather than specifying command-line switches in rc.conf, with the goal to apply the same environment to manual invocations. That said, I'm not sure it's a reason in itself to remove command-line switches.
2. About <compress> : I would really like this directive to be renamed to <compress_override>, since it doesn't affect files that are not already flagged with a compression letter, so the current name is misleading to people that would want to enable compression of all files (which this directive can't do). This would be best done in a separate revision.

@pauamma_gundo.com Ah, I forgot to tag you as a reviewer in the commit. I'm sorry.

Rework the part on the lifecycle pointed to by dst.

Address the leak of cpuset.

Address comments.

And fix the EINVAL description.

Fix the description of which data is returned. Add the guarantee that the passed object is left unmodified in case the function reports failure (depends on D43329). Mention ENOMEM as a possible return value.

Implement the "better" solution.

In D43249#987508, @imp wrote:

I also agree this is a hard problem. I looked at 100% eliminating this mechanism in favor of a mechanism that would return up the stack an estimate of how much write throughput each element could handle. In the geom layers I had to do some hacks for gmirror, gstripe, etc to fan in data in intelligent ways from the different devices. I also then passed this up to the bufobj that's scheduling the writes and hacked bufwrite to try to not schedule more than that 100ms of writes (so the wait move from after to before).... But I never got it stable, and the patches then decayed with other changes in vfs_bio and I never returned to it. The key, I think, is to provide some back pressure signal up the I/O stack so that the top level bufobjs don't write more than a fraction of the underlying disks / etc can handle in some small time slice. But I agree with your statement that the actual solution isn't clear, and I'm no closer to presenting one than i was several years ago when I started down this path... and I'll not have the time it needs to try again for a while :(. There might be a simpler way to do this as well based on allowing some writes through initially, but then backing off if they conjest, but it would likely need to be per-bufobj driven rather than globally (though I acknowledge that at the top end of doing this dynamically there's other limiting factors that I've not fully comprehended).

but again, I think this was a good change, and maybe there's a better place to have this discussion since we're space limited here and fragmented.

In D43335#987861, @emaste wrote:

jhb@ prefers such code to be written as

IMO that is indeed clearer.

The typo in the title ("libhtr" => "libthr") will be fixed on commit.