linux-kernel - Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201211271444.04002.Martin@lichtvoll.de>
Date:	Tue, 27 Nov 2012 14:44:03 +0100
From:	Martin Steigerwald <Martin@...htvoll.de>
To:	linux-kernel@...r.kernel.org
Cc:	Dave Chinner <david@...morbit.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Theodore Ts'o" <tytso@....edu>, torvalds@...ux-foundation.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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?
> > 
> > Why not just reserve a small group of bits for fs private use in that
> > case - for any fs.
> 
> Flawed - one bit, one function for all filesystems, otherwise the
> same binary could behave very differently on different filesystems.
> 
> 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.
> 
> 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....
> 
> 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… and I 
didn´t read the previous discussions about this patch…

… 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 
kernel source and I am happy that sometimes can understood some of it. 
Reading "this is used for some magic Google or Tao Bao do with their 
filesystem" would decrease my chance to understand whats going on there. 
Not quite approbiate for an open source kernel, I think.

Thanks,
-- 
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/