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

[Alexandru Ardelean]

On Fri, May 13, 2016 at 8:55 PM, David Lang <david at lang.hm> wrote:
> On Fri, 13 May 2016, Helmut Schaa wrote:
>
>> On Fri, May 13, 2016 at 12:03 PM, Bastian Bittorf
>> <bittorf at bluebottle.com> wrote:
>>>
>>> * Conor O'Gorman <i at conorogorman.net> [13.05.2016 11:52]:
>>>>
>>>> On 13/05/16 07:23, Alexandru Ardelean wrote:
>>>>>
>>>>> Short version is: we have a configuration management system on top of
>>>>> OpenWrt ; system boots with default settings (on every boot), and
>>>>> config management applies config changes (whether it's right after
>>>>> boot, or during system's normal operation).
>>>>> Maybe other people do something similar.
>>>>
>>>> Not many. Most people store the config, which is the current model.
>>>> It has benefits.
>>>
>>>
>>> We also have an approach like Alexandru, but i dont see
>>> the problem: logd starts at START='12'. Our config-thingy
>>> fires at START=01 and uci-sets all the stuffs. So we can still
>>> "rotate the knobs" e.g. uci set system. at system[0].log_size=64
>>
>>
>> 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 at 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).

Thanks
Alex