- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 31 2015
Jul 30 2015
I'm fine w/ this change.
Jul 29 2015
Jul 28 2015
Jul 25 2015
Please post a complete patch that includes both sets of changes, and adds proper documentation.
Jul 18 2015
Jul 15 2015
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.
Jul 14 2015
Other than the set/true change, the changes to the manpage are great.
Jul 12 2015
Please make it clear how the function behaves. Too much is unspecified.
Jul 11 2015
Jul 10 2015
does rS285336 have all these changes in it?
Jul 9 2015
Jul 8 2015
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...
Jul 7 2015
remove ifdef INVARIANTS, and add i386 support..
Jul 6 2015
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?
Jul 5 2015
Jul 4 2015
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.
Jul 3 2015
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!
Jul 1 2015
I only reviewed the changes in the new diff, I have not verified that my other comments were addressed.
Some more comments.
Jun 30 2015
Ok, added my comments. I need to get going, and will complete the review later.
Jun 27 2015
Jun 25 2015
In D2378#56588, @zbb wrote:What do we do with it?
BTW. Does anyone know why diffs are not visible :-) ?
Jun 23 2015
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..
Jun 20 2015
committed in svn commit: r284630 - head/usr.sbin/bhyve
addressed
address grehan's comments...
Jun 19 2015
I'll look over the code more later.
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
Jun 17 2015
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;
Jun 14 2015
Jun 11 2015
Jun 3 2015
looks fine, I haven't tested it though
Jun 1 2015
In D1503#28407, @ae wrote:Is there any news?
May 25 2015
fix README to not using X86_...
this time have libcpufeats added so it gets included in the diff...