[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9083c414-62f2-4bff-93ee-13f8ff60eb34@linaro.org>
Date: Wed, 21 Feb 2024 16:38:06 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Maxime Ripard <mripard@...hat.com>
Cc: Javier Martinez Canillas <javierm@...hat.com>,
linux-kernel@...r.kernel.org, Enric Balletbo i Serra <eballetbo@...hat.com>,
Erico Nunes <nunes.erico@...il.com>, Brian Masney <bmasney@...hat.com>,
Arnd Bergmann <arnd@...db.de>, Bjorn Andersson <quic_bjorande@...cinc.com>,
Catalin Marinas <catalin.marinas@....com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Neil Armstrong <neil.armstrong@...aro.org>, Will Deacon <will@...nel.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2] arm64: defconfig: Enable zram, xfs and loading
compressed FW support
On 21/02/2024 16:24, Maxime Ripard wrote:
> On Wed, Feb 21, 2024 at 04:10:12PM +0100, Krzysztof Kozlowski wrote:
>> On 21/02/2024 15:48, Maxime Ripard wrote:
>>> On Wed, Feb 21, 2024 at 03:22:38PM +0100, Krzysztof Kozlowski wrote:
>>>> On 21/02/2024 15:13, Javier Martinez Canillas wrote:
>>>>> These options are needed by some Linux distributions (e.g: Fedora), so
>>>>
>>>> How ZRAM is needed? Why Fedora cannot boot without it? Debian, which I
>>>> use on my arm64 boards, does not have any problem.
>>>
>>> Is it relevant in any way?
>>
>> Yes, because it is justification why we are doing it. Each commit is
>> supposed to explain "why" and the explanation here is not enough.
>
> There's a why though: it makes Fedora boot. It might not be enough for
I want to know to understand. Maybe it is not really neeed but "nice to
have"? People write various vague statements...
> you, but that's a different story. So, if it's not enough, please state
> exactly what you expect from that patch description so Javier can
> provide it.
Any explanation what ZRAM is necessary for Fedora to boot.
>
>>> I'm sure Debian can boot without MEMORY_HOTREMOVE, or BRIDGE, or
>>> NUMA_BALANCING, or BPF_JIT, or NFS_FS, yet all of them are enabled. Let
>>> me know if you want hundreds more examples.
>>
>> So if there is any bug, you are allowed to add new one? If there is any
>> silly option, you are allowed to add new one?
>>
>> Feel free to propose dropping of any irrelevant options.
>
> No, of course you aren't. My point is that Fedora is a distro just as
> established and legitimate as Debian is. And apparently "it makes Debian
> works" is a reasonable argument, since, well, it does.
>
> If making Fedora boot with that defconfig is not a legitimate goal,
It is, but I asked for more information.
> please state why, and document it (with the ack of all the maintainers
> involved with that defconfig, obviously) so we don't have the same
> argument over and over again.
>
>>>> I kind of repeat comments from similar patch earlier:
>>>> https://lore.kernel.org/all/fe1e74a2-e933-7cd9-f740-86d871076191@linaro.org/
>>>>
>>>> About XFS: I don't think it is needed to boot anything.
>>>
>>> Just like 9P_FS, NFS or UBIFS.
>>
>> NFS is often used on targets, e.g. my board farm, but also by other people.
>>
>> UBIFS was added recently because one device was using it - you needed
>> it. 9P_FS looks unnecessary.
>
> So all we need is one person or use case to require it? Sounds like
> we've checked that mark here.
Use case of given type. I would disagree for SMBFS because we have NFS.
UBIFS is hardware requirement. 9P_FS seems like virtio case.
>
>>>> This is a defconfig, not a distro config. Please don't make it distro.
>>>>
>>>> I will gladly support things needed by systemd or equivalent, but not
>>>> unusual filesystems needed by distro.
>>>
>>> It's a defconfig. It's whatever people want it to be. Or we need to come
>>> up with a clearly defined set of rules of what is acceptable in that
>>> defconfig or not, and prune every option that isn't.
>>
>> So that's the rule I am commenting from time to time. defconfigs are not
>> distro configs. These are reference hardware configs and debugging
>> configs.
>
> Supporting a board farm is hardly either.
Debugging purpose, but I agree we can drop it.
>
> And again, I've never heard of such rule for that defconfig in my ~10y
> as an ARM platform maintainer. But what do I know, right?
>
>> I was working in distro so trust me - they do stuff differently
>> and they not need XFS in our defconfig for anything.
>
> Sure, but you're not just arguing for XFS there.
I raised need for "why" for ZRAM and un-necessity of XFS. What's wrong
with that? I should send separate emails or what?
>
> What I really don't get is this: this makes the life of people easier.
Again: this makes my life harder. I cannot be buying new machines every
two years to be able to compile defconfig while testing/working.
>
> Being able to test an upstream kernel quickly when you have a bug in a
> downstream distro is super valuable for any distro developper. And on
That's a distro need, not relevant. And even if it was, then your
argument would be "let's enable everything distro has!". This is not a
distro kernel.
> the long run, if we don't make the switch from a kernel distro to a
> mainline kernel relatively easy, we're the ones that will lose out.
> Because people just won't bother, or be frustrated and thus super
> reluctant to do that work.
>
> That's the part I don't get. Why do we want to make the life of people
> harder. This patch has never been about making the defconfig the main
Because it makes my life harder and I don't see benefits. Quoting Arnd:
"Unfortunately this will increase build time noticeably, but"
Best regards,
Krzysztof
Powered by blists - more mailing lists