On Wed, Nov 30, 2022, at 21:24, Palmer Dabbelt wrote:
> On Mon, 28 Nov 2022 22:54:18 PST (-0800), Conor Dooley wrote:
>>
>> idk, defconfig to me is not about you or I, it's about A Developer that gets an SBC or a devkit and their experience.
>> Or alternatively, someone's CI ;)
>> I'd like to put everything in, but I recall that being shot down, that's all.
>
> The whole "who is defconfig for" discussion always ends up kind of
> vague, but IIUC it's generally aimed at kernel hackers as opposed to end
> users -- so it's not meant to be a disto config, that's why we have
> things like the debug options turned on. I tend to think of it as a "if
> a patch submitter is going to test only one config, then what do I want
> in it?" and let that determine what goes in defconfig.
>
> IMO having defconfig contain the drivers necessary to boot every common
> dev board as =y, and having =m for anything else on those boards also
> seem reasonable. That will make the transition from vendor/distro
> kernels to upstream a bit smoother, which is always good. I guess
> there's some slight build time and image size issues, but aside from
> some very small systems that shouldn't be too bad for kernel developers
> -- and if we really end up with another popular system with 6MiB of RAM
> we can just stick another tiny defconfig in there for it.
>
> I actually don't use modules when doing kernel development because I
> find it easier to track things when they're packed into a single binary,
> but I don't think it's necessary to steer everyone that way.
>
> Adding some of the Arm folks here, in case they have thoughts. The best
> bet is probably to try and do something similar, though my worry is that
> the answer is something like "target standard platforms" and we don't
> have any.
I think this is handled very inconsistently across architectures. On
32-bit arm, we used to have a board specific defconfig for each machine,
but of course that never scaled to the number of supported machines.
The important defconfig files we have these days are the arm64
one, and on arm32 we have the ones that are mutually incompatible,
in particular one for armv7 and one for armv5, each enabling as
many machines as possible, plus usually one per SoC vendor that
is more specialized.
If you want to formalize it a bit more than this, I would recommend
having more fragments, e.g. one for typical debugging options,
one for things that are needed to boot both Fedora and Debian
userland, etc.
Arnd
