From: Mike Frysinger <vapier@gentoo.org> To: Al Viro <viro@zeniv.linux.org.uk> Cc: "Ted Ts'o" <tytso@mit.edu>, Artem Bityutskiy <dedekind1@gmail.com>, Thierry Reding <thierry.reding@avionic-design.de>, Jan Kara <jack@suse.cz>, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] ext2: Don't export ext2_mask_flags() to user space Date: Sat, 24 Mar 2012 02:50:38 -0400 [thread overview] Message-ID: <CAMjpGUdnisfawUNThOu_+kbH54SWXCf6PhZwyWrV=B8SNjMRNg@mail.gmail.com> (raw) In-Reply-To: <20120322173150.GY6589@ZenIV.linux.org.uk> On Thu, Mar 22, 2012 at 13:31, Al Viro wrote: > On Thu, Mar 22, 2012 at 12:28:25PM -0400, Ted Ts'o wrote: >> On Thu, Mar 22, 2012 at 08:00:41AM +0200, Artem Bityutskiy wrote: >> > On Thu, 2012-03-22 at 06:53 +0100, Thierry Reding wrote: >> > > What's the recommended fix for packages that cannot or will not use >> > > libext2fs, like busybox? Copy the required parts into a private header >> > > and use that instead? >> > >> > The normal way is to just keep a private copy of the whole header file. >> > Because the on-disk format stays compatible, those programs do not have >> > to update the header very often - only rarely if they want to support >> > some new feature. >> >> Even if they're not iwlling to use libext2fs (for space reasons, I >> would assume? It can't be because of license compatibility issues >> since they are both GPLv2), they could just simply grab the ext2_fs.h >> from e2fsprogs. That has all of the file system definitions for ext2, >> ext3, and ext4. > > Ho-hum... Then we could kill a lot of lines in include/linux/ext2_fs.h. > I wonder how much of what remains has any business being outside of > fs/ext2, actually - AFAICS, there are very few places that might possibly > care: > > arch/blackfin/kernel/setup.c:595: if (*((unsigned short *)(mtd_phys + 0x438)) == EXT2_SUPER_MAGIC) > fs/nfsd/nfs3proc.c:599: case EXT2_SUPER_MAGIC: > fs/nfsd/nfs3proc.c:600: resp->p_link_max = EXT2_LINK_MAX; > fs/nfsd/nfs3proc.c:601: resp->p_name_max = EXT2_NAME_LEN; > init/do_mounts_rd.c:57: struct ext2_super_block *ext2sb; > init/do_mounts_rd.c:70: ext2sb = (struct ext2_super_block *) buf; > init/do_mounts_rd.c:153: if (ext2sb->s_magic == cpu_to_le16(EXT2_SUPER_MAGIC)) { > init/do_mounts_rd.c:155: "RAMDISK: ext2 filesystem found at block %d\n", > init/do_mounts_rd.c:157: nblocks = le32_to_cpu(ext2sb->s_blocks_count) << > init/do_mounts_rd.c:158: le32_to_cpu(ext2sb->s_log_block_size); > security/selinux/hooks.c:2974: case EXT2_IOC_GETFLAGS: > security/selinux/hooks.c:2976: case EXT2_IOC_GETVERSION: > security/selinux/hooks.c:2980: case EXT2_IOC_SETFLAGS: > security/selinux/hooks.c:2982: case EXT2_IOC_SETVERSION: > > and that's it. blackfin and do_mounts_rd are doing the same thing (blackfin - > buggy, AFAICS). buggy how ? they're not exactly the same as the Blackfin code is setting things up for the uClinux MTD map. it isn't parsing the filesystem itself (ignoring the size extraction from the superblock). > Looks like both are asking for something along the lines of > sector_t detect_ext2(void *image), returning 0 if it's not one and size in > kilobytes if it is... yes, that would be fine -mike
WARNING: multiple messages have this Message-ID (diff)
From: Mike Frysinger <vapier@gentoo.org> To: Al Viro <viro@zeniv.linux.org.uk> Cc: "Ted Ts'o" <tytso@mit.edu>, Artem Bityutskiy <dedekind1@gmail.com>, Thierry Reding <thierry.reding@avionic-design.de>, Jan Kara <jack@suse.cz>, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] ext2: Don't export ext2_mask_flags() to user space Date: Sat, 24 Mar 2012 02:50:38 -0400 [thread overview] Message-ID: <CAMjpGUdnisfawUNThOu_+kbH54SWXCf6PhZwyWrV=B8SNjMRNg@mail.gmail.com> (raw) In-Reply-To: <20120322173150.GY6589@ZenIV.linux.org.uk> On Thu, Mar 22, 2012 at 13:31, Al Viro wrote: > On Thu, Mar 22, 2012 at 12:28:25PM -0400, Ted Ts'o wrote: >> On Thu, Mar 22, 2012 at 08:00:41AM +0200, Artem Bityutskiy wrote: >> > On Thu, 2012-03-22 at 06:53 +0100, Thierry Reding wrote: >> > > What's the recommended fix for packages that cannot or will not use >> > > libext2fs, like busybox? Copy the required parts into a private header >> > > and use that instead? >> > >> > The normal way is to just keep a private copy of the whole header file. >> > Because the on-disk format stays compatible, those programs do not have >> > to update the header very often - only rarely if they want to support >> > some new feature. >> >> Even if they're not iwlling to use libext2fs (for space reasons, I >> would assume? It can't be because of license compatibility issues >> since they are both GPLv2), they could just simply grab the ext2_fs.h >> from e2fsprogs. That has all of the file system definitions for ext2, >> ext3, and ext4. > > Ho-hum... Then we could kill a lot of lines in include/linux/ext2_fs.h. > I wonder how much of what remains has any business being outside of > fs/ext2, actually - AFAICS, there are very few places that might possibly > care: > > arch/blackfin/kernel/setup.c:595: if (*((unsigned short *)(mtd_phys + 0x438)) == EXT2_SUPER_MAGIC) > fs/nfsd/nfs3proc.c:599: case EXT2_SUPER_MAGIC: > fs/nfsd/nfs3proc.c:600: resp->p_link_max = EXT2_LINK_MAX; > fs/nfsd/nfs3proc.c:601: resp->p_name_max = EXT2_NAME_LEN; > init/do_mounts_rd.c:57: struct ext2_super_block *ext2sb; > init/do_mounts_rd.c:70: ext2sb = (struct ext2_super_block *) buf; > init/do_mounts_rd.c:153: if (ext2sb->s_magic == cpu_to_le16(EXT2_SUPER_MAGIC)) { > init/do_mounts_rd.c:155: "RAMDISK: ext2 filesystem found at block %d\n", > init/do_mounts_rd.c:157: nblocks = le32_to_cpu(ext2sb->s_blocks_count) << > init/do_mounts_rd.c:158: le32_to_cpu(ext2sb->s_log_block_size); > security/selinux/hooks.c:2974: case EXT2_IOC_GETFLAGS: > security/selinux/hooks.c:2976: case EXT2_IOC_GETVERSION: > security/selinux/hooks.c:2980: case EXT2_IOC_SETFLAGS: > security/selinux/hooks.c:2982: case EXT2_IOC_SETVERSION: > > and that's it. blackfin and do_mounts_rd are doing the same thing (blackfin - > buggy, AFAICS). buggy how ? they're not exactly the same as the Blackfin code is setting things up for the uClinux MTD map. it isn't parsing the filesystem itself (ignoring the size extraction from the superblock). > Looks like both are asking for something along the lines of > sector_t detect_ext2(void *image), returning 0 if it's not one and size in > kilobytes if it is... yes, that would be fine -mike -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-03-24 6:51 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-03-21 21:50 [PATCH] ext2: Don't export ext2_mask_flags() to user space Thierry Reding 2012-03-21 22:23 ` Jan Kara 2012-03-21 23:16 ` Ted Ts'o 2012-03-22 5:53 ` Thierry Reding 2012-03-22 6:00 ` Artem Bityutskiy 2012-03-22 16:28 ` Ted Ts'o 2012-03-22 16:47 ` Thierry Reding 2012-03-22 18:31 ` Ted Ts'o 2012-03-23 9:27 ` [PATCH] ext2: No longer export ext2_fs.h " Thierry Reding 2012-03-23 9:27 ` Thierry Reding 2012-03-23 13:13 ` Ted Ts'o 2012-03-23 17:55 ` Al Viro 2012-03-24 21:51 ` Ted Ts'o 2012-03-24 22:16 ` H. Peter Anvin 2012-03-25 1:16 ` Ted Ts'o 2012-03-22 17:31 ` [PATCH] ext2: Don't export ext2_mask_flags() " Al Viro 2012-03-23 0:25 ` Andreas Dilger 2012-03-24 6:51 ` Mike Frysinger 2012-03-24 6:50 ` Mike Frysinger [this message] 2012-03-24 6:50 ` Mike Frysinger 2012-03-24 8:37 ` Al Viro 2012-03-24 17:59 ` Mike Frysinger
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAMjpGUdnisfawUNThOu_+kbH54SWXCf6PhZwyWrV=B8SNjMRNg@mail.gmail.com' \ --to=vapier@gentoo.org \ --cc=dedekind1@gmail.com \ --cc=jack@suse.cz \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=stable@vger.kernel.org \ --cc=thierry.reding@avionic-design.de \ --cc=tytso@mit.edu \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.