From mboxrd@z Thu Jan 1 00:00:00 1970 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=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8800 invoked from network); 20 Oct 2021 02:24:54 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Oct 2021 02:24:54 -0000 Received: (qmail 17660 invoked by uid 550); 20 Oct 2021 02:24: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 17624 invoked from network); 20 Oct 2021 02:24:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=pOyCubF2xQFZ2x8os/EdJnlBTXCkjiNUL/MYAz1pzp4=; b=coFGLJcLhiXbHeId7HmcxN4rXLbfqB4kv11YOma5xWta8dSh3JUJN1+kNoWcZi03dW N//dfWP1rpAhvjZNPMOCSIWTIrdnsz1hY4zK47iAr5oaglQ3fZMJAt7c5/hkAwKzPjNC 1O1iCOK30dDEgu4hA7M1ALkeBNiUMbpBmqg/OezQ2EBfGaGtAyzb/XYAiQSFOOwzsYY4 d5E9G69/SG3T+NNuEstou6vLPn5sbcxzm1nMHUJq8llLf8rbtwh26NA9g8jDJHeuMYRW ofy8T6tJ3TVjxeAgV6mgHA/T2hfHLm4ueSr9qskiDcZqmF/4VeV+zVxwJEwFkuVnD6UM laVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pOyCubF2xQFZ2x8os/EdJnlBTXCkjiNUL/MYAz1pzp4=; b=xN02cVorRpgCdFiuK3JwKMXnjl+ixMVze5W8ven5bN/7jtBjSduJjL2+fi+DffWJNv 9W8cMq53eTOK+r3jpdpot9RDXIHFsEzlnJVLUgYauUygGGWMXHbKnveG4VlzZk22UrjC i21e6OQUW3I5k1qtf4tOtMUQwTTV9NSl9Y4+SjduYlxD/Mk7IEfH1SScEc10nAHfxY3+ Czn8L5FpXMTksNapCRTzjb5kIENXc6JkI+z8q6dpfKCDvzrZJEAaDJQ71sq6xV6Go+Sz smoRiWdr7wbv+HwsqUvwfhcX5WUyE9iW9L64dE2SBAuQ95gk0YJ6TGpOoW4h2hCmOhga A2DA== X-Gm-Message-State: AOAM531u4W4eOxvRLQeTRtrR7pHjRfF8mFk+V+xQnOsjqhJcAgMoRpPn Cv+6ynmcyCrk2iqVAAeXg5qoXG9foi2hBQqVRnGhPGFomFkAyA== X-Google-Smtp-Source: ABdhPJwPE6hkY5lwcEAbXbsKCdssZdGOvow3+YdkJCF3jE4/1tPvSmuHoWbIK05S1zMnLS1ycVHXu7fCA+PHK7Zt8xQ= X-Received: by 2002:a05:6e02:1cab:: with SMTP id x11mr22041138ill.311.1634696677971; Tue, 19 Oct 2021 19:24:37 -0700 (PDT) MIME-Version: 1.0 From: enh Date: Tue, 19 Oct 2021 19:24:26 -0700 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000ceb34005cebf7aff" Subject: [musl] preadv2/pwritev2 --000000000000ceb34005cebf7aff Content-Type: text/plain; charset="UTF-8" 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 :-) --000000000000ceb34005cebf7aff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i've recently added preadv2(2) and pwritev2(2) wrapper= s to bionic, since we had our first real prospective user come along, and t= hey're mildly annoying to use via syscall(3). unfortunately, this parti= cular 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/pwri= tev2. 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, o= r 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 n= eed for it yet".

____
1. TL;DR: bei= ng able to statically link without worrying about licensing is very enticin= g, and gets us out of a lot of the compatibility issues we have that made o= ur last glibc update more trouble than it was worth, and means i have no in= tention 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. amu= singly [or not, depending on how you feel about "bugs you get away wit= h"], 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 re= gister pair. so that was a bonus :-)
--000000000000ceb34005cebf7aff--