From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B76B2C433F5 for ; Fri, 11 Feb 2022 21:53:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 16B876B0075; Fri, 11 Feb 2022 16:53:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 11AF96B007B; Fri, 11 Feb 2022 16:53:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFDB96B007D; Fri, 11 Feb 2022 16:53:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id DE0E56B0075 for ; Fri, 11 Feb 2022 16:53:22 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7D199998D3 for ; Fri, 11 Feb 2022 21:53:22 +0000 (UTC) X-FDA: 79131850644.23.0D6A66A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf08.hostedemail.com (Postfix) with ESMTP id EEF1C160003 for ; Fri, 11 Feb 2022 21:53:21 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id EF67A60DBC; Fri, 11 Feb 2022 21:53:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23257C340E9; Fri, 11 Feb 2022 21:53:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1644616400; bh=OKkifUPDbiPipbbjhfkrwiFe3zvLH8D2eSdINnSo9XM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AUF7n4LlZxdh+nVBkGdadBE5TUTAQtmTu2EwVHGaa1p5Ukrzz2Gv+wmOWqwRahnuY 9Wiw9sGELlzHfNgjjn8f9lsX0wtEnpe638yMBTtJ5heHRloKaOxtT4UOEYuWs0g50/ 3tvIPHK+M7th800I2S1aTpmyKFgWp0e8QWRdvJEo= Date: Fri, 11 Feb 2022 13:53:19 -0800 From: Andrew Morton To: SeongJae Park Cc: shy828301@gmail.com, ziy@nvidia.com, ying.huang@intel.com, willy@infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND] migrate: Wrap CONFIG_DEVICE_PRIVATE dependent function declarations with ifdef Message-Id: <20220211135319.1ff408fa6a7c5c5755ac2c87@linux-foundation.org> In-Reply-To: <20220209094753.22022-1-sj@kernel.org> References: <20220209094753.22022-1-sj@kernel.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: EEF1C160003 X-Stat-Signature: imndd1ptkceixgnibqx146oaixeynt53 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=AUF7n4Ll; dmarc=none; spf=pass (imf08.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1644616401-488636 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 9 Feb 2022 09:47:53 +0000 SeongJae Park wrote: > 'migrate_vma_{setup,pages,finalize}()' functions are defined under > CONFIG_DEVICE_PRIVATE, but their declarations are not. This commit > wraps the declaration under the config to minimize confusion. > > ... > > --- a/include/linux/migrate.h > +++ b/include/linux/migrate.h > @@ -162,9 +162,14 @@ struct migrate_vma { > unsigned long flags; > }; > > +#ifdef CONFIG_DEVICE_PRIVATE > + > int migrate_vma_setup(struct migrate_vma *args); > void migrate_vma_pages(struct migrate_vma *migrate); > void migrate_vma_finalize(struct migrate_vma *migrate); > + > +#endif /* CONFIG_DEVICE_PRIVATE */ > + We often don't do this. The advantage is that errors are revealed at compile time rather than at link time. But the downside is quite a lot of maintenance overhead and messier-looking header files. And that maintenance overhead is significant, partly because we can get this wrong but the kernel will still happily compile and boot! So the only way to maintain these things is by inspection.