From patchwork Thu Feb 6 14:29:18 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Disseldorp X-Patchwork-Id: 3596371 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 6AF60C02DC for ; Thu, 6 Feb 2014 14:29:28 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B764F20131 for ; Thu, 6 Feb 2014 14:29:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D824F200F2 for ; Thu, 6 Feb 2014 14:29:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755219AbaBFO3X (ORCPT ); Thu, 6 Feb 2014 09:29:23 -0500 Received: from cantor2.suse.de ([195.135.220.15]:43682 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754284AbaBFO3W (ORCPT ); Thu, 6 Feb 2014 09:29:22 -0500 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 04304ABB3 for ; Thu, 6 Feb 2014 14:29:22 +0000 (UTC) From: David Disseldorp To: linux-btrfs@vger.kernel.org Cc: David Disseldorp Subject: [PATCH] ioctl: add note regarding CLONE_RANGE(len=0) behaviour Date: Thu, 6 Feb 2014 15:29:18 +0100 Message-Id: <1391696958-4522-1-git-send-email-ddiss@suse.de> X-Mailer: git-send-email 1.8.4.5 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP A BTRFS_IOC_CLONE_RANGE request with a src_length value of zero has the effect of cloning all data from src_offset through to end-of-file. Document this behaviour in the header file for those who (like me) incorrectly assume that no data is cloned in such a case. Signed-off-by: David Disseldorp --- ioctl.h | 1 + 1 file changed, 1 insertion(+) diff --git a/ioctl.h b/ioctl.h index a589cd7..f7d435d 100644 --- a/ioctl.h +++ b/ioctl.h @@ -506,6 +506,7 @@ static inline char *btrfs_err_str(enum btrfs_err_code err_code) #define BTRFS_IOC_SCAN_DEV _IOW(BTRFS_IOCTL_MAGIC, 4, \ struct btrfs_ioctl_vol_args) +/* With a @src_length of zero, the range from @src_offset->EOF is cloned! */ struct btrfs_ioctl_clone_range_args { __s64 src_fd; __u64 src_offset, src_length;