[LEDE-DEV] A request not making IRC necessary to be part of the action

[Daniel Dickinson]

Hi,

I'd really appreciate if we could actually use the mailing list for the
main communications venue rather than shutting out people not in the
European timezones, which is what happens if IRC is the main way to
participate in the community.

I have been told that to really be part of the OpenWrt action I should
have been on IRC; but I'm not in European timezone so that is not
actually a useful suggestion, since most of the most people most
relevant to decision-making are in Europe, and I would hope LEDE has a
more *inter-continental focus than OpenWrt had.

Regards,

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Funkiness with lede-staging / lede-source

[Daniel Dickinson]

Hi all,

Was there some history rewriting or something lede-staging and/or
lede-source transition.

I have a number of branches I created against lede-staging that after
some pull diverged, and which also have a divergent set of commits from
lede-source, so I'm wondering if something non-kosher was done to the
lede-staging tree?

Regards,

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] ar71xx v4.4 testing

[Felix Fietkau]

On 2016-05-14 21:32, Hannu Nyman wrote:
> On 14.5.2016 21:33, Felix Fietkau wrote:
>> On 2016-05-14 12:56, Hannu Nyman wrote:
>>> Sorry but no beef. I still end up in a reboot loop with my WNDR3800.
>>> I applied your two 4.4. patches manually to my sources.
>>>
>>> As far as I could see from the LEDs, the router reboots before the failsafe
>>> entrance point is reached. Behaviour looks similar as before your patches. 
>>> (I
>>> have been compiling and trying 4.4 monthly ever since nbd introduced 4.4
>>> support for ar71xx initially and so far every attempt has been a reboot 
>>> loop.)
>> Please try the updated version from my staging tree, it should work now:
>> http://git.lede-project.org/lede/nbd/staging.git
>>
>> Thanks,
>>
>> - Felix
> 
> Thanks, Felix.
> Your patch fixed booting for me. I applied your commit 
> 60069b2270882d70069a2da3664e87791f9b76c3 on top of John's two patches, as 
> they did not seem to conflict. The router booted ok after the flash.
> 
> (note that in patch 620-... Felix hardcoded the value 3 instead of using 
> QCA953X_DDR_REG_FLUSH_PCIE (and _WMAC), while John fixed those symbols' 
> values in his changes to the patch 620-... and in the new patch 480-... )
> 
> However, a negative symptom is that the radios are disabled. I did not apply 
> your new mac80211 patch, so that might be a reason. "wifi detect" produces no 
> output.  I haven't tried to debug that any further, but just wanted to tell 
> that the WNDR3800 router finally boots with kernel 4.4, so the changes from 
> Felix are to the right direction.
Please use the commits from my staging tree as-is and skip John's patches.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] [ubox] logd: add ubus reload method

[John Crispin]

On 13/05/2016 22:40, David Lang wrote:
> On Fri, 13 May 2016, Alexandru Ardelean wrote:
> 
>> On Fri, May 13, 2016 at 8:55 PM, David Lang  wrote:
>>> On Fri, 13 May 2016, Helmut Schaa wrote:
 I was thinking of a different use-case:
 Increasing the buffer size on the fly comes in handy during a debug
 session
 where you'd like to not interrupt logging (and thus potentially lose
 some
 parts
 of the syslog when restarting logd).

 Independent of how the implementation looks like I think the
 functionality
 would be quite useful.
>>>
>>>
>>> I don't think it's very valuable. If you are debugging, you really don't
>>> want to be tweaking anything in the middle of trying to capture data.
>>> you
>>> want to set everything up and let it run, then analyze the data.
>>>
>>> I don't see that changing the log size in the middle of a capture run
>>> is a
>>> good idea, let alone one that is common enough to have to introduce uci
>>> specific knowledge into the logd daemon.
>>>
>>> You are better off sending to a remote logserver anyway.
>>>
>>> David Lang
>>>
>>>
>>> ___
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>> First of all, let's agree on a few things:
>> 1) the patch " [ubox] syslog: use realloc to change log buffer size ",
>> which precedes this, is an improvement over the existing code in logd
>> ; the initial code of logd, includes a logic to dynamically increase
>> the log buffer (using malloc() + memcpy()) ; there are 2 logical
>> options regarding that code:
>>   1.1) make it work (as that patch does)
>>   1.2) remove it
>> 2) there are people that don't need this ability to dynamically
>> increase the log buffer ; we do need it, but are not blocked by not
>> having it ; it would be neat to have in upstream ubox/logd, given that
>> logd was initially written with this ability partially intended;
>>
>> I don't know if this pushback is also amplified by my snappy reply to
>> KarlP.
>> If it is, well, c'est la vie :) .  I lost an argument because of a
>> snappy come-back that upset some people. Wouldn't be the first time.
>>
>> I feel that this change [to dynamically increase the log-size] can be
>> achieved with minimal impact on code/binary size and logd behavior
>> (given point 1) ).
>> Normal operation should not be affected (or the patchset can be
>> adapted to less affect normal operation).
>> And then, if it's in, people can choose to use it or not.
>> Or, if it's too intrusive/bothersome, we can drop the patchset
>> altogether.
>>
>> I'm still unclear yet how patch submission works in LEDE, and how
>> patches are accepted/voted, or who has the final go.
>> At least this process can shed some on light on that (for us).
> 
> People don't object to the ability to resize the buffer if the code
> impact is small, but when you start saying that you want to have logd
> understand/parse UCI in the binary (as opposed to the script that starts
> the binary), the code impact is not that small any longer.
> 
> The use case isn't non-existant, but it is marginal.
> 
> David Lang


