On Thu, May 12, 2016 at 5:49 PM, Karl Palsson <ka...@tweak.net.au> wrote:
>
> Alexandru Ardelean <ardeleana...@gmail.com> wrote:
>> On Thu, May 12, 2016 at 5:30 PM, Karl Palsson
>> <ka...@tweak.net.au> wrote:
>>
>> >
>> > Dan Bugnar <danut...@gmail.com> wrote:
>> > > From: Dan Bugnar <danut...@gmail.com>
>> > >
>> > > 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.
>> >
>> >
>> > Why do you need this exactly? It's already being parsed from the
>> > config file by the init script, and that is much less code than
>> > adding all of uci parsing into logd?
>> >
>> >
>> Doing a reload on logd (to increase the buffer size), should
>> not clear out the previous log info. By default logd's reload,
>> is a logd restart. The end game is to do a proper reload, and
>> keep whatever info was logged, before the reload (if doing a
>> log buffer increase).
>
> And that's something that you want to do, at run time, often
> enough that you want to add config file parsing to it? I mean,
> ok, I understand what you're saying, but is that really a useful
> usecase? changing log size dynamically?
>
> Cheers,
> Karl P

Regarding the UCI parsing in C, that's an open discussion, where I'd
be flexible for just passing the new log size via a ubus parameter and
keeping the UCI parsing in shell.
I wouldn't debate much on this.
Anything that allows the passing of the new log-size to the realloc()
code is fine for us.

Changing the log size dynamically at runtime is a use case that we have.
Ideally, it would be nice if we could also keep some some log info
when log-size is reduced (the more recent logs), but we don't have
that use case yet.
And the code for that would be a bit more complicated.

>From the looks of it, logd already has some code that looks like it
was intended for increasing the log size.
It was written, but doesn't work, and never gets executed.
See patch:  [PATCH 1/2] [ubox] syslog: use realloc to change log buffer size

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

Reply via email to