Hi all, 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. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 31, 2011 at 12:57 PM, David Sterba <dave@jikos.cz> 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. > > > davidI''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.
On Wed, Jun 01, 2011 at 10:16:48AM -0500, Mitch Harder wrote:> 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).Goffredo Baroncelli (CCed) posted a patch to enhance sysfs interface: https://patchwork.kernel.org/patch/308902/ (http://www.spinics.net/lists/linux-btrfs/msg06777.html)> I also had to reverse a small portion of code that was in the last > clean-up.Restoring the code should not be a problem, the cleanup was too eager and I think a sysfs inteface would be good, not only for debugging purposes or tuning.> If a CONFIG_BTRFS_DEBUG type configuration flag is ever introduced, it > would be interesting to resurrect btrfs'' sysfs capabilities.Hearing about CONFIG_BTRFS_DEBUG again, seems worth to add it. david
On Fri, Jun 03, 2011 at 01:10:49PM +0200, David Sterba wrote:> On Wed, Jun 01, 2011 at 10:16:48AM -0500, Mitch Harder wrote: > > 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). > > Goffredo Baroncelli (CCed) posted a patch to enhance sysfs interface: > > https://patchwork.kernel.org/patch/308902/ > (http://www.spinics.net/lists/linux-btrfs/msg06777.html) > > > I also had to reverse a small portion of code that was in the last > > clean-up. > > Restoring the code should not be a problem, the cleanup was too eager > and I think a sysfs inteface would be good, not only for debugging > purposes or tuning.Indeed. There''s a few parts of the balance API that would be significantly enhanced by being able to put things in sysfs. I could drop at least one (if not two) of the three ioctls if I had somewhere in sysfs to put the relevant files. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- The glass is neither half-full nor half-empty; it is twice as --- large as it needs to be.
On Mon, May 30, 2011 at 3:36 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:> Hi all, > > 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.I see the same warnings with Debian''s gcc-4.6 (here: next-20110603), plus some more: fs/btrfs/ioctl.c: In function ''btrfs_ioctl_fs_info.isra.24'': fs/btrfs/ioctl.c:2080:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=] fs/btrfs/delayed-inode.c: In function ''btrfs_batch_insert_items'': fs/btrfs/delayed-inode.c:690:9: warning: ''nitems'' may be used uninitialized in this function [-Wuninitialized] - Sedat -> -- > Cheers, > Stephen Rothwell sfr@canb.auug.org.au > http://www.canb.auug.org.au/~sfr/ >
On Fri, Jun 03, 2011 at 01:10:49PM +0200, David Sterba wrote:> On Wed, Jun 01, 2011 at 10:16:48AM -0500, Mitch Harder wrote: > > 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). > > Goffredo Baroncelli (CCed) posted a patch to enhance sysfs interface: > > https://patchwork.kernel.org/patch/308902/ > (http://www.spinics.net/lists/linux-btrfs/msg06777.html) > > > I also had to reverse a small portion of code that was in the last > > clean-up. > > Restoring the code should not be a problem, the cleanup was too eager > and I think a sysfs inteface would be good, not only for debugging > purposes or tuning. > > > If a CONFIG_BTRFS_DEBUG type configuration flag is ever introduced, it > > would be interesting to resurrect btrfs'' sysfs capabilities. > > Hearing about CONFIG_BTRFS_DEBUG again, seems worth to add it.For debugging stuff, please use debugfs instead of sysfs, as that is what it is there for. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html