Received-SPF: pass (google.com: domain of linux-kernel+bounces-74993-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Wed, 21 Feb 2024 16:24:51 +0100
From: Maxime Ripard <mripard@redhat.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Javier Martinez Canillas <javierm@redhat.com>, 
	linux-kernel@vger.kernel.org, Enric Balletbo i Serra <eballetbo@redhat.com>, 
	Erico Nunes <nunes.erico@gmail.com>, Brian Masney <bmasney@redhat.com>, Arnd Bergmann <arnd@arndb.de>, 
	Bjorn Andersson <quic_bjorande@quicinc.com>, Catalin Marinas <catalin.marinas@arm.com>, 
	Geert Uytterhoeven <geert+renesas@glider.be>, Konrad Dybcio <konrad.dybcio@linaro.org>, 
	Marek Szyprowski <m.szyprowski@samsung.com>, Neil Armstrong <neil.armstrong@linaro.org>, 
	Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] arm64: defconfig: Enable zram, xfs and loading
 compressed FW support
Message-ID: <fy3wffb2jwv4veo3golfn5olri77clxywbuwuokese7sbobixd@mird5k66cl2w>
References: <20240221141350.3740488-1-javierm@redhat.com>
 <1f28256c-e436-4add-aa67-2cfb2248b220@linaro.org>
 <6scz7iti3tzzrd4ph3gnuc2pvkcbtuuicgfgujh3pa3c34kdkt@bhfa4xbxeu7t>
 <cb8bf006-57df-494e-80f3-947582ec71f1@linaro.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="nbgb4ezh6w6ejdw7"
Content-Disposition: inline
In-Reply-To: <cb8bf006-57df-494e-80f3-947582ec71f1@linaro.org>


--nbgb4ezh6w6ejdw7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
> >=20
> > Is it relevant in any way?
>=20
> 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
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.

> > 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.
>=20
> 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?
>=20
> 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,
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@linar=
o.org/
> >>
> >> About XFS: I don't think it is needed to boot anything.
> >=20
> > Just like 9P_FS, NFS or UBIFS.
>=20
> NFS is often used on targets, e.g. my board farm, but also by other peopl=
e.
>=20
> 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.

> >> 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.
> >=20
> > 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.
>=20
> 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.

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.

What I really don't get is this: this makes the life of people easier.

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
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
Fedora kernel configuration: it won't be, just like it isn't the Debian
kernel configuration.

However, it works for your board farm because it's just so much more
convenient, you can get a kernel from all the auto-builder and boot that
and you know that it's supposed to work. And that's totally reasonable.

So if it's convenient for you and your board farm, why do you oppose
other people trying to make it reasonably convenient for them?

Maxime

--nbgb4ezh6w6ejdw7
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZdYVwwAKCRDj7w1vZxhR
xQfIAP9aQIEniQ/41hUku1FMmbfk8C6uHIE42LCeZlNwAK37NwEA0gT5QzXSVMC8
w6iE/SmpnOSFNLVcqpa+35zgMWw3Uw0=
=cwHJ
-----END PGP SIGNATURE-----

--nbgb4ezh6w6ejdw7--