From owner-freebsd-hackers@freebsd.org Fri Oct 2 04:25:15 2020 Return-Path: Delivered-To: freebsd-hackers@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 973743F54F1; Fri, 2 Oct 2020 04:25:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on0616.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::616]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C2cNV2cwTz46lM; Fri, 2 Oct 2020 04:25:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l07uyznkvUjREQ7PYIne+S16X2pQnG0HK/4WyRyTQhVEXBMWmdeUyTe/jjHSWkh335g6DvEurKCEqo4LKH5Ey5zyfUgNUgL4zuM7eZioynUS0nQb8pXZ4vsB5zuwLo9K6rdn6NzldCBDFuxMAKn/GXXSef2eB5t/VZkjZWdTLnT8P+4E5N6eep6AYifjNdcBhLkUCbd3czZSoIjEVUlFwLAqCuYHYYhlNQBkfaPSJ+TbmvvqxmexWb2Jo/kuDiSiA+0AnHBMqsZXZ4SRado38bbehpwK6gluo1RUQ4H/NlDfhSuzSJqU4XEaqRuh8aKCh98RDBcSkorrUyvlgs43hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jg4YNQMy554FWRZJQma1s496zGXbeUsGCi5dTZyESFM=; b=gATcj4ldM1WNcH5vh2VfWLy2MnQdDWJKbPUeiExV3+nmcCjYDvtLq2ldhpCvd2BxJFEiWJALHXWckGcyFfIoTginDt+yadWlJIBVyORu2neNniM9J9EciMRgMP7ITCvahexD5YkDYHEtZT2OAArkDbqMEFyCQTNuVg6vIK4uM18YggwbLBCObvR2cNJ41oRE02TCiboqglAxd4B/f4ZA+CpI+anzey4F8KFVV15h415f2neOqKZi8ouQlHswk9gYUBl1ZO+hs1/UzWuz7pCwLnw0qF9FUemfTQX8hxfjEvLHathLVTLPkHHZasyAF93gQ0eFXnngPIRHQXRfaI410g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jg4YNQMy554FWRZJQma1s496zGXbeUsGCi5dTZyESFM=; b=i4wDLtSpGUVRaPrMDI43swUB4Uihygcy19YDXCthHWHOPnGaUMIDnt4gmMjcjRaanBZ8yy5JOQixXxFkj7DA/+IrcwUeSshYdJwKxG6wgQt8Qjyqn8b6I/ZqCofHoMPvRZptxApo4OWJ/sfapxUnlYEJBgyLKaIdQ9Hr4AHaH+bl4t8xuvgurHJ4Rdrzcn8h5//LoJAr1dzUFBGViVh5g1QjX1Kapw4xKLq7+vKmuqhl9r2eFDhjuEkz3Veb2gBEULvyB2LeUwkcRz35wLGg9O3MVMyVYUiUUiL81Xu9YdEecwRzVzh4NbVsaCwXXmb15tszZ0DEeTDQoNzNR5qHBA== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YT1PR01MB2426.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:3::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.38; Fri, 2 Oct 2020 04:25:10 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3433.034; Fri, 2 Oct 2020 04:25:10 +0000 From: Rick Macklem To: Mateusz Guzik , Alan Somers CC: "Wall, Stephen" , FreeBSD Hackers , "freebsd-current@freebsd.org" Subject: Re: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Topic: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Index: AQHWlFwtm/+ImGEdKkCaptKgpElFK6l7nDvmgAAr7eCAALVoToAADHSAgAAPsQCAByNZ/w== Date: Fri, 2 Oct 2020 04:25:10 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6f8cfe24-4071-4626-6b0f-08d8668b26a6 x-ms-traffictypediagnostic: YT1PR01MB2426: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wnEijiPQNmKWL/w6bf6UwXF9jO/LEF8pHl9ASoio1k14KrrI7Q5VN63myyqrOFs9S4qtNgpqGet+QBuhncWtMdTLh/U4+oHQU9ieyFTrhIKPe4JyW1VIgYKxfkNTtU/g8IQC6ycmEICqgd/EIGBJCnZ24PWBPmuR+NY2A5sC1tCUdFUWpjJgO2HVACQKAmyZWntwfZ2D4JwxB++j4HKQf8P2zDOtRTSjPczGKe8rxsUEDLWZRjoUadTWgc2xpdMfM9sb8v20gG/OB11H10+3bR98mOCQvSV5UpXDsDyIxkxt42jXqJQ1iyUjE4xGoWEI1w+CBHaUKzHyHL/shy1ajg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(396003)(39860400002)(366004)(8676002)(316002)(478600001)(786003)(8936002)(71200400001)(86362001)(55016002)(9686003)(33656002)(4326008)(66476007)(64756008)(186003)(53546011)(5660300002)(52536014)(6506007)(91956017)(66556008)(66446008)(7696005)(76116006)(66946007)(110136005)(54906003)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: o8B8LqTu5O7Fh5witrF10soGGLt6jY1mpbviW5AhuB7KZLjlfReq+tDCXgkhIwWdIMJwPlqqU5uuFSVq/jJxeqMKujpzLcHuF50lVqOULdshFVf/W18OrAKTmGUIizgHgQb2GsclXLeHBJg+0KGZr6CmNEcKTMcTkj8/M4ClR3TrP1m+IBkN7OLkPQuWKFUsZTOGymknBYURcyMgnuC0SGLq4xlyAjyYsm9f9ElGjGdyXIt0Kcq5vspt6WWjfpiUjp9zkeOqGauC6ExzxBDaJB2Zpb9tsLiAfHRFkg0jVN0iPS6swFm5TlR0FIAQjp9u6FYJlr97CcxnGZH1T5Xu6rUYl1k+uIT9lMCUiXtzPQ3G1HvCOsgodExagVvHq8uZaSy1cSGNmANHDEkd1o+T6dzzRJai9apLMRzHnq2iWjJYZqhBq9ILpjora03TJhmGd7LTn8DOJ1VzEaCaaqgO46Lw11edh8egfKoPwUZKrW9qFNFViRtBAKjYyIw86gKl9Rvl247moacvc60SpJ2aDZOrITlvJx8wsPotK6OtDjW6GimQbevWHohqqOsYLiWDXwpNXGDKb8IITgnKnh1FkaLovkq38mOVzTii9rBhJohLQBwyBR5mRAcaeJSdUnGlRbogpEkrqjxrSL5DgVk3yl51rucopFiU/OzCQnoWjwgVhOdH3W52OjVvllm2NJZsxKoGivKlyuhIVDYZKzzW5w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 6f8cfe24-4071-4626-6b0f-08d8668b26a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2020 04:25:10.7243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MOijainVIaVzHok/RiYQxAqsrmFx4U7uripkRG0JSLWqbfG2PkDUMO6Nby0ESp2RQW+io/GxqZfMO0CGg07evQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB2426 X-Rspamd-Queue-Id: 4C2cNV2cwTz46lM X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=i4wDLtSp; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5c::616 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.07 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.026]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; NEURAL_HAM_LONG(-0.94)[-0.937]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_FIVE(0.00)[5]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.10)[-1.103]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 04:25:15 -0000 Mateusz Guzik wrote:=0A= >On 9/27/20, Alan Somers wrote:=0A= >> On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen = =0A= >> wrote:=0A= >>=0A= >>>=0A= >>> > I'll assume you are referring to the "flags" argument when you say=0A= >>> "param" above.=0A= >>>=0A= >>> Correct, I was misremembering the man page.=0A= >>>=0A= >>> > However, since the Linux man page says it will return EINVAL if=0A= >>> > the "flags" argument is non-zero, you've still introduced an=0A= >>> incompatibility=0A= >>> > w.r.t. the Linux behaviour.=0A= >>>=0A= >>> This would be a one-way incompatibility, i.e. code written on linux wil= l=0A= >>> run unaltered on FreeBSD.=0A= >>> If the flag were along the lines of `FREEBSD_COPY_DEVICES` (or whatever= ,=0A= >>> important part is `FREEBSD`) it will be quite obvious that this code=0A= >>> needs=0A= >>> to be adapted to other platforms:=0A= >>> ```=0A= >>> #ifndef FREEBSD_COPY_DEVICES=0A= >>> #define FREEBSD_COPY_DEVICES 0=0A= >>> #endif=0A= >>> ```=0A= >>>=0A= >>> > Why require extra work for so little purpose?=0A= >>>=0A= >>> I'm sorry, I'm not sure what extra work you are referring to. Specifyi= ng=0A= >>> a flag on copy_file_range(2)? That's trivial.=0A= >>>=0A= >>=0A= >> It's easy to leave out, which could cause a lot of pain for users who do= n't=0A= >> understand why their application isn't working.=0A= >>=0A= >=0A= >A FreeBSD-specific flag to a Linux-alike syscall is bound to run into=0A= >a conflict at some point, making it a non-starter.=0A= >=0A= >>=0A= >>>=0A= >>> > My opinion is that if we can make it work for character devices, we= =0A= >>> should.=0A= This turns out to be a lot messier than I thought it would be.=0A= For example: /dev/zero cannot be read via VOP_READ() on the vnode.=0A= To read it, you must us dofileread() on the file descriptor.=0A= --> This implies a separate copy loop from the one implemented by=0A= vn_generic_copy_file_range(), which works on vnodes. (And that needs to= =0A= remain, because the NFS server only has vnodes and no open file descrip= tors.=0A= =0A= At least that appears to be the case when I tried it and then looked in=0A= sys/fs/devfs and sys/dev/null when it didn't work.=0A= =0A= rick=0A= =0A= >>=0A= >> Well, collecting opinions was the point, no? :)=0A= >>=0A= >> What's going to use this function besides system commands? I think I sa= w=0A= >> `cp` and `dd` mentioned - I think it unlikely you need to be concerned= =0A= >> about their portability.=0A= >>=0A= >=0A= > Userspace RAID-like applications could use it for rebuilds, and they'll= =0A= > need it to work on device nodes. Userspace NFS servers and iSCSI servers= =0A= > could obviously use it. And since the FUSE protocol includes a=0A= > COPY_FILE_RANGE operation, many FUSE daemons could implement that with=0A= > copy_file_range(2).=0A= =0A= I think the first thing to do is check what Linux is doing here, most=0A= notably they may have other primitives to take care of it and in that=0A= case would be best to implement equivalents.=0A= =0A= I don't have a strong opinion on VCHR support. I will note there may=0A= be Linux code expecting to fail with such argument.=0A= =0A= If Linux-compatible approach mentioned above is not going to work out,=0A= I think the best thing to do is to add another syscall=0A= (copy_file_range_np?) which can be tweaked however we see fit.=0A= =0A= --=0A= Mateusz Guzik =0A=