Hi all,
After commit 986d9deb3b24bc72e9e7ecf93affbc3f188bb926 ("build: allow
calling append-dtb from image build commands"), layerscape targets do
not build correctly anymore.
The failure is on DTB compilation, where an attempt is made to place the
DTB in a non-existent path:
make[5]: Ente
Hello,
It turns out that the assumption that the "transmit timed out"-issue
was related to pause frames/flow control was incorrect. I have
recently started to see the error again, with flow control disabled.
However, unlike last time, I am now able to reliably trigger the
issue.
The timeout seems
Rosen Penev wrote:
> Less verbose.
>
> Signed-off-by: Rosen Penev
>
> v2: some of those memset calls are needed. Also replace { 0 }
> with {}.
cmon, that's just unnecessary. It's one thing to prefer using gnu
{} instead of ISO C {0} but replacing ISO standard C form with a
gnu form, just beca
Thanks, also for the link (https://vorpus.org/blog/why-does-calloc-exist/).
This article made me aware that using calloc() may be wise.
For security reasons: calloc avoids possible arrhythmic overflows when the
allocation size for malloc is the product of two numbers.
And because it may offer re
Citeren Rosen Penev :
Less verbose.
And uses a GCC extension which makes it less portable. ISO C forbids
empty initializer braces [1]. See for yourself by adding the -pedantic
flag to your CFLAGS. The correct way to initialize to all-zeros is
therefore { 0 }.
[1] ISO/IEC 9899:201x, par
On Wed, 8 Nov 2017, John Crispin wrote:
you can probably drop the validation. if the users passes 9 as a
priority everything will be logged. passing -1 will cause silent logging.
you should do limit checks and cap the internal value to the limit, otherwise
you have to do more work for each lo
Felix Fietkau writes:
> On 2017-11-08 07:18, John Crispin wrote:
> It's just the I/O scheduler, not the CPU one. It will have zero impact
> on typical router workloads. The only thing that might get slower is
> heavy multi-threaded disk I/O, which is probably an extremely rare
> occurence on LEDE
On Wed, 2017-11-08 at 10:27 +0100, Felix Fietkau wrote:
> On 2017-11-08 07:18, John Crispin wrote:
> > j
> >
> >
> > On 07/11/17 19:41, Rosen Penev wrote:
> > > most users don't have multithreaded workloads though.
> > >
> > > On Mon, Nov 6, 2017 at 4:43 PM, Dave Taht wrote:
> > > > I happen to
On Wed, 2017-11-08 at 11:57 +0100, Paul Oranje wrote:
> Both memset() and calloc() have highly optimised implementations, so
> the expected gains with this patch for the allocation of zeroed
> memory will be small at best. As this patch does not fix a bug: why
> is the change "needed" ?
>
Style ch
Less verbose.
Signed-off-by: Rosen Penev
v2: some of those memset calls are needed. Also replace { 0 } with {}.
---
interface.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/interface.c b/interface.c
index 7f814d2..deabcbb 100644
--- a/interface.c
+++ b/i
Citeren Alexandru Ardelean :
On Tue, Nov 7, 2017 at 11:18 PM, Arjen de Korte
wrote:
Citeren Rosen Penev :
I beg to differ. https://vorpus.org/blog/why-does-calloc-exist/
Section 2.
I don't care about theoretical gains, benchmarks please. How much do you
gain with these patches? I really
Previous email was a little premature, but more news on the subject:
https://sourceware.org/bugzilla/show_bug.cgi?id=984
from what I can tell, MUSL reads the resolv.conf file on every call to
__lookup_name()… so it shouldn’t have this issue.
Then again, it’s a problem that’s more likely to affl
On 2017-11-07 09:45, Zoltan HERPAI wrote:
> Given that we've decided to sail under the same flag for
> the benefit of the whole community, and acknowledge the
> achievements of the LEDE project, let's start the final
> steps of the merge.
>
> The git and other sources are untouched until the infra
Hi Stijn,
What is your opinion on this patch? There has been a bit of feedback, but
you were the one requesting the change in the first place :)
Thanks,
Baptiste
On 26-10-17, Baptiste Jonglez wrote:
> When calling a download target, hash verification is now completely
> skipped if the SKIPHASH
Hi,
Thanks for feedback!
On 31-10-17, Philip Prindeville wrote:
> I’d also note that some of the compatibility stuff has been deprecated,
> hasn’t it?
What do you mean?
> > define Package/openssl/Default/description
> > -The OpenSSL Project is a collaborative effort to develop a robust,
> > -c
Both memset() and calloc() have highly optimised implementations, so the
expected gains with this patch for the allocation of zeroed memory will be
small at best. As this patch does not fix a bug: why is the change "needed" ?
Just curiosity, bye,
Paul
> Op 7 nov. 2017, om 21:05 heeft Rosen Pene
Hi,
comments inline.
> ---
> interface.c | 22 --
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/interface.c b/interface.c
> index 7f814d2..18dee52 100644
> --- a/interface.c
> +++ b/interface.c
> @@ -44,7 +44,7 @@
> static int
> interface_send_packet4
On 11/08/2017 10:57 AM, Zefir Kurtisi wrote:
> On 11/07/2017 09:24 PM, Rosen Penev wrote:
>> Less verbose
>>
>> Signed-off-by: Rosen Penev
>> ---
>> interface.c | 22 --
>> 1 file changed, 8 insertions(+), 14 deletions(-)
>>
>> diff --git a/interface.c b/interface.c
>> index 7
On 11/07/2017 09:24 PM, Rosen Penev wrote:
> Less verbose
>
> Signed-off-by: Rosen Penev
> ---
> interface.c | 22 --
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/interface.c b/interface.c
> index 7f814d2..18dee52 100644
> --- a/interface.c
> +++ b/int
On Tue, Nov 7, 2017 at 9:34 PM, Rosen Penev wrote:
> Replace malloc+memset with calloc. Cleaner and faster in extreme situations.
>
> Signed-off-by: Rosen Penev
> ---
> libubus.c | 6 ++
> lua/ubus.c | 18 ++
> 2 files changed, 8 insertions(+), 16 deletions(-)
>
> diff --gi
On 2017-11-08 07:18, John Crispin wrote:
> j
>
>
> On 07/11/17 19:41, Rosen Penev wrote:
>> most users don't have multithreaded workloads though.
>>
>> On Mon, Nov 6, 2017 at 4:43 PM, Dave Taht wrote:
>>> I happen to like deadline schedulers, and at least from a kernel
>>> perspective, we have a
John Crispin [2017-11-08 08:01:53]:
Hi,
> wondering if it would be nicer to add this to the already existing if
> clause.
I find code more readable if I check for all necessary preconditions at the
start of the function and then do the main logic afterwards, if all
precondition are met, so I
22 matches
Mail list logo
