public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Maxime Ripard <mripard@redhat.com>
Cc: 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
Date: Thu, 22 Feb 2024 10:09:54 +0100	[thread overview]
Message-ID: <87r0h47tlp.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <bd071521-7f7b-41e8-8786-ad2eeb58b03e@linaro.org>

Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> writes:

> On 21/02/2024 20:34, Javier Martinez Canillas wrote:

[...]

>>>
>>> Any explanation what ZRAM is necessary for Fedora to boot.
>>>
>> 
>> I mentioned already in another email, Fedora is enabling the systemd
>> zram-generator and not having a /dev/zram0 slows down the boot to the
>> point of being unusable. One could disable that service but then is yet
>
> That one sentence would be enough for me.
>

I'll add that then to the commit message when proposing a config fragment.

[...]

>> 
>> So that means that for aarch64, some filesystems have more precedence over
>> others? It's OK to have ext4 or btrfs but no xfs? Honestly it seems quite
>> arbitrary and subjective for me.
>
> Yes, subjective, but to be honest: I would drop Btrfs. I was thinking

Fair. If the agreegment is to minimize defconfig (which AFAIU is your
point), then I'm on board with it. We can start splitting in separate
fragments, people can then mix and match for their specific use cases.

> about it, but since Arnd agrees on XFS I won't fight that battle.
>

Yeah, it was a strange hill for me to die on and is true that fragments
seems to be the best compromise, as Maxime said before in this thread.

By the way, I want to apologize for my harsh/rude comments yesterday. I
wasn't in the best mood and I got too emotional...

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-02-22  9:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-21 14:13 [PATCH v2] arm64: defconfig: Enable zram, xfs and loading compressed FW support Javier Martinez Canillas
2024-02-21 14:22 ` Krzysztof Kozlowski
2024-02-21 14:48   ` Maxime Ripard
2024-02-21 15:10     ` Krzysztof Kozlowski
2024-02-21 15:14       ` Krzysztof Kozlowski
2024-02-21 15:20       ` Geert Uytterhoeven
2024-02-21 15:24       ` Maxime Ripard
2024-02-21 15:38         ` Krzysztof Kozlowski
2024-02-21 19:34           ` Javier Martinez Canillas
2024-02-22  8:40             ` Krzysztof Kozlowski
2024-02-22  9:09               ` Javier Martinez Canillas [this message]
2024-02-22 11:17                 ` Krzysztof Kozlowski
2024-02-21 15:41         ` Arnd Bergmann
2024-02-21 15:46           ` Krzysztof Kozlowski
2024-02-21 15:51           ` Maxime Ripard
2024-02-21 15:53             ` Krzysztof Kozlowski
2024-02-21 15:56               ` Brian Masney
2024-02-21 16:50                 ` Andrew Halaney
2024-02-21 21:56             ` Javier Martinez Canillas
2024-02-21 14:55   ` Javier Martinez Canillas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r0h47tlp.fsf@minerva.mail-host-address-is-not-set \
    --to=javierm@redhat.com \
    --cc=arnd@arndb.de \
    --cc=bmasney@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=eballetbo@redhat.com \
    --cc=geert+renesas@glider.be \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mripard@redhat.com \
    --cc=neil.armstrong@linaro.org \
    --cc=nunes.erico@gmail.com \
    --cc=quic_bjorande@quicinc.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox