Re: [PATCH] loop.c to use write ops for fs requiring special locking

[Robert S Peterson <rpeterso@redhat.com>]

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.