From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Blunck Subject: Re: + embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt.pa tch added to -mm tree Date: Tue, 6 Nov 2007 13:59:03 +0100 Message-ID: <20071106125903.GK5619@hasse.suse.de> 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: akpm@linux-foundation.org, mm-commits@vger.kernel.org, agruen@suse.de, hch@lst.de, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk To: =?iso-8859-1?Q?J=F6rn?= Engel Return-path: Received: from mx1.suse.de ([195.135.220.2]:47645 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754582AbXKFM7G (ORCPT ); Tue, 6 Nov 2007 07:59:06 -0500 Content-Disposition: inline In-Reply-To: <20071106113038.GA25953@lazybastard.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Nov 06, J=F6rn Engel wrote: > > 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. This are the patches currently in -mm related to the struct path cleanu= p: move-struct-path-into-its-own-header.patch embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt.patch introduce-path_put.patch use-path_put-in-a-few-places-instead-of-mntdput.patch introduce-path_get.patch use-struct-path-in-fs_struct.patch make-set_fs_rootpwd-take-a-struct-path.patch introduce-path_get-unionfs.patch embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt-union= fs.patch introduce-path_put-unionfs.patch one-less-parameter-to-__d_path.patch d_path-kerneldoc-cleanup.patch d_path-use-struct-path-in-struct-avc_audit_data.patch d_path-make-proc_get_link-use-a-struct-path-argument.patch d_path-make-get_dcookie-use-a-struct-path-argument.patch use-struct-path-in-struct-svc_export.patch use-struct-path-in-struct-svc_expkey.patch d_path-make-seq_path-use-a-struct-path-argument.patch d_path-make-d_path-use-a-struct-path.patch > > 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. ;) I'll send them in a later series. > > 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. I start sending out the patches in multiple chunks because nobody revie= wed the union mount series except for coding style violations. So this is the p= rework for the changes that come with my union mount series. So they are relat= ed but not a part of the union mount patch series. It seems that people te= nd to like the patch series with small changes for itself instead of a big fa= t series. > > 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. Sorry for missing your feedback but now I found your mail ("mental masturbation that complicates the source"). I guess this is what happen= s when multiple people start posting the same patch series. Coming back to the mental stuff: the savings of the first bunch of patc= hes that already hit -mm: Textsize without patches: 0x20e572 Textsize with patches: 0x20e042 ---------------------------------- 0x530 =3D 1328 bytes Cheers, Jan - 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