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
would need to
be modified to use a printk plugin an
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 addres
On Tue, Sep 23, 2014 at 11:38 AM, Joel Sherrill
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.. This means that some
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
w
On 23/09/14 18:27, Gedare Bloom wrote:
On Tue, Sep 23, 2014 at 11:38 AM, Joel Sherrill
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 roughly 3% processor load i
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
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/
On 24/09/14 07:34, Chris Johns wrote:
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
wrote:
The code is m68k and the comment is PowerPC.
Sorry, a copy and paste error.
I did performance tests on both plat
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 a/newlib/libc/include/machine/type
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 -
On 24/09/2014 3:51 pm, Sebastian Huber wrote:
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.
Wh
On 24/09/14 07:55, Chris Johns wrote:
On 24/09/2014 3:51 pm, Sebastian Huber wrote:
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 af
11 matches
Mail list logo
