VFS: introduce helpers for the s_dirty flag
in [Kernel]
|
Prev: [PATCH 5/6] cciss: add performant mode support
Next: [PATCH 6/6] cciss: new controller support and bump driver version
From: tytso on 9 Jun 2010 11:50 On Fri, May 28, 2010 at 02:17:55PM -0700, Andrew Morton wrote: > > > > The real issue is that it's almost certainly an overdesign. Let's > > get rid of the bogus uses first and figure out what's happening in > > what remains, OK? > > That would be good. Can we figure out what the new names will be for these accessor functions, and then pursuade Linus to be willing to add patch #1 in this series to add these accessor functions (without any users for these functions, that would wait until the next merge window) to 2.6.35-rc3 or -rc4, please? It will make life much easier for fs maintainers to merge the patches, especially if they've done some cleanup to reduce the bogus places where s_dirt was getting set in the first place. That way I can apply my patch to reduce the use of s_dirt[1], then apply a patch I carry in my own tree to convert to the new accessor functions without worrying about patch conflicts. [1] http://article.gmane.org/gmane.comp.file-systems.ext4/19499 Thanks, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Artem Bityutskiy on 9 Jun 2010 12:00 On Wed, 2010-06-09 at 11:44 -0400, tytso(a)mit.edu wrote: > On Fri, May 28, 2010 at 02:17:55PM -0700, Andrew Morton wrote: > > > > > > The real issue is that it's almost certainly an overdesign. Let's > > > get rid of the bogus uses first and figure out what's happening in > > > what remains, OK? > > > > That would be good. > > Can we figure out what the new names will be for these accessor > functions, and then pursuade Linus to be willing to add patch #1 in > this series to add these accessor functions (without any users for > these functions, that would wait until the next merge window) to > 2.6.35-rc3 or -rc4, please? > > It will make life much easier for fs maintainers to merge the patches, > especially if they've done some cleanup to reduce the bogus places > where s_dirt was getting set in the first place. That way I can apply > my patch to reduce the use of s_dirt[1], then apply a patch I carry in > my own tree to convert to the new accessor functions without worrying > about patch conflicts. Yes, that would be nice, Al? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 9 Jun 2010 12:40 On Wed, 9 Jun 2010 11:44:49 -0400 tytso(a)mit.edu wrote: > On Fri, May 28, 2010 at 02:17:55PM -0700, Andrew Morton wrote: > > > > > > The real issue is that it's almost certainly an overdesign. Let's > > > get rid of the bogus uses first and figure out what's happening in > > > what remains, OK? > > > > That would be good. > > Can we figure out what the new names will be for these accessor > functions, sb_mark_dirty(), sb_mark_clean(), sb_is_dirty(). > and then pursuade Linus to be willing to add patch #1 in > this series to add these accessor functions (without any users for > these functions, that would wait until the next merge window) to > 2.6.35-rc3 or -rc4, please? I expect he'd be OK with that. > It will make life much easier for fs maintainers to merge the patches, > especially if they've done some cleanup to reduce the bogus places > where s_dirt was getting set in the first place. For that reason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Al Viro on 9 Jun 2010 18:40
On Wed, Jun 09, 2010 at 09:31:57AM -0700, Andrew Morton wrote: > > Can we figure out what the new names will be for these accessor > > functions, > > sb_mark_dirty(), sb_mark_clean(), sb_is_dirty(). Fine by me. If Linus doesn't take such a patch, I certainly will and put it into for-next ASAP. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |