Re: [PATCH 0/5] Reintroduce writev(3p)

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 27, 2026, 15:44 UTC
Message-ID: <xmqqo6fso2s8.fsf@gitster.g>
In-Reply-To: <f8050598-392f-44c9-8d66-0454740a7a12@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 12 quoted lines

> Am 16.07.26 um 09:52 schrieb Patrick Steinhardt:
>> this patch series reintroduces the writev(3p) wrapper. This wrapper was
>> originally introduced as part of Git 2.54 [1], but was ejected due to
>> issues on NonStop [2].
>
> Please don't call the function "writev" so that nobody associates it
> with the guarantees that only POSIX provides, but none of the
> emulations. Call it "write_gather", for example.
>
> Also, clearly document that its only purpose is to reduce sequences of
> write() calls to a single function call, but that the additional writev
> guarantees are not needed.

It is philosophically more "pure" to have a two-level abstraction where write_gather(), which may be inspired by writev(2) but with specific subset of semantics that the application needs, is used by the application and have platforms with good enough writev(2) to implement it in terms of it. Other platforms may implement it differently, like a series of write(2) calls, and as long as it fulfills the need of write_gather(), we are OK.

Doing so would also help in a minuscule way to avoid adding to the complaints we sometimes hear that our internal implementation assumes platform support for POSIX API and semantics way too much even when we do not need to.

So I do not mind going in that direction. It feels a slightly roundabout approach, but in the longer run, I think it would place us in a much better place.

I think Patrick's writev(2) follows the pattern our previous compat/ routines have taken. We use real writev(2) where it is available, and in the fake implementations in compat/ we have comments that essentially say "the real function offers X, Y, and Z, but we only want X and Z and do not need Y, so this implementation does not support Y". It is harder to maintain because the application side may be tempted over time to start depending on Y. If some platforms cannot easily provide an equivalent of the real function, it is easier for them if the rules explicitly state from the beginning that we do not require and will never require Y, needing only X and Z from either the fake or real implementation.

At that point, we are not describing the real function anymore, so your proposal to give it a specific name is one step away from that, and that step is in the right direction.

Thanks.

PS. I was going over the list of "waiting for response" topics, and this was one of them. I suspect Patrick and the GitLab team are still away at an offsite [*], so this is in no way poking him for an immediate reroll, but rather a note sent while my attention is on these stalled topics.

https://lore.kernel.org/git/amLgMqkqxR8mKIbT@pks.im/