tl;dr - just noticed 100 mails in this thread

the way deamons are expected to work is that they load with a default
configuration, this is usually loaded from uci and for small daemons
passed as the cmdline. if the config changes there are 2 ways to handle this

1) restart the daemon with a new cmdline
2) use the config.change trigger notification and send a new config to
the daemon via ubus.

this patch does 3) hook uci into the daemon etc pp which is i am afraid
not an option.

the difference between 1) and 2) is 1) is less code and 2) preserves the
data in the buffer. personally i would got for 1) but if there is a
patch for 2) that is clean i'll happily merge it. i'll close the series
as "Changes requested" and wait for a resend of 1) or 2) which ever it
might be.

John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] [ubox] logd: add ubus reload method

[John Crispin]

On 12/05/2016 14:09, Dan Bugnar wrote:
> From: Dan Bugnar 
> 
> Add logd link to uci library, to read the system config file and get the 
> buffer size.
> Remove the -S option support and use just the option from the config file.
> 
> Signed-off-by: Dan Bugnar 

NAK, logd should not get a dependency on uci. if you want to change the
buffer size there are 2 options

1) restart the log daemon with a bigger default buffer
2) add a ubus call that will realloc the buffer and copy the existing data

John

> ---
>  CMakeLists.txt |  2 +-
>  log/logd.c | 60 
> --
>  log/syslog.c   |  8 +---
>  log/syslog.h   |  2 +-
>  4 files changed, 49 insertions(+), 23 deletions(-)
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 834b5b6..b635c4a 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -42,7 +42,7 @@ INSTALL(TARGETS validate_data
>  )
>  
>  ADD_EXECUTABLE(logd log/logd.c log/syslog.c)
> -TARGET_LINK_LIBRARIES(logd ubox ubus)
> +TARGET_LINK_LIBRARIES(logd ubox ubus uci)
>  INSTALL(TARGETS logd
>   RUNTIME DESTINATION sbin
>  )
> diff --git a/log/logd.c b/log/logd.c
> index 27d3cac..6e493d0 100644
> --- a/log/logd.c
> +++ b/log/logd.c
> @@ -23,9 +23,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "syslog.h"
>  
> +#define SYSTEM_CONFIG_PATH "/etc/config"
> +#define SYSTEM_CONFIG "system"
> +#define LOG_DEFAULT_SIZE 16
> +
>  int debug = 0;
>  static struct blob_buf b;
>  static struct ubus_auto_conn conn;
> @@ -124,9 +129,48 @@ write_log(struct ubus_context *ctx, struct ubus_object 
> *obj,
>   return 0;
>  }
>  
> +static void
> +config_reload()
> +{
> + struct uci_context *ctx;
> + struct uci_package *p;
> + struct uci_element *e;
> + int size = LOG_DEFAULT_SIZE;
> + 
> + ctx = uci_alloc_context();
> + if (!ctx) {
> + fprintf(stderr, "Could not allocate memory for config\n");
> + exit(-1);
> + }
> + ctx->flags &= ~UCI_FLAG_STRICT;
> + uci_set_confdir(ctx, SYSTEM_CONFIG_PATH);
> + if (uci_load(ctx, SYSTEM_CONFIG, ) == 0){
> + uci_foreach_element(>sections, e){
> + struct uci_section *s = uci_to_section(e);
> + if (strcmp(s->type, "system") == 0){
> + const char *buffer_size = 
> uci_lookup_option_string(ctx, s, "log_buffer_size");
> + if (buffer_size != NULL)
> + size = atoi(buffer_size);
> + break;
> + }
> + }
> + }
> + uci_free_context(ctx);
> + log_buffer_reinit(size * 1024);
> +}
> +
> +static int
> +reload_log(struct ubus_context *ctx, struct ubus_object *obj,
> + struct ubus_request_data *req, const char *method,
> + struct blob_attr *msg)
> +{
> + config_reload();
> + return 0;
> +}
>  static const struct ubus_method log_methods[] = {
>   { .name = "read", .handler = read_log, .policy = _policy, 
> .n_policy = 1 },
>   { .name = "write", .handler = write_log, .policy = _policy, 
> .n_policy = 1 },
> + { .name = "reload", .handler = reload_log },
>  };
>  
>  static struct ubus_object_type log_object_type =
> @@ -176,22 +220,10 @@ ubus_connect_handler(struct ubus_context *ctx)
>  int
>  main(int argc, char **argv)
>  {
> - int ch, log_size = 16;
> -
>   signal(SIGPIPE, SIG_IGN);
> - while ((ch = getopt(argc, argv, "S:")) != -1) {
> - switch (ch) {
> - case 'S':
> - log_size = atoi(optarg);
> - if (log_size < 1)
> - log_size = 16;
> - break;
> - }
> - }
> - log_size *= 1024;
> -
>   uloop_init();
> - log_init(log_size);
> + config_reload();
> + log_init();
>   conn.cb = ubus_connect_handler;
>   ubus_auto_connect();
>   uloop_run();
> diff --git a/log/syslog.c b/log/syslog.c
> index d6cb868..683eeb8 100644
> --- a/log/syslog.c
> +++ b/log/syslog.c
> @@ -270,16 +270,10 @@ log_buffer_reinit(int size)
>  }
>  
>  void
> -log_init(int _log_size)
> +log_init()
>  {
>   regcomp(_prio, "^<([0-9]*)>(.*)", REG_EXTENDED);
>   regcomp(_tstamp, "^\[[ 0]*([0-9]*).([0-9]*)] (.*)", REG_EXTENDED);
> -
> - if (log_buffer_reinit(_log_size)) {
> - fprintf(stderr, "Failed to allocate log memory\n");
> - exit(-1);
> - }
> -
>   syslog_open();
>   klog_open();
>   openlog("sysinit", LOG_CONS, LOG_DAEMON);
> diff --git a/log/syslog.h b/log/syslog.h
> index ed5a41b..fe815b9 100644
> --- a/log/syslog.h
> +++ b/log/syslog.h
> @@ -30,7 +30,7 @@ struct log_head {
>   char data[];
>  };
>  
> -void log_init(int log_size);
> +void log_init();
>  void log_shutdown(void);
>  
>  typedef void (*log_list_cb)(struct log_head *h);
> 

Re: [LEDE-DEV] ar71xx v4.4 testing

[Felix Fietkau]

On 2016-05-14 12:56, Hannu Nyman wrote:
> On 14.5.2016 11:54, John Crispin wrote:
>> i pushed a tiny patch to fix a regression which i believe was the root
>> cause for v4.4 not working for most folks. if anyone has time to test
>> please do so.
> Sorry but no beef. I still end up in a reboot loop with my WNDR3800.
> I applied your two 4.4. patches manually to my sources.
> 
> As far as I could see from the LEDs, the router reboots before the failsafe 
> entrance point is reached. Behaviour looks similar as before your patches. (I 
> have been compiling and trying 4.4 monthly ever since nbd introduced 4.4 
> support for ar71xx initially and so far every attempt has been a reboot loop.)
Please try the updated version from my staging tree, it should work now:
http://git.lede-project.org/lede/nbd/staging.git

Thanks,

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] ar71xx v4.4 testing

