Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758252Ab1FAPQy (ORCPT ); Wed, 1 Jun 2011 11:16:54 -0400 Received: from mail-ww0-f44.google.com ([74.125.82.44]:61454 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758096Ab1FAPQu (ORCPT ); Wed, 1 Jun 2011 11:16:50 -0400 MIME-Version: 1.0 In-Reply-To: <20110531175709.GC12709@twin.jikos.cz> References: <20110530113653.5c7084f0.sfr@canb.auug.org.au> <20110531175709.GC12709@twin.jikos.cz> Date: Wed, 1 Jun 2011 10:16:48 -0500 Message-ID: Subject: Re: linux-next: build warninga in Linus' tree From: Mitch Harder To: dave@jikos.cz, Stephen Rothwell , Chris Mason , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1854 Lines: 42 On Tue, May 31, 2011 at 12:57 PM, David Sterba wrote: > Hi, > > On Mon, May 30, 2011 at 11:36:53AM +1000, Stephen Rothwell wrote: >> After merging the Linus' tree, today's linux-next build (powerpc >> ppc64_defconfig) produced these warnings: >> >> fs/btrfs/sysfs.c:76:26: warning: 'btrfs_root_attrs' defined but not used >> fs/btrfs/sysfs.c:97:26: warning: 'btrfs_super_attrs' defined but not used >> fs/btrfs/sysfs.c:153:13: warning: 'btrfs_super_release' defined but not used >> fs/btrfs/sysfs.c:160:13: warning: 'btrfs_root_release' defined but not used >> >> I have started using gcc v4.5.2 (instead of v4.4.4) if that makes a >> difference. > > the warning probably started to show up after one of my cleanup patches, > removing unused functions (f2a97a9dbd86eb1ef956bdf20e05c507b32beb96). > The sysfs interface is not being used right now, but there's a unmerged > patchset which adds the interesting bits like info about available btrfs > filesystems and devices. I don't know what are the intentions regarding > sysfs. > > > david I've been playing around with resurrecting the basic sysfs capabilities that had been previously incorporated into btrfs. As it stands right now, it was relatively easy to re-implement sysfs as it was originally. However, that implementation of sysfs wasn't populated with much information (only total_blocks, blocks_used, and blocksize). I also had to reverse a small portion of code that was in the last clean-up. If a CONFIG_BTRFS_DEBUG type configuration flag is ever introduced, it would be interesting to resurrect btrfs' sysfs capabilities. -- 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/