Date:Sun, 12 Oct 2014 00:17:22 +0900
From:Masao Uebayashi uebay...@gmail.com
Message-ID:
cadbf7ecem8n2vhq_9ats2ysjzx-zl-4cg65jtd7vuu0nigt...@mail.gmail.com
For what it is worth, this change (below) just bit me - I did my first new
builds for a couple of weeks, and my
On Wed, Oct 15, 2014 at 08:28:31PM +0700, Robert Elz wrote:
[...]
| Including std.ath_hal means that you pull in ath device code in your
| kernel.
No it doesn't. All it is is a bunch of option definitions, by themselves,
those do (or should do) nothing. What's more, I verified that
On Tue, Oct 07, 2014 at 12:40:04AM +0700, Robert Elz wrote:
Date:Mon, 6 Oct 2014 14:26:44 +
From:Havard Eidnes h...@netbsd.org
Message-ID: 20141006142644.7693...@cvs.netbsd.org
| Make this build again without debugging enabled; DPRINTF() can end up
| as
On Tue, Oct 07, 2014 at 04:53:44PM +, Andreas Gustafsson wrote:
Module Name: src
Committed By: gson
Date: Tue Oct 7 16:53:44 UTC 2014
Modified Files:
src/tests/lib/libm: t_exp.c
Log Message:
In the exp2_values test case, provide separate expected return values
for
On Wed, 15 Oct 2014, David Laight wrote:
Consider what happens if you write:
if (error)
DPRINTF((...));
else
fubar();
When DPRINTF() expands 'if (xxx) yyy' it all goes horribly wrong.
That's why I changed it to
do { if (xxx) yyy; }
Date:Wed, 15 Oct 2014 19:41:40 +0100
From:David Laight da...@l8s.co.uk
Message-ID: 20141015184140.gl23...@snowdrop.l8s.co.uk
| Consider what happens if you write:
| When DPRINTF() expands 'if (xxx) yyy' it all goes horribly wrong.
Of course, the do { } while(0)
On Tue, Oct 14, 2014 at 03:16:56AM +, John Nemeth wrote:
Module Name: src
Committed By: jnemeth
Date: Tue Oct 14 03:16:56 UTC 2014
Modified Files:
src/sys/arch/x86/x86: identcpu.c
Log Message:
Force x86_xsave_features to 0 when running under XEN for AMD
processors.
