From owner-freebsd-current@freebsd.org Sun Sep 27 14:20: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 B7F443FCC48; Sun, 27 Sep 2020 14:20:50 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (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 4Bznr15ZM2z3Z1L; Sun, 27 Sep 2020 14:20:49 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f41.google.com with SMTP id o8so7056007otl.4; Sun, 27 Sep 2020 07:20: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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HSgDPQJ/DVFSle5/qEn+0pp2/+CBLxzl8FleFedPxuE=; b=JNcktGBxpQD0iKsj/FZOcSBLawxn57cet2Y6HC3vnmN7LCqp8/e57QTLyh+3o5r8+w VPEeSDZx6srqAhJ9cU14We8LrM13z5Rwdj4WCSed5uN39p1VUbN7iKQRC6cKfcF8UBU+ dRUz7kISGbo8t2DEioC6P3/0VVLkIzE+FK7nEIKxbZM6gc+V3kN5U6vyJoQfA3D5C0Gd pKW4dI8JNqWgjbdljCENemDzzD0HughhmvsYYOoskXoN+HHJo2iROfTzG1ybki0yM2Kr dzK5M5AJmXBCegBOeG6IZr5wrvAXSc9NCzAzA/WQ+4ljmtZAR1XqlGv52xPq2EJ5ltom R2iw== X-Gm-Message-State: AOAM533QnM9+CYJoU+iEHV6eCRpVZgsJ5vl9jiQO4IbOijGT9TnaH+65 x0awEeVU/kJi/9acryZrFHF7TWFt9V2Edldy34c= X-Google-Smtp-Source: ABdhPJwTgQPY2NBamRDshrvXK6WiPpC1LeceDUAH/1vEOPzZn8j2NaZYaWhFXItDPkvpem9mRIFkTxNU4znxI2Y1sjg= X-Received: by 2002:a05:6830:1286:: with SMTP id z6mr5893487otp.291.1601216448720; Sun, 27 Sep 2020 07:20:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sun, 27 Sep 2020 08:20:37 -0600 Message-ID: Subject: Re: RFC: should copy_file_range(2) remain Linux compatible or support special files? To: "Wall, Stephen" Cc: Rick Macklem , FreeBSD Hackers , "freebsd-current@freebsd.org" X-Rspamd-Queue-Id: 4Bznr15ZM2z3Z1L X-Spamd-Bar: - X-Spamd-Result: default: False [-1.37 / 15.00]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; ARC_NA(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.41:from]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.01)[-1.014]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.38)[-0.379]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.41:from]; NEURAL_HAM_MEDIUM(-0.98)[-0.981]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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 14:20:50 -0000 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. > > > 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). -Alan