From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id CEB312B6A7 for ; Wed, 17 Jan 2024 15:08:44 +0100 (CET) Received: (qmail 3482 invoked by uid 550); 17 Jan 2024 14:06:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3447 invoked from network); 17 Jan 2024 14:06:51 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705500511; x=1706105311; h=content-transfer-encoding:mime-version:organization:user-agent :message-id:in-reply-to:references:from:subject:cc:to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OtLSw0wXyA6AqGyQIk50qssYWrIuHNeCtTgbyZR/lzY=; b=KLlFs2OJHL2n1JK6qGmKT1xCaLgk80zS17gtb1SbcuiOMyGIaXkUsst9m9fylczQH5 Oyqg136tVfNBT2ISyecyY2CggQ8DZIFmPzc28nj06g7U3gG+G//utY0cc5mh9CBCiut+ VLucZg8OQuDvPBYzavsNfdlrB3oyEDudZO4aMNZcaHjoZ9akmFWLUyaEs9cI1doSHH9d xavFOlSepRUDNy1o1urI48VmoPQb4xSPCqBiolwnQAb4S95qcYPej5mKwDXkI7y8SXCc 8v0IKAYQQH+Uwca/R0lameiAi//31gPBggOVxul3jh893w3zFStkA+5o3eRVbvgpICPi UtiA== X-Gm-Message-State: AOJu0YxPAoVxlO7gjBh+BXgf0FZdM0RC48z19x42YiH9EYET7kb915sY QCDlUK2GvOXO3LfvRpSowng= X-Google-Smtp-Source: AGHT+IF4viFeQo9RJ2zpvIAXMNRsj8KN8kN5WvgkYr4gPFhec5Zme1No+Kx8QRQfmXg3SVdQMLDsow== X-Received: by 2002:a7b:c3c8:0:b0:40e:6922:6c7a with SMTP id t8-20020a7bc3c8000000b0040e69226c7amr4489962wmj.24.1705500510824; Wed, 17 Jan 2024 06:08:30 -0800 (PST) Date: Wed, 17 Jan 2024 15:08:29 +0100 To: musl@lists.openwall.com Cc: enh From: Leah Neukirchen References: <20211020181836.GP7074@brightrain.aerifal.cx> In-Reply-To: <20211020181836.GP7074@brightrain.aerifal.cx> Message-Id: <27LHJ7Y2LTSTA.218670SJVIHRW@hera.home.vuxu.org> User-Agent: mblaze/1.2-25-g5310c4e (2023-11-21) Organization: vuxu.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] preadv2/pwritev2 Rich Felker 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, sinc= e we > > had our first real prospective user come along, and they're mildly anno= ying > > to use via syscall(3). unfortunately, this particular user also wants t= o be > > able to compile for the host, and our glibc is years out of date, and o= ur > > current plan is to move to musl for the host[1]. > >=20 > > 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 ju= st > > 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 hav= en't > > got round to/had a need for it yet". > >=20 > > ____ > > 1. TL;DR: being able to statically link without worrying about licensin= g 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 mea= ns 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 wri= tten > > 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 th= at > > they weren't zeroing the unused half of the register pair. so that was = a > > bonus :-) >=20 > 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); } --=20 Leah Neukirchen https://leahneukirchen.org/