On 12/17/2010 09:07 PM, Jeff Layton wrote: > On Fri, 17 Dec 2010 20:58:22 +0530 > Suresh Jayaraman <sjayaraman@xxxxxxx> wrote: > >> On 12/08/2010 08:33 PM, Jeff Layton wrote: >>> This is the second version of this patchset. The changes since the last >>> set are: >>> >>> 1) The patch to remove "/proc/fs/cifs/Experimental" did not remove the >>> deregistration of that file, which caused a warning on rmmod. >>> >>> 2) The patch to remove "/proc/fs/cifs/Experimental" now adds a new >>> module parameter so that people relying on it to allow zero-copy >>> writes with signing have a way to continue using that. >>> >>> A modified description of the set follows... >>> >>> The CONFIG_CIFS_EXPERIMENTAL KConfig option is the sort of thing that >>> gives distro packagers nightmares. The things that live under it are >>> impossible to predict for someone who isn't following development >>> upstream. >> >> In general, I like the overall idea of removing heavily overloaded >> CIFS_EXPERIMENTAL config option. It's true that it was at times hard to >> narrow down suspect once this option is enabled. >> >> However, the dependency of a few options on EXPERIMENTAL (fscache and >> acl) is not removed. CIFS_FSCACHE can be marked as not dependent on >> EXPERIMENTAL. Not sure about CIFS_ACL though. >> >> Can you make this patchset or a subsequent patch accomodates this change >> too? >> > > There's a difference between CONFIG_CIFS_EXPERIMENTAL and > CONFIG_EXPERIMENTAL. Those options depend on the latter. I'm removing > the former. I think it's still appropriate to mark these new features > as EXPERIMENTAL and to leave them dependent on CONFIG_EXPERIMENTAL. Doh, I missed it. Indeed they are different. Sorry about the noise. > Note, that I don't necessarily think we must leave these features > tagged CONFIG_EXPERIMENTAL just that if we want to remove those labels, > we should do that in the context of a separate discussion... > Agreed. -- Suresh Jayaraman -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
