Re: [Xen-devel] [PATCH v4] tools/libxc: Implement writev_exact() in the same style as write_exact()

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel