From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert S Peterson Subject: Re: [PATCH] loop.c to use write ops for fs requiring special locking Date: Wed, 29 Mar 2006 18:10:11 -0600 Message-ID: <1143677411.26193.43.camel@technetium.msp.redhat.com> References: <1143496322.10856.22.camel@technetium.msp.redhat.com> <20060328144018.GA17080@infradead.org> <1143561557.10856.92.camel@technetium.msp.redhat.com> <20060329090503.GA7940@infradead.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Anton Altaparmakov , Andrew Morton , fs-devel mailing list Return-path: Received: from mx1.redhat.com ([66.187.233.31]:2001 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S1751237AbWC3AHY (ORCPT ); Wed, 29 Mar 2006 19:07:24 -0500 To: Christoph Hellwig In-Reply-To: <20060329090503.GA7940@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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.