From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756522AbbEUWLX (ORCPT ); Thu, 21 May 2015 18:11:23 -0400 Received: from mail.kernel.org ([198.145.29.136]:41753 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754247AbbEUWLW (ORCPT ); Thu, 21 May 2015 18:11:22 -0400 Date: Thu, 21 May 2015 15:11:17 -0700 From: Jaegeuk Kim To: Andreas Ruprecht Cc: "Theodore Ts'o" , Uday Savagaonkar , linux-kernel , Paul Bolle , Valentin Rothberg , Stefan Hengelein Subject: Re: Unnecessary #ifdef in commit c863114122ac Message-ID: <20150521221117.GA69587@jaegeuk-mac02.mot.com> References: <555DBA77.6010503@fau.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555DBA77.6010503@fau.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andreas, On Thu, May 21, 2015 at 12:59:03PM +0200, Andreas Ruprecht wrote: > Hi Jaegeuk, > > your commit c863114122ac ("f2fs crypto: add symlink encryption") showed > up in linux-next today (i.e., next-20150521). I noticed it because we > run a daily analysis on linux-next, checking for inconsistencies > regarding #ifdef blocks [0,1]. > > In the commit, you create nested #ifdef blocks like the following: > > #ifdef CONFIG_F2FS_FS_ENCRYPTION > [...] > #ifdef CONFIG_F2FS_FS_XATTR > [...] > #endif > [...] > #endif > > The inner #ifdef, however, is unnecessary as CONFIG_F2FS_FS_XATTR is > defined with a dependency on CONFIG_F2FS_FS_ENCRYPTION (line 78 in the > corresponding Kconfig file at fs/f2fs/Kconfig). > > This means, CONFIG_F2FS_FS_XATTR can never be disabled if > CONFIG_F2FS_FS_ENCRYPTION is enabled, and that the inner #ifdef can > safely be removed. > > Do you want me to send a patch for this or do you want to do this yourself? Agreed. Let me please fix this in the original patch. Thanks, > > Best regards, > > Andreas > > [0] https://cados.cs.fau.de > [1] http://www.linuxplumbersconf.org/2014/ocw/proposals/1863