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

> Johannes Sixt <j6t@kdbg.org> writes:
> 
> > 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.