From mboxrd@z Thu Jan 1 00:00:00 1970 From: Karel Zak Subject: Re: move all statfs f_type magic numbers to linux/magic.h Date: Tue, 4 Mar 2014 13:37:59 +0100 Message-ID: <20140304123759.GA4994@x2.net.home> References: <1393927258-10709-1-git-send-email-kzak@redhat.com> <20140304105807.GD6851@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Al Viro , linux-fsdevel@vger.kernel.org To: Dave Chinner Return-path: Received: from mx1.redhat.com ([209.132.183.28]:24368 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756971AbaCDMiD (ORCPT ); Tue, 4 Mar 2014 07:38:03 -0500 Content-Disposition: inline In-Reply-To: <20140304105807.GD6851@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Mar 04, 2014 at 09:58:07PM +1100, Dave Chinner wrote: > On Tue, Mar 04, 2014 at 11:00:36AM +0100, Karel Zak wrote: > > The file is incomplete and some magic numbers that kernel > > returns by statfs f_type to userspace are not defined there. This situation > > makes statfs f_type usage in userpace painful as you have to "ifndef-define" > > many magic numbers in userspace code. > > > > All the patches are trivial and just move *_SUPER_MAGIC stuff from > > filesystem specific files to the generic . > > IMO, this is the wrong way to fix the statfs magic numbers into the > user API. You're changing the code to define magic numbers that are > on disk to be defined - and fixed permanently - by the statfs > syscall API. Well, my idea was to follow the current kernel manner :-) and add the missing magic numbers to the API. I agree that linux/magic.h is mess, and if there is call for something better than I can send v2 with API cleanup. > We need to be able to change the on-disk magic numbers whenever and > however we want without affecting userspace It's still possible, just define a new FOO_SUPER_MAGIC2 in fs code and keep linux/magic.h unchanged. And not in all cases *_SUPER_MAGIC are used for on-disk stuff, very often it's magic number for s_magic and f_type only. > If you want all the magic numbers that filesystems expose to > userspace in statfs to be defined in one place, then you need to > create the definitions for only that purpose that match what is Yes, I thought about it, but I was not sure if such change will be accepted. > currently documented in the statfs() man page and use those in the > filesystem statfs implementation rather than the on-disk superblock > magic number definitions. > > e.g. include/uapi/linux/statfs_magic.h: > > #define __STATFS_ADFS_SUPER_MAGIC 0xadf5 > #define __STATFS_AFFS_SUPER_MAGIC 0xADFF > ... Now filesystems usually share statfs f_type with superblock s_magic. It would be probably good enough to use something like include/uapi/linux/statfs_magic.h: #define __STATFS_FOO_SUPER_MAGIC 0xadf5 fs/foo/foo_sb.h: #define FOO_SUPER_MAGIC __STATFS_FOO_SUPER_MAGIC to avoid multiple definitions of the same numbers. > and then convert all the kernel filesystem statfs code to use these > types rather than their on-disk magic numbers in f_type. > > Then, for userspace, wrap them appropriately in glibc sys/statfs.h: > > #include > > #define ADFS_SUPER_MAGIC __STATFS_ADFS_SUPER_MAGIC > #define AFFS_SUPER_MAGIC __STATFS_AFFS_SUPER_MAGIC and what about the old linux/magic.h? I guess it's necessary to keep it for backward compatibility. Karel -- Karel Zak http://karelzak.blogspot.com