On Mon, Feb 18, 2008 at 08:12:29AM +0100, Ingo Molnar wrote: > > Nack. I don't object to un-exporting journal_update_superblock(), > > because that is pretty internal, but the other functions are intended > > specifically for use by code outside of JBD. For example, the journal > > checksum patch for ext3/4 uses journal_set_features() to turn on > > features in the JBD superblock. > > > > Similarly, for 64-bit support in ext4 uses journal_set_features() to > > set a 64-bit feature flag in the journal superblock. > > that's an invalid excuse for the benefit of out-of-tree forks: reality > is that you can export those functions in the "journal checksum patch" > just fine. So you cannot 'nack' a sensible patch on that ground and no > maintainer does it on that ground. Once you get your stuff upstream, you > can re-add the export. I'm going to NACK it as well. This kind of code churn where we make symbols static only to make them non-static again in an existing ext4 tree is exactly the sort of needless code churn that makes patches start to conflict and where we need different patches depending on whether it is intended for -mm or linux-next or mainline. I think we really have gotten WAY to doctrinaire on the if there are no in-tree users, it MUST be static. This is exactly the sort of mindless rules that cause the patch conflicts that have been causing us so much pain and grief. In this case, it is an existing symbol which is already non-static, and for which we have code in a development tree that will be using it. In the r/o bind case, it is the insistence that you can't push an existing patch to expose a new interface that must be used later in the r/o bind patchset and which sweeps across all trees changing stuff that causes pain and grief. In both cases, if we expand "in-tree" development users to include known development trees that are intended for mainline, it makes all of our lives MUCH easier. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
