Message-ID: <CAF8px55cnNytE=Hg-jt0mtp9CL1grQ5vS1-QXjSrHfQ_C8XXNQ@mail.gmail.com>
Date:   Tue, 5 Jan 2021 15:48:14 -0600
From:   Mike Mestnik <cheako@...emestnik.net>
To:     linux-kernel@...r.kernel.org
Subject: Config option tags/groups.

I can't find good descriptions for CONFIG_IRQ_MSI_IOMMU,
CONFIG_GENERIC_IRQ_CHIP, and CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS.  I
know that doesn't sound like it has anything to do with the subject,
I'm getting there.  I'm trying to add cgroups and virtualization to an
OpenWRT config.  As odd as it seems the config for OWRT is
*obfuscated(AFAICT), so I'm unable to take that config and just edit
it.  My new idea is to strip out the "hardware" parts of the config(or
just the NF config) from Debian's arm64 kernel and merge that with
what I do have from OpenWRT.  The problem, there is no way of knowing
what flags(options/CONFIG_) are dependent on some piece of hardware or
even what flags are part of NF.  I looked at generating a list of
flags that depend on CONFIG_NETFILTER, but that seems like it would
involve reading not only the Kconfig files but also the Makefiles.

You may be asking, what do I want the hardware or the NF parts.  The
answer is either would be a start.  The term hardware is ambiguous(is
SMT options hardware?), so I think I'd be more interested in having
groups that are for NF, flags that add things to the userspace
API(further separated by syscall/proc/sys/dev) and flags that change
parts of the userspace API.

I don't think the metadata should live in the Kconfig files and there
is also no real reason this should live in the kernel tree at all, but
I think it's most useful there.  I'm thinking more about files in a
folder under documentation or something like that.  I would put these
lists together, but as I started with...  that's just impossible for
someone without good documentation on what each flag does.

* If you merge the base, arch, and board configs together you won't
get a config that includes things like NetFilter.  You might think
that's impossible for OpenWRT to work that way, but as it turns out NF
is added by some Makefile scripting.  I tried to run an OpenWRT build,
but that was a dead end for me...  I couldn't get the build system
configured for some reason.

How I got here, the whole rest of what I'm doing:
This is for an ESPRESSObin V7 Board /w the Marvell Armada 3700LP
(88F3720) dual core ARM Cortex A53.  OpenWRT seems to have a great
config for this board that I'm currently using.  I'd like to add
cgroups and virtualization to this config and while I'm at it upgrade
from the 4.x kernel OpenWRT uses.  Doing so, I noticed that
CONFIG_NETFILER was unset.  So I was like that's ok I'll just grab
that from Debian's arm64 kernel .config.  You can't do that though,
AFAICT.  Debian's config has a lot of stuff for other boards and
notably doesn't include the hardware crypto acceleration OpenWRT does.
So I'd like to grab all the userspace stuff from Debian's config and
merge it with the hardware things from OpenWRT, this should be
simple...  I should be able to tell if
CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS is a piece of hardware or not.

Wile CONFIG_IRQ_MSI_IOMMU sounds like part of a north bridge(that I
wouldn't have) and CONFIG_GENERIC_IRQ_CHIP sounds like something every
arm64 should have...  but CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS I
can't tell and have no idea.  These come from running olddefconfig on
both configs and diffing, Debian seems to set all of these and the
base OpenWRT kernel has them unset.

I would accept to skip all of this and start working with an
un-obfuscated OpenWRT config, where I can just turn on the two
frameworks I'm interested in.  Though there is still the issue that
Debian seems to have more userspace option flags set, so if I go to
try and run Debian in a container I expect it to fail on not having
POSIX_MQUEUE or something.  I'll cross that bridge when I get there.

Cheers.

Powered by blists - more mailing lists