[Arjen de Korte]

Citeren John Crispin :


i pushed a tiny patch to fix a regression which i believe was the root
cause for v4.4 not working for most folks. if anyone has time to test
please do so. i pushed the patches to my staging tree

http://git.lede-project.org/lede/blogic/staging.git

Please help with testing to see if this fixes the problem.


Hmmm. I don't know if this is relevant, but I have used v4.4 on my  
Netgear WNDR4300 for quite some time now. I took the plunge with  
OpenWrt r49195 (modified target/linux/ar71xx/Makefile to use 4.4). I'm  
currently running LEDE r170 on this device with no apparent issues.


Regards, Arjen


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] ar71xx v4.4 testing

[John Crispin]

Hi,

i pushed a tiny patch to fix a regression which i believe was the root
cause for v4.4 not working for most folks. if anyone has time to test
please do so. i pushed the patches to my staging tree

http://git.lede-project.org/lede/blogic/staging.git

Please help with testing to see if this fixes the problem.

John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Fwd: [PATCH 2/2] [ubox] logd: add ubus reload method

[Alexandru Ardelean]

Hmm, very weird.
My settings for GMail are to send email in Plain Text Mode and I still
got email delivery failure to lede-dev (for this message).

===
The error that the other server returned was:
550-Mailing lists do not accept HTML mail. See
550 http://david.woodhou.se/email.html
===

