<div dir="ltr">Hi Artem,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I still don't see a reason to have two different applications in one<br>repository, but let's try.<br>I believe that the common part with socket opening/reading (about 100<br>lines of code) is nothing compared to the complexity of supporting<br>such sophisticated configuration in meson and bb files.</blockquote><div><br></div><div>Please take a look at <a href="https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-hostlogger/+/44241">https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-hostlogger/+/44241</a>. I made the HostLogger build the same binary but with different behaviour. In this way, no bb file changes are needed. It leverages existing socket reading, config reading, and dbus event loop. By default it doesn't affect the existing buffer based HostLogger at all.</div><div><br></div><div>Sincerely,</div><div>Nan</div></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 13, 2021 at 11:18 PM Artem Senichev <<a href="mailto:artemsen@gmail.com" target="_blank">artemsen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Jun 12, 2021 at 12:07 AM Nan Zhou <<a href="mailto:nanzhou@google.com" target="_blank">nanzhou@google.com</a>> wrote:<br>
>><br>
>> ><br>
>> >> > Or did me missing something?<br>
>> >> ><br>
>> >> > Also, we already talked about it: there's a problem that if BMC loses the<br>
>> >> > power before it sends out a signal to hostlogger, data in memory won't be<br>
>> >> > persisted.<br>
>> >> Yes, I agree that this is a problem. But there are ways to fix it without<br>
>> >> breaking the current functionality of Hostlogger.<br>
>> >> We can use rsyslog with external log server, or increase the buffer size<br>
>> >> in obmc-console-server, or use systemd-cat with logrotate.<br>
>> >> We can even add a new mode to Hostlogger that will not use the buffer, but<br>
>> >> as I said earlier, there are not many common parts.<br>
>> ><br>
>> > I guess you are arguing we need a new daemon rather than modify Hostlogger, right? +Ed Tanous here to see what his opinion is.<br>
>> If Nans use case is in fact totally different, and can't be handled in<br>
>> the same application I think that's ok, but I'd like to see the new<br>
>> application put in the hostlogger repo so it can share the routines<br>
>> that are common (things like finding and opening the unix socket,<br>
>> managing the reads, and the zlib integration) and to ensure that users<br>
>> find it when searching for code that solves this problem, as on the<br>
>> outset they're pretty similar, just with seemingly different rules.<br>
>> If we don't put it there, it seems like we'd have to duplicate a lot<br>
>> of code.<br>
><br>
> Thanks a lot for the previous discussion. Following up on this, is it acceptable if we add a new application (it will be a new binary + a new systemd service config) in the hostlogger repo to support the stream application? We can add options to control whether to turn on this new stream application. In this way, existing applications stay unchanged. As Ed said, we could use codes that deal with unix sockets and reads. It should also make sense that console codes are put together in the same place.<br>
><br>
> Please let us know what you think. Your confirmation will be very valuable and will unblock our development.<br>
<br>
I still don't see a reason to have two different applications in one<br>
repository, but let's try.<br>
I believe that the common part with socket opening/reading (about 100<br>
lines of code) is nothing compared to the complexity of supporting<br>
such sophisticated configuration in meson and bb files.<br>
<br>
--<br>
Best regards,<br>
Artem Senichev<br>
</blockquote></div>