On Fri, 2006-07-28 at 22:58 +0200, Łukasz Mierzwa wrote: > It just hited me that 90% of mails (those I've read and remember) in which > You guys are talking why r4 should or should not be merged did not contain > a patch or not even a line of code as a reference, most of complains feels > so abstract and ahead of time, there is nothing wrong with planing ahead > but does it still makes sense when nobody else actually said that he would > want to use it in future? Can't it be pusshed up to vfs later if it proves > itself and there is demand for it? > My question is what does it break now? It's been in mm for some time now, > what troubles does it couse? Did anyone complained that it breaks mm and > should be dropped? > I'm just a end user and have no idea of linux internals, but all the fuzz > about r4 seems so political and it's not just me who things so.
Agreed. As an outsider looking in trying to understand this all, it sounds like Hans can't win either way. People complain if the plugin code is contained entirely within Reiser4 and people complain if he tries to add functionality to the VFS that only Reiser4 will likely use for the foreseeable future. Or maybe ever use, we don't know yet? Ignoring pseudo files which Hans has pulled for now anyways, what difference is their between Reiser4 plugins and what EXT3 does with mount options like dir_index? 3rd party plugins can't be dynamically loaded, and some of them need mount options to enable them even after they are compiled in. So people can't "mistakenly" load some plugin that corrupts their data, or changes the on-disk format making it impossible to downgrade kernel versions. Is it the fact that Reiser4 plugins can be enabled/disable on a per file basis? If you don't use the word "plugin", how is adding dir_index code to EXT3 any different then adding encryption/compression code to Reiser4? -- Mike Benoit <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
