[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191217150921.GA136178@chrisdown.name>
Date: Tue, 17 Dec 2019 15:09:21 +0000
From: Chris Down <chris@...isdown.name>
To: Michal Hocko <mhocko@...nel.org>
Cc: Qian Cai <cai@....pw>,
Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
Johannes Weiner <hannes@...xchg.org>,
Vladimir Davydov <vdavydov.dev@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
cgroups@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: memcontrol.c: move mem_cgroup_id_get_many under
CONFIG_MMU
Michal Hocko writes:
>yes, I would just ignore this warning. Btw. it seems that this is
>enabled by default for -Wall. Is this useful for kernel builds at
>all? Does it realistically help discovering real issues? If not then
>can we simply blacklist it?
There's no way we're the first people to encounter these problems, so what did
we do in the past when situations like this (adding a generic API which is not
yet used by non-configurable code) came up, and in retrospect did they work
well?
As far as I know -Wunused-function also guards against other errors, like when
a function is prototyped but not actually defined, which might be more useful
to know about.
(Side note: I'm moderately baffled that a tightly scoped __maybe_unused is
considered sinister but somehow disabling -Wunused-function is on the table
:-))
Powered by blists - more mailing lists