From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: [PATCH] fs-private data in struct block_device Date: Thu, 1 Jan 2004 21:43:17 -0500 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040102024317.GA3851@gtf.org> References: <20040101164219.GB654@lst.de> <20040101151017.3f7bc407.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org Return-path: Received: from havoc.gtf.org ([63.247.75.124]:24768 "EHLO havoc.gtf.org") by vger.kernel.org with ESMTP id S262925AbUABCnS (ORCPT ); Thu, 1 Jan 2004 21:43:18 -0500 To: Andrew Morton Content-Disposition: inline In-Reply-To: <20040101151017.3f7bc407.akpm@osdl.org> List-Id: linux-fsdevel.vger.kernel.org On Thu, Jan 01, 2004 at 03:10:17PM -0800, Andrew Morton wrote: > > --- 1.276/include/linux/fs.h Mon Dec 29 22:37:20 2003 > > +++ edited/include/linux/fs.h Thu Jan 1 13:42:08 2004 > > @@ -353,6 +353,7 @@ > > int bd_invalidated; > > struct gendisk * bd_disk; > > struct list_head bd_list; > > + unsigned long bd_fspriv; /* file-system private data */ > > }; > > > > /* > > Seems sane. You'll need to decide whether that field should be operated > upon with atomic ops. If so, document it. If not, document its locking, > please. It looks like the standard normally-a-pointer thing that's completely managed opaquely to the block device layer. In fact, I actually prefer that these be (void*) unless there is a common use as an integer. Jeff