The code is m68k and the comment is PowerPC.
Any guidance for the porting guide on what constitutes too expensive? There
should be some general guidelines regarding when to pick a format bases on that.
Also.. This means that some ports will have 2038 issues at the score level. We
have to
On Tue, Sep 23, 2014 at 11:38 AM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
The code is m68k and the comment is PowerPC.
Any guidance for the porting guide on what constitutes too expensive? There
should be some general guidelines regarding when to pick a format bases on
that.
Also..
On 23/09/2014 10:29 pm, Jennifer Averett wrote:
I tried to limit how much functionality I removed from the capture engine with
this
set of patches and limit it to what had to be removed in order to support
removal of
capture tasks. I have no problem with it moving to cpuuse, but I think it
On 23/09/14 18:27, Gedare Bloom wrote:
On Tue, Sep 23, 2014 at 11:38 AM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
The code is m68k and the comment is PowerPC.
Sorry, a copy and paste error.
I did performance tests on both platforms with FTP transfers to/from
/dev/zero. I observed
On 24/09/2014 3:27 pm, Sebastian Huber wrote:
On 23/09/14 18:27, Gedare Bloom wrote:
On Tue, Sep 23, 2014 at 11:38 AM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
The code is m68k and the comment is PowerPC.
Sorry, a copy and paste error.
I did performance tests on both platforms with
On 24/09/2014 3:42 pm, Sebastian Huber wrote:
On 24/09/14 07:34, Chris Johns wrote:
On 24/09/2014 3:27 pm, Sebastian Huber wrote:
Yes, we should move to 64-bit time_t after the next release or even now.
What is involved ?
Something like this:
diff --git
On 24/09/14 07:45, Chris Johns wrote:
On 24/09/2014 3:42 pm, Sebastian Huber wrote:
On 24/09/14 07:34, Chris Johns wrote:
On 24/09/2014 3:27 pm, Sebastian Huber wrote:
Yes, we should move to 64-bit time_t after the next release or even now.
What is involved ?
Something like this:
diff
