From owner-freebsd-fs@freebsd.org Sat Jul 27 23:34:52 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9A18BC418C for ; Sat, 27 Jul 2019 23:34:52 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B77FC72C66; Sat, 27 Jul 2019 23:34:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f193.google.com with SMTP id v24so55055867ljg.13; Sat, 27 Jul 2019 16:34:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/AkSf8N9ltyZq4q4/w9U/FysaJENbLun9N+xMuTrzp4=; b=rGyEauI/deO5+fLFqkcEFBdWIFKWK66ZkMmU/7P5LdGqWUChptBlQkHlxXz7iyyq8d YW8pP10w3gaGT7dte1M/dJT0bZrLInFr2d7IIUvgX9t2aslAbgvwfpVquVUf1MX5BkmW bZb+fqnvnvKlbG9OZBE7sKu9s02N4OSaV0hpJgTww7m88FmfIWm6RwB8xAbO81TILHK2 pXSAlM7L8xNKyiMlQT4aC89Ivy189KhLZhDQry0dSJcYCsxkSOg20Ik4kYlalt1RnWSR roGQ9TYo19Y96uAPomweBN9AVgFs1VtwBj7Zdlyft/GmLyIYNLZs7rfHRmRR1hFptEZP 9iTg== X-Gm-Message-State: APjAAAU008Jy1NevPCege8KBFIUeplQl8I9Y5BeD31oAj0bowaYlONMR EGBKGdftCGtZVWAwEPdDQ/bldgKbgilMazVVxUuhXQ== X-Google-Smtp-Source: APXvYqzRDqe4arcKlB6i3faYrf1kAAFzbHJ0WLVqJnrD3T5V7ebSNvSs4WB0x6OfKYKjGeA2e4RbcyA8DbKBhsKmvaw= X-Received: by 2002:a2e:9dc1:: with SMTP id x1mr53868142ljj.0.1564270044321; Sat, 27 Jul 2019 16:27:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 27 Jul 2019 17:27:12 -0600 Message-ID: Subject: Re: RFC: should copy_file_range(2) use size_t or off_t for length argument To: "Conrad E. Meyer" Cc: Rick Macklem , "freebsd-fs@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B77FC72C66 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.193 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.97 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.70)[-0.699,0]; RCVD_IN_DNSWL_NONE(0.00)[193.208.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.27)[ip: (-0.44), ipnet: 209.85.128.0/17(-3.42), asn: 15169(-2.44), country: US(-0.05)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[193.208.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 23:34:52 -0000 I agree. Full compatibility is more important than a slight boost to efficiency. -Alan On Sat, Jul 27, 2019 at 11:17 AM Conrad Meyer wrote: > > Just my 2=C2=A2: keep the 1:1 Linux compatible interface. Requiring > programs to loop over N x 2^31 copies of larger files on 32-bit > platforms does not impose significant extra syscall burden on copy > programs over the wider off_t, and it fits the pattern of many > existing synchronous IO APIs (size_t lengths). > > I think there is some benefit to matching other OS's non-POSIX > function APIs exactly when we choose to use those same names and > concepts =E2=80=94 ifdef soup is painful. And developers target Linux fi= rst. > > Cheers, > Conrad > > On Sat, Jul 27, 2019 at 9:40 AM Rick Macklem wrote= : > > > > Hi, > > > > r350315 implemented a Linux compatible copy_file_range(2) syscall. > > Since Linux used a length argument of size_t and a return argument > > type of ssize_t, I did the same. > > > > Kostik has suggested that making these off_t would allow a full 64bit > > copy be done on 32bit arches. > > Here is the snippet of discussion we have had: > > Kostik Belousov wrote: > > > >Kostik Belousov wrote: > > >> >I sat to write the compat32 shims, and only then noted that len has= size_t > > >> >type. Why is it size_t and not off_t ? > > > I wrote: > > >> Well, that's what Linux did. > > >> > > >> Also, since it returns ssize_t, it can't do more than SSIZE_MAX > > >> (generally 1/2 of SIZE_T_MAX). Returning ssize_t is also what Linux > > >> does and is consistent with read(2)/write(2). > > > > > >If changing the length argument type to off_t, it is reasonable to cha= nge > > >the return type to off_t as well. We already have the lseek(2) syscal= l that > > >requires two return registers on 32bit. > > > > > >Note that it is reasonable for read(2) to take length as size_t-typed > > >parameter, because size_t is the type for object sizes. There is no > > >object in user address space for copy_file_range(2) API, so potentiall= y > > >wider off_t is acceptable and is in fact useful there. It is useful on > > >32bit machines where FreeBSD size_t is 32bit, while off_t is 64bit. > > > > So, what do others think? > > (My only concern w.r.t. changing the arguments to off_t is Linux compat= ibility.) > > > > rick > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"