Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754754AbZCaINB (ORCPT ); Tue, 31 Mar 2009 04:13:01 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757486AbZCaIMN (ORCPT ); Tue, 31 Mar 2009 04:12:13 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:58490 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757437AbZCaIML (ORCPT ); Tue, 31 Mar 2009 04:12:11 -0400 Date: Tue, 31 Mar 2009 01:04:30 -0700 From: Andrew Morton To: Boaz Harrosh Cc: Avishay Traeger , Jeff Garzik , Evgeniy Polyakov , linux-fsdevel , open-osd , linux-kernel , James Bottomley , FUJITA Tomonori Subject: Re: [PATCH 6/8] exofs: super_operations and file_system_type Message-Id: <20090331010430.72e8137e.akpm@linux-foundation.org> In-Reply-To: <1237399791-29502-1-git-send-email-bharrosh@panasas.com> References: <49C1331D.1080805@panasas.com> <1237399791-29502-1-git-send-email-bharrosh@panasas.com> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1789 Lines: 57 On Wed, 18 Mar 2009 20:09:51 +0200 Boaz Harrosh wrote: > This patch ties all operation vectors into a file system superblock > and registers the exofs file_system_type at module's load time. > > * The file system control block (AKA on-disk superblock) resides in > an object with a special ID (defined in common.h). > Information included in the file system control block is used to > fill the in-memory superblock structure at mount time. This object > is created before the file system is used by mkexofs.c It contains > information such as: > - The file system's magic number > - The next inode number to be allocated > > > ... > > +static int exofs_statfs(struct dentry *dentry, struct kstatfs *buf) > +{ > + struct super_block *sb = dentry->d_sb; > + struct exofs_sb_info *sbi = sb->s_fs_info; > + struct osd_obj_id obj = {sbi->s_pid, 0}; > + struct osd_attr attrs[] = { > + ATTR_DEF(OSD_APAGE_PARTITION_QUOTAS, > + OSD_ATTR_PQ_CAPACITY_QUOTA, sizeof(__be64)), > + ATTR_DEF(OSD_APAGE_PARTITION_INFORMATION, > + OSD_ATTR_PI_USED_CAPACITY, sizeof(__be64)), > + }; > + uint64_t capacity = ~0; > + uint64_t used = ~0; My brain hurts. ~0 is signed 0xffffffff. When assigning to a u64 it gets signed extended to signed 0xffffffffffffffff and then converted to unsigned 0xffffffffffffffff. I think. Just as with plain old "-1". Perhaps using plain old "-1" would be clearer here. > > ... > > +const struct super_operations exofs_sops = { This can in fact be made static, I believe. > > ... > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/