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.

In D2378#56588, @zbb wrote:

What do we do with it?
BTW. Does anyone know why diffs are not visible :-) ?

INVARIANTS already covers this. If you didn't want your machine to panic when it detects code failures, you shouldn't have compiled w/ INVARIANTS. :)

remove the vfs change as it has already been committed... This patch will be
committed in 24 hours unless comments are added.. It's languished too long..

I have committed part to properly break up the change...

changed to using M_ZERO instead... Maintainer should clean this up more.

switch to zero'ing all of memory, as selinfo and other fields aren't
properly initalized..

In D2890#56145, @mjg wrote:

This particular piece of code actually expects a zeroed struct. In particular, you can see that neither mtx_init nor knlist_init initialize the whole struct, leaving e.g.vpi_events and vpi_revents indeterminate. Then vn_pollrecord immediately examines vpi_revents of a newly added object and we are in trouble.

In other words, while it was mtx_init which complained about junk-filled memory, the issue is bigger. initialisation here needs to either be done with M_ZERO or extended to cover missed fields. Uninitialised parts also include something from struct knlist, so it's more than zeroing 2 shorts, but I'm too lazy to check how to do deal with that knlist.

tomorrow..

committed in svn commit: r284630 - head/usr.sbin/bhyve

addressed

address grehan's comments...

I'll look over the code more later.

looks like arc does support git trees too...

In D2842#55489, @emaste wrote:

In D2842#55479, @jmg wrote:

Read it, completely unconvinced that adding braces would have caught it, anyone who missed the strange indentation of two goto statements would have missed what extra braces ment... style(9) is there to help make code easier to read, but does not alleviate the developer from reading and understanding the code...

I think you've missed my point: in this case the braces aren't there to make it more likely someone would catch the extra goto fail in code review, but to make it less likely that a merge process ends up producing it at all.

I would recommend a statement that adds that the preferred/recommended is no extra braces if this must go in...

In D2842#54946, @emaste wrote:

It might have slipped through code review, but it's less likely to have been introduced in the first place if braces are used.

David Wheeler's got a pretty good description: http://www.dwheeler.com/essays/apple-goto-fail.html

needs work... style(9) is a guide, clearly not stricktly enforced, and if code is truely confusing w/o the braces, then add them, but changing style(9) is unneeded... The original example of double goto fail doesn't point out that:
if (case) {

goto fail;

}
goto fail;

looks fine, I haven't tested it though

In D1503#28407, @ae wrote:

Is there any news?

fix README to not using X86_...

this time have libcpufeats added so it gets included in the diff...