The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Javier Martinez Canillas <javierm@redhat.com>,
	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 12:17:36 +0100	[thread overview]
Message-ID: <87f2c94b-fbda-4a7d-8570-2c5a15964546@linaro.org> (raw)
In-Reply-To: <87r0h47tlp.fsf@minerva.mail-host-address-is-not-set>

On 22/02/2024 10:09, Javier Martinez Canillas wrote:
> 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.
> 
> [...]

Thanks.

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

No worries, I did not notice. Everything seemed fine for me.

Best regards,
Krzysztof


  reply	other threads:[~2024-02-22 11:17 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
2024-02-22 11:17                 ` Krzysztof Kozlowski [this message]
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=87f2c94b-fbda-4a7d-8570-2c5a15964546@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bmasney@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=eballetbo@redhat.com \
    --cc=geert+renesas@glider.be \
    --cc=javierm@redhat.com \
    --cc=konrad.dybcio@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