On Thu, Jun 27, 2024 at 2:11 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, 27 Jun 2024 13:50:22 -0700 Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote:
>
> > On Thu, Jun 27, 2024 at 12:59 PM Andrew Morton
> > > Is it possible/sensible to make this feature Kconfigurable so that people who
> > > don't need it can omit it?
> >
> > It's just a matter of #ifdef/#endif, so not hard, technically
> > speaking. But I'm wondering what's the concern? This is mostly newly
> > added code (except factoring out get_vma_name logic, which won't be
> > #ifdef'ed anyways), so if no one is using this new API, then it should
> > cause no issue.
> >
> > Generally speaking, I'd say if we don't *have to* add the Kconfig
> > option, I'd prefer that. But if you feel strongly, it's not hard for
> > me to do, of course.
> >
> > Or are you concerned with the vmlinux code size increase? It doesn't
> > seem to be large enough to warrant a Kconfig, IMO (from
> > bloat-o-meter):
> >
> > do_procmap_query - 1308 +1308
> > get_vma_name - 283 +283
> > procfs_procmap_ioctl - 47 +47
> > show_map_vma 444 274 -170
> >
> > But again, do let me know if you insist.
>
> Yes, I'm thinking about being nice to small systems ("make
> tinyconfig"!). The kernel just gets bigger and bigger over time,
> little bit by little bit.
>
> It's a judgment call - if making it configurable is ugly and/or adds
> maintenance overhead then no.
>
I see, thanks for clarifying. I'd vote to not add extra Kconfig to
keep things simple and less surprising. All this code is conditional
on CONFIG_PROC_FS=y anyways, and there is plenty of code for procfs
already. I think this do_procmap_query is just a small addition here
that doesn't fundamentally regress anything.
