From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: + embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt.pa tch added to -mm tree Date: Tue, 6 Nov 2007 12:18:02 -0800 Message-ID: <20071106121802.f524bb37.akpm@linux-foundation.org> References: <200711052101.lA5L1Q1p019531@imap1.linux-foundation.org> <20071105221021.GC21533@lazybastard.org> <20071106091149.GJ5619@hasse.suse.de> <20071106113038.GA25953@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: jblunck@suse.de, joern@logfs.org, agruen@suse.de, hch@lst.de, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk To: =?ISO-8859-1?B?SvZybg==?= Engel Return-path: Received: from smtp2.linux-foundation.org ([207.189.120.14]:52816 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752613AbXKFTSq convert rfc822-to-8bit (ORCPT ); Tue, 6 Nov 2007 14:18:46 -0500 In-Reply-To: <20071106113038.GA25953@lazybastard.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org > On Tue, 6 Nov 2007 12:30:38 +0100 J=F6rn Engel wrot= e: > On Tue, 6 November 2007 10:11:49 +0100, Jan Blunck wrote: > > On Mon, Nov 05, J=F6rn Engel wrote: > >=20 > > > This patch changes some 400 lines, most if not all of which get l= onger > > > and more complicated to read. 23 get sufficiently longer to requ= ire an > > > additional linebreak. I can't remember complexity being invited = into > > > the kernel without good reasoning, yet the patch description is > > > surprisingly low on reasoning: > > > > Switch from nd->{dentry,mnt} to nd->path.{dentry,mnt} everywher= e. > >=20 > > I don't measure complexity by lines of code or length of lines. May= be I was > > not verbose enough in the description, fair. >=20 > If you have a better metric, please share it. In the paragraph you > deleted I explicitly asked for _any_ metric that shows favorable > numbers. Lacking numbers, we could only argue about our respective > personal taste. >=20 > > This is a cleanup series. In mostly no case there is a reason why s= omeone > > would want to use a dentry for itself. This series reflects that fa= ct in > > nameidata where there is absolutly no reason at all. >=20 > 400+ lines changed in this patch, some 10 in a followup patch that > combines dentry/vfsmount assignments into a single path assignment. = If > your argument above was valid, I would expect more simplifications an= d > fewer complications. Call me a sceptic until further patches show up= to > support your point. >=20 > > It enforced the correct > > order of getting/releasing refcount on pairs. >=20 > This argument I buy. >=20 > > It enables us > > to do some more cleanups wrt lookup (which are coming later). >=20 > Please send those patches. I invite cleanups that do clean things up > and won't argue against then. ;) >=20 > > For stacking > > support in VFS it is essential to have the pair i= n every > > place where you want to traverse the stack. >=20 > True, but unrelated to this patch. >=20 > > > If churn is the only effect of this, please considere it NAKed ag= ain. > >=20 > > I wonder why you didn't speak up when this series was posted to LKM= L. It was > > at least posted three times before. >=20 > I did speak up. Once. If you missed that thread, please forgive me > missing those in which the same patch I disapproved of were resent > without me on Cc. >=20 > I'm not categorically against this struct path business. It does hav= e > some advantages at first glance. But the patch we're arguing about > clearly makes code more complicated and harder to read. We should ha= ve > more than superficial benefits if we decide to pay such a cost. It sounds like we at least need a better overall changlog, please.. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html