From owner-freebsd-current@freebsd.org Sun Sep 27 15:16:50 2020 Return-Path: Delivered-To: freebsd-current@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 8F17D3FE0A2; Sun, 27 Sep 2020 15:16:50 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Bzq4d3nmWz3cFP; Sun, 27 Sep 2020 15:16:49 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wr1-x441.google.com with SMTP id k15so8944103wrn.10; Sun, 27 Sep 2020 08:16:49 -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:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nYAWEbKSLZu/2ZxBG1Do56H/lS5xBsAeuocCuW1wpc4=; b=kRarqAcd7w/4ZppqxzJUXX4u0umjuOc/RSXxyF20E/nUT2kmCvajOkoNJzou3sMfC8 9XXvdPR4Z8N0ZYBY/XZqKW/SN0QvDGvpyCAmXrs77hPz6W1f6FCqykD8/O0PWabTE0UP eQUmKSzkQbs9j1ImfQUWZxHO91GQ97wEttcQhlO10MaiAJWQTeD4FouKS8agyuqnI1mi eUZBv9E9KI7Dxjua5hqgakGyy6DhwmIDR2sytXWwJBXFm4wcV170NJ/Y9+eDvojPAQiu 78+wFQ3ZI4oZ7kLX3KbVEA3SgYSfospONFZ6q4IrzaNpKxSx/6RJFFQ+GRuNB4X/jICH 0mpA== X-Gm-Message-State: AOAM530I16Q5ABs3Z+lih0KtK7IhqPR14UotWXpEaJQBqkImb7UQp3S/ mZcpkpxgAHgTVW/O6gSKlFZKKlrt5exNjnU0qFp0lf3zNOw= X-Google-Smtp-Source: ABdhPJxqID61zylEJYpBYeaQ3JHLbpBDsDgNQgK+wHcKtt22kvnTZVIMVbzAksfgpIVfpVdSFuVHmrznruJyusFuiZg= X-Received: by 2002:adf:e84a:: with SMTP id d10mr15369002wrn.66.1601219807770; Sun, 27 Sep 2020 08:16:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6000:187:0:0:0:0 with HTTP; Sun, 27 Sep 2020 08:16:46 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Sun, 27 Sep 2020 17:16:46 +0200 Message-ID: Subject: Re: RFC: should copy_file_range(2) remain Linux compatible or support special files? To: Alan Somers Cc: "Wall, Stephen" , Rick Macklem , FreeBSD Hackers , "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Bzq4d3nmWz3cFP X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.57 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.02)[-1.019]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::441:from]; NEURAL_HAM_SHORT(-0.56)[-0.560]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 15:16:50 -0000 On 9/27/20, Alan Somers wrote: > On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen > wrote: > >> >> > I'll assume you are referring to the "flags" argument when you say >> "param" above. >> >> Correct, I was misremembering the man page. >> >> > However, since the Linux man page says it will return EINVAL if >> > the "flags" argument is non-zero, you've still introduced an >> incompatibility >> > w.r.t. the Linux behaviour. >> >> This would be a one-way incompatibility, i.e. code written on linux will >> run unaltered on FreeBSD. >> If the flag were along the lines of `FREEBSD_COPY_DEVICES` (or whatever, >> important part is `FREEBSD`) it will be quite obvious that this code >> needs >> to be adapted to other platforms: >> ``` >> #ifndef FREEBSD_COPY_DEVICES >> #define FREEBSD_COPY_DEVICES 0 >> #endif >> ``` >> >> > Why require extra work for so little purpose? >> >> I'm sorry, I'm not sure what extra work you are referring to. Specifying >> a flag on copy_file_range(2)? That's trivial. >> > > It's easy to leave out, which could cause a lot of pain for users who don't > understand why their application isn't working. > A FreeBSD-specific flag to a Linux-alike syscall is bound to run into a conflict at some point, making it a non-starter. > >> >> > My opinion is that if we can make it work for character devices, we >> should. >> >> Well, collecting opinions was the point, no? :) >> >> What's going to use this function besides system commands? I think I saw >> `cp` and `dd` mentioned - I think it unlikely you need to be concerned >> about their portability. >> > > Userspace RAID-like applications could use it for rebuilds, and they'll > need it to work on device nodes. Userspace NFS servers and iSCSI servers > could obviously use it. And since the FUSE protocol includes a > COPY_FILE_RANGE operation, many FUSE daemons could implement that with > copy_file_range(2). I think the first thing to do is check what Linux is doing here, most notably they may have other primitives to take care of it and in that case would be best to implement equivalents. I don't have a strong opinion on VCHR support. I will note there may be Linux code expecting to fail with such argument. If Linux-compatible approach mentioned above is not going to work out, I think the best thing to do is to add another syscall (copy_file_range_np?) which can be tweaked however we see fit. -- Mateusz Guzik