From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 19/19] fs: do not assign default i_ino in new_inode Date: Sat, 16 Oct 2010 12:35:17 -0400 Message-ID: <20101016163517.GF20086@infradead.org> References: <1287216853-17634-1-git-send-email-david@fromorbit.com> <1287216853-17634-20-git-send-email-david@fromorbit.com> <1287220153.2799.101.camel@edumazet-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Chinner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Eric Dumazet Return-path: Content-Disposition: inline In-Reply-To: <1287220153.2799.101.camel@edumazet-laptop> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sat, Oct 16, 2010 at 11:09:13AM +0200, Eric Dumazet wrote: > I wonder if adding a flag in super_block to explicitely say : > > "I dont need new_inode() allocates a i_ino for my new inode, because > I'll take care of this myself later" > > would be safer, permiting each fs maintainer to assert the flag instead > of a single patch. What's the point, really? Assigning i_ino in new_inode always has been an utterly stupid idea to start with. I fixed the few filesystem that need it to do it explicitly. There's nothing unsafe about it - checking callers of new_inode for manual i_ino assignment was trivial. Conditional code like the one you suggested is simply evil - it complicates things instead of simplifying them.