Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754941AbZCaKby (ORCPT ); Tue, 31 Mar 2009 06:31:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752326AbZCaKbm (ORCPT ); Tue, 31 Mar 2009 06:31:42 -0400 Received: from gw-ca.panasas.com ([209.116.51.66]:15728 "EHLO laguna.int.panasas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751268AbZCaKbm (ORCPT ); Tue, 31 Mar 2009 06:31:42 -0400 Message-ID: <49D1F096.1020802@panasas.com> Date: Tue, 31 Mar 2009 13:29:42 +0300 From: Boaz Harrosh User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090315 Remi/3.0-0.b2.fc10.remi Thunderbird/3.0b2 MIME-Version: 1.0 To: Andrew Morton 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 References: <49C1331D.1080805@panasas.com> <1237399791-29502-1-git-send-email-bharrosh@panasas.com> <20090331010430.72e8137e.akpm@linux-foundation.org> In-Reply-To: <20090331010430.72e8137e.akpm@linux-foundation.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2009 10:31:39.0365 (UTC) FILETIME=[E0332950:01C9B1EB] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1927 Lines: 62 On 03/31/2009 11:04 AM, Andrew Morton wrote: > 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. > >> ... >> > OK, OK. Thanks will fix Boaz -- 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/