On Fri, Jun 01, 2007 at 07:35:00PM +0900, Nobuhiro Itou wrote: Hi Nobuhiro, I guess you still think of a single log file shared by multiple virsh run, and honnestly I think this adds way too much complexity and is not really useful. You have one log file per virsh run. It's the responsability of the user to pick a log file name. Trying to reinvent syslog at the level of virsh does not sounds right to me, or rather it makes what should be a small patch something really complex instead, I am not sure it is worth it. [...] Honnestly I don't see the need for a lock. The filename is provided by the user, I would not add this extra layer there. typo, message :-) Drop the lock, then you just have the fd, then you don't need a structure and everything is way simpler. [...] I am not 100% sure you can actually reuse ap again without doing the va_end(ap) and va_start(ap, format) again. This may work in some case but break on some implemntations. same here [...] hum, I don't see why you would prevent relative paths for log files from a virsh run, except it makes simpler to compute the path to the lock file, but agains let's just get rid of that lock. I would not do that kind of test. Open the file for writing, if it fails emit an error and return. This is way too complex. I certainly do not want to create directories just because an error was made typing the path to the log file. This doesn't make much sense to me. Try to open the file for writing, if it fails, error out, that's all. That could be kept but IMHO this is still more than needed. Please drop the lock. Locking would have been needed if virsh required using the same file names. Now the user provides the file name, it's his responsability to get it right. [...] drop locking. Anyway intermixed output from multiple run is unlikely to be very helpful, actually more a source of confusion than help in my optinion. [...] saving the time is okay. I don't think sharing log files for multiple run helps in any way, so no need to put the pid in... [...] I would not bother with the log size either. Just dump to the file. If the output is big well the user will probably need all of it to sort out the problem, but basically it shouldn't grow very large if it is not shared between virsh runs. I expect the use to be the following: - users uses virsh for virtualization operation - something suddenly does not work - then he re-runs the command with logging - then he can analyze the log or transmit it to a sysadmin who can have a look but I don't believe in reimplementing something like syslog within virsh to log all operations all the time, especially with a fixed size buffer. logs will be intermixed, hard to process, add a burden on the server, and makes the code way more complex than it needs to be. Maybe I didn't understood how you expected logging to work, but apparently we had different viewpoints, I would rather go for the simplest, does that still work for your use case ? Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/