On Wed, 2006-03-29 at 10:05 +0100, Christoph Hellwig wrote: > adding flags adds special cases. in this particular case it adds a special > case to hack around a leaking abstraction. the right thing is to fix that > leaky abstraction as I said in my previous mail. please go ahead and add > a proper abstraction at the file operation level that > gets rid of this leaky abstraction instead of adding a kludge ontop of an > existing one. I considered doing this, but as I said, it would require the underlying fs to use its own versions of 3,4,5, and 6, thus bypassing a great deal of vfs. Replacing 3,4,5 and 6 is certainly an option, but why change 200 lines of code when a problem can simply be fixed by 1 line of code? That seems like exposing a lot of people to a lot of unnecessary risk to me. I just can't justify replacing my car's entire engine because one spark plug is misfiring. loop.c already has the capability to use the write method rather than the prepare_write/commit_write method. So what is so wrong with giving the underlying fs the ability to decide which with a flag? My patch already received a thumbs up from Anton Altaparmakov, and I've discussed the matter with Heinz M. as well, both of whom have changed loop.c. One flag does not make the kernel "unmaintainable." I strongly believe that the "right thing to do" in this case is to add this constant. > such crap might be acceptable inside redhat, but in kernel land it never > was so this never would be even considered an option. Christoph, I would have hoped that a man of your obvious intelligence would not resort to name calling, especially in the open-source Community (with a capital C). I expected more from you. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
