[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <27LHJ7Y2LTSTA.218670SJVIHRW@hera.home.vuxu.org>
Date: Wed, 17 Jan 2024 15:08:29 +0100
From: Leah Neukirchen <leah@...u.org>
To: musl@...ts.openwall.com
Cc: enh <enh@...gle.com>
Subject: Re: preadv2/pwritev2
Rich Felker <dalias@...c.org> wrote:
> On Tue, Oct 19, 2021 at 07:24:26PM -0700, enh wrote:
> > i've recently added preadv2(2) and pwritev2(2) wrappers to bionic, since we
> > had our first real prospective user come along, and they're mildly annoying
> > to use via syscall(3). unfortunately, this particular user also wants to be
> > able to compile for the host, and our glibc is years out of date, and our
> > current plan is to move to musl for the host[1].
> >
> > anyway ... musl doesn't have preadv2/pwritev2. i couldn't see any
> > discussion on the mailing list, so i thought i'd ask whether this is just
> > because no-one's got round to it yet, or there's some policy[2] i'm not
> > aware of, or what? happy to send a patch if it's just a case of "we haven't
> > got round to/had a need for it yet".
> >
> > ____
> > 1. TL;DR: being able to statically link without worrying about licensing is
> > very enticing, and gets us out of a lot of the compatibility issues we have
> > that made our last glibc update more trouble than it was worth, and means i
> > have no intention of getting us embroiled in another glibc update.
> > 2. i've been maintaining bionic for years now, and don't think i've written
> > down our policy explicitly. this was definitely a borderline case from the
> > "number of users" perspective, but for me the "annoying to use with
> > syscall(2)" tipped me over the edge into adding them. amusingly [or not,
> > depending on how you feel about "bugs you get away with"], it also made me
> > realize that our pread/pwrite implementations for LP64 were wrong in that
> > they weren't zeroing the unused half of the register pair. so that was a
> > bonus :-)
>
> There is high level policy for decision-making process for
> inclusion/exclusion. For new sycalls that are "safe" to use directly
> via syscall() it's not terribly urgent to take any action, but some
> like these would benefit from being cancellation points, which makes
> them somewhat compelling. If we do add them, I want to make sure we
> don't conflict with glibc's way of exposing them to applications (if
> they have one yet) -- things like the function signatures and how the
> flags are exposed. None of this looks hard to get right though. So I
> think it should be pretty straightforward to add these.
Bumping this, as bcachefs-tools now uses pwritev2.
glibc wraps the syscall with a cancellation point and also tries to
fall back to pwritev/writev when flags is zero and the original call
failed with ENOSYS. Vice versa for preadv2.
I didn't bother with the fallback since the call is there since Linux 4.6:
ssize_t pwritev2(int fd, const struct iovec *iov, int count, off_t ofs, int flags)
{
return syscall_cp(SYS_pwritev2, fd, iov, count,
(long)(ofs), (long)(ofs>>32), flags);
}
--
Leah Neukirchen <leah@...u.org> https://leahneukirchen.org/
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
