From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yufang Zhang Subject: Re: [PATCH] xenconsole: add file lock to xenconsole Date: Fri, 27 May 2011 11:20:54 +0800 Message-ID: <4DDF1896.5000704@gmail.com> References: <1306246402-12917-1-git-send-email-yuzhang@redhat.com> <19931.58936.294657.639013@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <19931.58936.294657.639013@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: pbonzini@redhat.com, Yufang Zhang , xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 05/25/2011 01:09 AM, Ian Jackson wrote: > Yufang Zhang writes ("[Xen-devel] [PATCH] xenconsole: add file lock to xenconsole"): >> This patch add a file lock to xenconsole for each console id, so >> that only one console could be attached to a guest at a time. >> Otherwise, consoles would get stuck and print strange outputs. > If only we had a better console protocol, it would be possible to > attach multiple times. Oh well. In the meantime your semantic change > is sensible. > > However: > >> +static int console_locked(const char *file) >> +{ >> + int fd; >> + > You need to use the same indent level and coding style as the > surrounding code. > >> + sprintf(buf, "/tmp/xenconsole-%d-%d", domid, num); > The lockfile should be in /var/run/xen. You should use snprintf. > Thanks Ian. Version2 patch has been sent, please review. > What arrangements do you plan to make for cleaning up stale lockfiles > (which I think will be left behind if the xenconsole client crashes) ? > Are we just going to rely on them being removed at reboot and apart > from that let them accumulate a bit ? > > Ian. Considering the lock files are just blank and can be reused, leaving them behind is not that bad? Yufang