On 07/06/16 11:34, Wei Liu wrote: > On Tue, Jun 07, 2016 at 11:29:31AM +0100, David Vrabel wrote: >> On 07/06/16 11:21, Wei Liu wrote: >>> On Tue, Jun 07, 2016 at 11:17:07AM +0100, David Vrabel wrote: >>>> On 07/06/16 10:55, Wei Liu wrote: >>>>> On Tue, Jun 07, 2016 at 10:44:50AM +0100, David Vrabel wrote: >>>>>> On 06/06/16 16:59, Wei Liu wrote: >>>>>>> Wei Liu (6): >>>>>>> xenconsoled: introduce log file abstraction >>>>>>> xenconsoled: switch hypervisor log to use logfile abstraction >>>>>>> xenconsoled: switch guest log to use logfile abstraction >>>>>>> xenconsoled: delete two now unused functions >>>>>>> xenconsoled: options to control log rotation >>>>>>> xenconsoled: handle --log-backups 0 in logfile_rollover >>>>>> >>>>>> What not use syslog and/or logrotate? >>>>>> >>>>> >>>>> It's cumbersome to setup per guest facility for syslog. We don't want >>>>> console log from different guests mix together in one file. >>>>> >>>>> Logrorate runs periodically. It doesn't actively limit the disk space >>>>> consumed. >>>>> >>>>> The combination of syslog and logrotate can't prevent a guest from >>>>> filling up Dom0 disk as far as I can tell. I'm happy to know if there is >>>>> some sort of simple configuration we can ship with open source Xen. >>>> >>>> Ok. Found the other thread now. >>>> >>>> We should just use virtlogd instead of re-inventing the wheel. >>>> >>> >>> As in importing that to our own tree (potentially a fork)? Provide >>> interfaces to let system administrator configure that (need to at least >>> check if it provides stable interfaces)? >> >> Of course not! It would simply be an external dependency. >> >>> Not to mention to use that we need to add dependency to some sort of RPC >>> library in our toolstack. >> >> So? >> > > That's something I would like to avoid if possible. This is just for > guest console logging. It's definitely not a good idea to add that to > xenconsoled.
Why is it a bad idea to make use of an existing solution? David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel