Regarding ifdefs: I'm not a big fan of ifdefs in general. This subject has been covered extensively (google "ifdefs harmful") but in a nutshell: - I think it makes the code more complex. You have to think about how the code behaves given different config options and as a result it hides bugs at both run time and compile time. We see this often thanks to the intel building bots. - Regarding memory usage and compiled code size, I haven't run the numbers I suspect it's insignificant. I'm much more in favor of runtime ways to enable/disable stuff. If you *really* want to make cifs functionnaly different at compile time I think the ifdefs parts should really only stick to the functionnal part of the feature. Functionnal as in "the part that calls the code responsible for the work" or the parts settings values/mode to enable/disabe. Dont wrap field structures or function definitions. This way you have as little ifdefs as possible and you keep them small and manageable. Cheers, -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- 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
