From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Steigerwald Subject: Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI Date: Tue, 27 Nov 2012 14:44:03 +0100 Message-ID: <201211271444.04002.Martin@lichtvoll.de> References: <1353366267-15629-1-git-send-email-david@fromorbit.com> <20121126115345.19977e46@pyramind.ukuu.org.uk> <20121126211200.GI6434@dastard> (sfid-20121127_001638_373244_611CF8E2) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Dave Chinner , Alan Cox , "Theodore Ts'o" , torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org To: linux-kernel@vger.kernel.org Return-path: Received: from mondschein.lichtvoll.de ([194.150.191.11]:48636 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753537Ab2K0NoH convert rfc822-to-8bit (ORCPT ); Tue, 27 Nov 2012 08:44:07 -0500 In-Reply-To: <20121126211200.GI6434@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Am Montag, 26. November 2012 schrieb Dave Chinner: > On Mon, Nov 26, 2012 at 11:53:45AM +0000, Alan Cox wrote: > > > It's not like there is any shortage of flag bits, so what's the > > > harm of reserving the bit? > >=20 > > Why not just reserve a small group of bits for fs private use in th= at > > case - for any fs. >=20 > Flawed - one bit, one function for all filesystems, otherwise the > same binary could behave very differently on different filesystems. >=20 > Besides, we already have a mechanism for adding filesystem specific > interfaces. It's called an ioctl. That's what it's there for - a > free-form extensible interface that can be wholly defined and > contained in the out-of-tree patch. >=20 > Most filesystems implement ioctls for their own specific > functionality, including for one-off preallocation semantics (e.g. > XFS_IOC_ZERO_RANGE). There is no reason why ext4 can't do the same > thing and we can drop the whole issue of having to modify a syscall > API with magic, undocumented flag bits with unpredictable > behaviour.... >=20 > ext4 is not a special snowflake that allows developers to bend rules > whenever they want. If the ext4 developers want to support out of > tree functionality for their filesystem, then they can do it within > their filesystem via ioctls like everyone else does. I do not develop for the kernel, just test here a bit, there a bit=E2=80= =A6 and I=20 didn=C2=B4t read the previous discussions about this patch=E2=80=A6 =E2=80=A6 but I think I can follow this argument of yours, Dave. And Ted, this does not appear to be screaming to me. So why no ioctl? And what functionality is this about anyway? Sometimes I read in some=20 kernel source and I am happy that sometimes can understood some of it.=20 Reading "this is used for some magic Google or Tao Bao do with their=20 filesystem" would decrease my chance to understand whats going on there= =2E=20 Not quite approbiate for an open source kernel, I think. Thanks, --=20 Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html