From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v4] tools/libxc: Implement writev_exact() in the same style as write_exact() Date: Thu, 19 Feb 2015 10:23:09 +0000 Message-ID: <54E5B98D.8050804@citrix.com> References: <1424284314-3619-1-git-send-email-andrew.cooper3@citrix.com> <1424339351.30924.23.camel@citrix.com> <54E5B549.6050102@citrix.com> <1424341106.30924.44.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1424341106.30924.44.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Wei Liu , Ian Jackson , Xen-devel List-Id: xen-devel@lists.xenproject.org On 19/02/15 10:18, Ian Campbell wrote: > On Thu, 2015-02-19 at 10:04 +0000, Andrew Cooper wrote: >> On 19/02/15 09:49, Ian Campbell wrote: >>> On Wed, 2015-02-18 at 18:31 +0000, Andrew Cooper wrote: >>>> This implementation of writev_exact() will cope with an iovcnt greater than >>>> IOV_MAX because glibc will actually let this work anyway, and it is very >>>> useful not to have to work about this in the caller of writev_exact(). The >>> s/work/worry? >> Oops yes. >> >>> Will this still work with non-glibc libcs which do not cope with iovcnt >> Yes - observe the min() in the call to writev(). This code never >> actually breaks the writev() requirements, but allows the caller of >> writev_exact() to be more flexible. >> >>>> IOV_MAX? >>> In fact looking at the code it's not clear what glibc is letting work >>> anyway, do you pass a count > IOV_MAX to writev? Doesn't look like it. >> The page data algorithm in migration v2 submits 1024+7 IOV's at once for >> 1024 page frames and the associated metadata. It is specifically useful >> not to complicate that function with IOV_MAX adjustments in the case >> that IOV_MAX is 1024. > I see that, but where does "because glibc will actually let this work > anyway" come into it? This function will never actually pass > iovcnt>IOV_MAX to glibc, so I'm not sure what you are trying to say with > that statement in the commit log, since glibc is not being expected to > cope or "let this work" AFAICT. > > If what you are trying to say is that this function is more flexible > than the underlying writev implementation is required to be by POSIX or > something then you should just say that. Conflate it with the underlying > writev implementation coping with such things is just adding confusion > to the commit message IMHO. > > Ian. Now that you point this out, that part is stale, and more obviously applied to an older iteration of the patch. I will have a go at rewriting the message from scratch and see if I can come to something more appropriate. ~Andrew