address some comments.

Just a few comments.

I said Yes, but I think that we need to clean up our base libraries first. We need to make most/all libs private. If it isn't part of posix, it needs a man page which links to functions provided.

Thanks. changed.

• change a needs to to a must to be more correct.. If there are threads

Address all but /The/That/ change.. I understand why you suggested it, but it reads not as easily for me... We are only referencing the once example.

• address comments from bjk...

hopefully update the diff w/ complete change..

ok, this is an issue w/ git and arc locally, not with phabric...

• Fix date..

add documentation to kthread, and fix up kproc Sx

Minor comments.

Thanks, looks good.

In D3354#68427, @markm wrote:

In D3354#68413, @delphij wrote:

I have only glanced over the code and it seems good overall.

Thanks!

One thought: can we make DEV_RANDOM something like NO_DEV_RANDOM? That way it would be an opt-out feature, as most systems still need it.

Nope, sorry. The DEV_RANDOM pseudo-option comes for free from 'device random' in the kernel config file. There is no negative variant, but it is safe enough given that the kernel configs that need this device have it.

Are you opening this up to more reviewers? Or still only for SO (aka delphij)? The reason I ask is that secteam only consists of delphij, so adding secteam doesn't add any new reviewers.

Comments are not required to be addressed.

Look good.. Please address the comments.

In D3303#66772, @ed wrote:

In D3303#66768, @jmg wrote:

I don't see an issue w/ this, though if this is committed, but then CloudABI decided to not use it anymore, I request that it be removed.

Of course. Would it make sense to #ifdef _KERNEL it and revert the man page changes? That way we can be certain that userspace won't use it.

I don't see an issue w/ this, though if this is committed, but then CloudABI decided to not use it anymore, I request that it be removed.

I'm fine w/ this change.

Please post a complete patch that includes both sets of changes, and adds proper documentation.

errx needed to be used instead of err as errno will not be set in this case.

Update to add error when d == 0...

I could also use the term reciprocal, but for me invert makes sense and is more common.

In D3084#61045, @imp wrote:

Invert isn't the right terminology.
You are converting from the time domain to the frequency domain.
This is a fundamental conceptual faux pas.

Other than the set/true change, the changes to the manpage are great.

Please make it clear how the function behaves. Too much is unspecified.

does rS285336 have all these changes in it?

the pause has been removed in rS285297, it was unneeded because another lock by the crypto driver prevented it. I have also documented this in the man page.

address a couple of kib's comments...

remove ifdef INVARIANTS, and add i386 support..

Are you to busy to make the requested changes? If I create a patch addressing the changes, would you accept that, or do you reject the requested changes?

add rule to tell the user how to rebuild the .o.uu when it is out
of date...

Marking uudecode as done as bapt hasn't replied to my question for over a month and there are already existing requirements on uudecode.

In D2651#58654, @kib wrote:

In D2651#58647, @imp wrote:

Don't like the generated code that's committed to the tree, nor the yasm sources.

I have exactly the same opinion about this issue. IMO we should provide consistent source which can be self-rebuilt. We do accept .o blobs for obscure hardware, or keep such blobs in the ports. Having the sensitive crypto code in blob, for which the external tool is needed, does not feel right. Also note that there are many offspring x86 assemblers, which are known to be badly maintained and eventually fall into the stagnation.

I noted some options which could be tried, e.g. using intel mode for gas/clang, or whole file convertion to the att syntax.

Whatever the decision is, I dislike the .o for core kernel component very much.

I plan to commit this next week if I don't get any reviews. This has been in review for over a month w/o comments.

In D2936#57341, @eri wrote:

The only issue i have with jmg@ locking patch is that it provides consistency for userland threads but i still do not see how it solves the panic due to FPU on a migrated thread!

I only reviewed the changes in the new diff, I have not verified that my other comments were addressed.

Some more comments.

Ok, added my comments. I need to get going, and will complete the review later.