This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sun May 19 15:24:58 2024 Received: from lml.valinux.com (postfix@lml.valinux.com [198.186.203.19]) by herbie.ucs.indiana.edu (8.9.3/8.9.3) with ESMTP id RAA08093 for ; Tue, 7 Mar 2000 17:22:05 -0500 (EST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by lml.valinux.com (Postfix) with ESMTP id E346060E5A; Tue, 7 Mar 2000 14:19:48 -0800 (PST) Received: by vger.rutgers.edu via listexpand id ; Tue, 7 Mar 2000 13:02:52 -0500 Received: by vger.rutgers.edu id ; Tue, 7 Mar 2000 12:39:13 -0500 Received: from smtp1.cern.ch ([137.138.128.38]:2718 "EHLO smtp1.cern.ch") by vger.rutgers.edu with ESMTP id convert rfc822-to-8bit; Tue, 7 Mar 2000 12:29:12 -0500 Received: from pcep-jamie.cern.ch (pcep-jamie.cern.ch [137.138.38.126]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id WAA24576; Tue, 7 Mar 2000 22:29:31 +0100 (MET) Received: (from jamie@localhost) by pcep-jamie.cern.ch (8.9.3/8.9.3) id WAA07749; Tue, 7 Mar 2000 22:29:30 +0100 Date: Tue, 7 Mar 2000 22:29:30 +0100 From: Jamie Lokier To: Hans Reiser Cc: "Stephen C. Tweedie" , Jamie Lokier , Alexander Viro , "linux-kernel@vger.rutgers.edu" , "linux-fsdevel@vger.rutgers.edu" References: <38C2DAC2.7713713B@idiom.com> <20000306142741.F4819@pcep-jamie.cern.ch> <38C371B5.C48EBB05@idiom.com> <20000307003542.A5916@pcep-jamie.cern.ch> <38C42313.A8C2BD7E@idiom.com> <14532.65158.420190 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT X-Mailer: Mutt 0.95.4us In-Reply-To: <38C4D911.506FC829@idiom.com>; from Hans Reiser on Tue, Mar 07, 2000 at 01:25:21PM +0300 Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu X-Orcpt: rfc822;linux-kernel-outgoing-dig Hans Reiser wrote: > I didn't say, do the meta-stat-data access with an iget, I meant let > the FS decide how to do it. If it does it with iget, fine, but what I > want to see is a general interface which can access arbitrary > non-filebody data (which the FS can store where it chooses and fetch > how it chooses). Fine, but I think that's pretty separate from the d_type change which is specifically "something returned by readdir". > This way we can handle ACLs and other things as yet undreamt of in a > symmetrical manner. We'll produce some code to do this sometime in > the next year I think, and then put it out for comment and review. Does it really make sense to avoid reading inodes for ACLs and other file attributes? I think not -- that's exactly what inodes are for. > You and James That's "Jamie". Really, it's the name on my birth certificate. > provided good answers to the issues I was concerned about, I guess I > just lack enthusiasm for more changes to VFS interfaces while we are > trying to port to the changes already made, and I am wrong in this.  The VFS interface change is very, very simple. Just #include and insert DT_UNKNOWN as the second argument to filldir() in your readdir() function. You can do more, but it's not required. It might not even be worthwhile with Reiserfs, depending on how the fs is laid out on disk. If my patch goes into the kernel, I'll send you an update for Reiserfs if you like. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/