-- Forwarded message --
From: Alexandru Ardelean 
Date: Sat, May 14, 2016 at 11:05 AM
Subject: Re: [LEDE-DEV] [PATCH 2/2] [ubox] logd: add ubus reload method
To: David Lang 
Cc: Helmut Schaa ,
lede-dev@lists.infradead.org, Bastian Bittorf 


On Fri, May 13, 2016 at 11:40 PM, David Lang  wrote:
>
> On Fri, 13 May 2016, Alexandru Ardelean wrote:
>
>> On Fri, May 13, 2016 at 8:55 PM, David Lang  wrote:
>>>
>>> On Fri, 13 May 2016, Helmut Schaa wrote:

 I was thinking of a different use-case:
 Increasing the buffer size on the fly comes in handy during a debug
 session
 where you'd like to not interrupt logging (and thus potentially lose some
 parts
 of the syslog when restarting logd).

 Independent of how the implementation looks like I think the functionality
 would be quite useful.
>>>
>>>
>>>
>>> I don't think it's very valuable. If you are debugging, you really don't
>>> want to be tweaking anything in the middle of trying to capture data. you
>>> want to set everything up and let it run, then analyze the data.
>>>
>>> I don't see that changing the log size in the middle of a capture run is a
>>> good idea, let alone one that is common enough to have to introduce uci
>>> specific knowledge into the logd daemon.
>>>
>>> You are better off sending to a remote logserver anyway.
>>>
>>> David Lang
>>>
>>>
>>> ___
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>>
>> First of all, let's agree on a few things:
>> 1) the patch " [ubox] syslog: use realloc to change log buffer size ",
>> which precedes this, is an improvement over the existing code in logd
>> ; the initial code of logd, includes a logic to dynamically increase
>> the log buffer (using malloc() + memcpy()) ; there are 2 logical
>> options regarding that code:
>>   1.1) make it work (as that patch does)
>>   1.2) remove it
>> 2) there are people that don't need this ability to dynamically
>> increase the log buffer ; we do need it, but are not blocked by not
>> having it ; it would be neat to have in upstream ubox/logd, given that
>> logd was initially written with this ability partially intended;
>>
>> I don't know if this pushback is also amplified by my snappy reply to KarlP.
>> If it is, well, c'est la vie :) .  I lost an argument because of a
>> snappy come-back that upset some people. Wouldn't be the first time.
>>
>> I feel that this change [to dynamically increase the log-size] can be
>> achieved with minimal impact on code/binary size and logd behavior
>> (given point 1) ).
>> Normal operation should not be affected (or the patchset can be
>> adapted to less affect normal operation).
>> And then, if it's in, people can choose to use it or not.
>> Or, if it's too intrusive/bothersome, we can drop the patchset altogether.
>>
>> I'm still unclear yet how patch submission works in LEDE, and how
>> patches are accepted/voted, or who has the final go.
>> At least this process can shed some on light on that (for us).
>
>
> People don't object to the ability to resize the buffer if the code impact is 
> small, but when you start saying that you want to have logd understand/parse 
> UCI in the binary (as opposed to the script that starts the binary), the code 
> impact is not that small any longer.
>
> The use case isn't non-existant, but it is marginal.
>
> David Lang


@Felix, so then to conclude/converge. We keep the -S cli param, and
add a "size" ubus method that can return the current log size (if no
arg specified), and if an arg is specified, then update the log size ?
Something like:
- to read: ubus call log size   ==> output: {  size: 1024 }
- to write: ubus call log size  '{  "size" : 2048  }'  ==>  output: {
size: 2048 }

This would work fine for us as well.
I'm open to other modifications/simplifications as long as we can at
least write the new log size.

@David: I did mention in an earlier message in this thread, that I am
open/flexible regarding the UCI C change; that I am fine with with
replacing it with (inherently dropping it for) a ubus arg to the
reload method.
Somehow that message seems to have been missed, or if it's an issue
with infraread & GMail, let's fix that.
We're more interested in getting the log size dynamically increased
(if possible).

___
Lede-dev mailing list
Lede-dev@lists.infradead.org

Re: [LEDE-DEV] [PATCH] generic: New LEDE Banner

[Hannu Nyman]

The line with "... Reboot (%C, %R) ..." will fail in real use, as the %C and 
%R will be replaced with version strings. Currently there are short strings 
"HEAD" and "r222" that fit ok, but try applying "Designated Driver" and 
"r45678" and the line will overflow.


The contents of that line should be left empty after the "(%C, %R)" 
placeholder to allow flexibility.


Additionally, the card suit symbols look strange to me.


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] generic: New LEDE Banner

[Daniel Curran-Dickinson]

On 16-05-14 02:20 AM, L. D. Pinney wrote:
> + ___
> +/  /\   ██╗  ███╗ ██╗  ███╗
> +   /  Linux   /  \  ██║  ██╔╝ ██╔══██╗ ██╔╝  Linux
> +  / Embedded /\ ██║  █╗   ██║  ██║ █╗  Embedded
> + /  /  \██║  ██╔══╝   ██║  ██║ ██╔══╝Development
> +/__/  LE\   ███╗ ███╗ ██╔╝ ███╗
> Environment
> +\  \DE  /   ╚══╝ ╚══╝ ╚═╝  ╚══╝
> + \   Dev.   \  /
> +  \   Env.   \/  
> --
> +   \  \  /Reboot (%C, %R)   ♠ ♥ ♣ ♦lede-project.org
> +\__\/
> --

This doesn't look like 7-bit ASCII.  Are you sure it renders properly
everywhere?

Regards,

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [RFC] generic: Optional Command Line Prompts

[L. D. Pinney]

This patch sets the busybox prompt to the default. 
It also provides options to colorizes (or not) the command line prompt.
Also optional time display.

Signed-off-by: L. D. Pinney 

---

diff --git a/package/base-files/files/etc/profile 
b/package/base-files/files/etc/profile
index ad8fe12..3d03204 100644
--- a/package/base-files/files/etc/profile
+++ b/package/base-files/files/etc/profile
@@ -9,7 +9,14 @@ fgrep -sq '/ overlay ro,' /proc/mounts && {
 export PATH="%PATH%"
 export HOME=$(grep -e "^${USER:-root}:" /etc/passwd | cut -d ":" -f 6)
 export HOME=${HOME:-/root}
-export PS1='\u@\h:\w\$ '
+#export PS1='\u@\h:\w\$ '
+#export PS1='\t \u@\h:\w\$ '
+#export 
PS1='[\[\033[31;1m\]\u\[\033[0m\]@\[\033[32;1m\]\h\[\033\[0m\]:\[\033[33;1m\]$PWD\[\033[0m\]]\$
 '
+#export PS1='\t 
[\[\033[31;1m\]\u\[\033[0m\]@\[\033[32;1m\]\h\[\033\[0m\]:\[\033[33;1m\]$PWD\[\033[0m\]]\$
 '
+
+### COLORS ###
+# 31 = red ; 32 = green ; 33 = yellow ; 34 = blue ; 
+# 35 = magenta ; 36 = cyan ; 37 = white ; 38 = black
 
 [ -x /bin/more ] || alias more=less
 [ -x /usr/bin/vim ] && alias vi=vim || alias vim=vi

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] generic: New LEDE Banner

[L. D. Pinney]

This patch provides a new banner for LEDE

Signed-off-by: L. D. Pinney 

---

diff --git a/package/base-files/files/etc/banner 
b/package/base-files/files/etc/banner
index ae2f16f..7b19941 100644
--- a/package/base-files/files/etc/banner
+++ b/package/base-files/files/etc/banner
@@ -1,10 +1,11 @@
- _
-//\  ____ ___  ___
-   /  LE/  \| |  | __|   \| __|
-  /DE  /\   | |__| _|| |) | _|
- //  LE  \  ||___|___/|___|  lede-project.org
- \\   DE /
-  \LE  \/  ---
-   \  DE\  /Reboot (%C, %R)
-\\/---
-
+ ___
+/  /\   ██╗  ███╗ ██╗  ███╗
+   /  Linux   /  \  ██║  ██╔╝ ██╔══██╗ ██╔╝  Linux
+  / Embedded /\ ██║  █╗   ██║  ██║ █╗  Embedded
+ /  /  \██║  ██╔══╝   ██║  ██║ ██╔══╝Development
+/__/  LE\   ███╗ ███╗ ██╔╝ ███╗Environment
+\  \DE  /   ╚══╝ ╚══╝ ╚═╝  ╚══╝
+ \   Dev.   \  /
+  \   Env.   \/  --
+   \  \  /Reboot (%C, %R)   ♠ ♥ ♣ ♦lede-project.org
+\__\/--

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev