These options are needed by some Linux distributions (e.g: Fedora), so
let's enable them to make it easier for developers using such distros.
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Brian Masney <[email protected]>
---
Changes in v2:
- Add Brian Masney's Reviewed-by tag.
- Drop CONFIG_MODULE_COMPRESS_XZ, it's OK to build uncompressed kernel modules.
arch/arm64/configs/defconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 056a6cc546a4..b062d6ca7f5e 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -241,6 +241,7 @@ CONFIG_PCI_EPF_TEST=m
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_FW_LOADER_USER_HELPER=y
+CONFIG_FW_LOADER_COMPRESS=y
CONFIG_HISILICON_LPC=y
CONFIG_TEGRA_ACONNECT=m
CONFIG_MHI_BUS_PCI_GENERIC=m
@@ -275,6 +276,8 @@ CONFIG_MTD_NAND_FSL_IFC=y
CONFIG_MTD_NAND_QCOM=y
CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_UBI=m
+CONFIG_ZRAM=m
+CONFIG_ZRAM_WRITEBACK=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_VIRTIO_BLK=y
@@ -1595,6 +1598,7 @@ CONFIG_HTE_TEGRA194_TEST=m
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
+CONFIG_XFS_FS=m
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
CONFIG_FANOTIFY=y
--
2.43.0
On 21/02/2024 16:10, 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.
>
>>
>> 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.
BTW, each commit adding such options is supposed to explain why there
are needed, so please go to the git log and answer yourself why there
are there. I am pretty sure I will ack/review removal of every option
added without answering "why".
Don't twist the discussion of necessity of Kconfig options, because each
commit should stand on its own.
Best regards,
Krzysztof
Hi Krzysztof,
On Wed, Feb 21, 2024 at 4:10 PM Krzysztof Kozlowski
<[email protected]> wrote:
> UBIFS was added recently because one device was using it - you needed
> it. 9P_FS looks unnecessary.
9P_FS is used commonly for file transfer between host and guest, cfr.
commit af9b99647cd2a6a2 ("arm64: defconfig: add virtio support for
running as a kvm guest").
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
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
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.
>
> 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,
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/[email protected]/
> >>
> >> 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.
> >> 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.
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
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/[email protected]/
>>>>
>>>> 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
On Wed, Feb 21, 2024, at 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
> 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.
It's definitely enough for me. It makes a lot of sense to have
a defconfig that boots common and popular distros.
I don't use ZRAM either, but I can see that being useful to
avoid swapping to SD cards or eMMC when that is the only
available swap device.
>> >> I kind of repeat comments from similar patch earlier:
>> >> https://lore.kernel.org/all/[email protected]/
>> >>
>> >> 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.
I think we want all of the above. We can probably drop ext2 since
we already need ext4, but that is a different question.
>> 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.
We had previously discussed adding config fragments for common
distros the way we have kvm_guest.config, but if the Javier's
patch is all that is actually needed for Fedora, that seems better
to me than the added complexity of fragments.
Arnd
On 21/02/2024 16:41, Arnd Bergmann wrote:
> On Wed, Feb 21, 2024, at 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
>> 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.
>
> It's definitely enough for me. It makes a lot of sense to have
> a defconfig that boots common and popular distros.
>
> I don't use ZRAM either, but I can see that being useful to
> avoid swapping to SD cards or eMMC when that is the only
> available swap device.
>
>>>>> I kind of repeat comments from similar patch earlier:
>>>>> https://lore.kernel.org/all/[email protected]/
>>>>>
>>>>> 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.
>
> I think we want all of the above. We can probably drop ext2 since
> we already need ext4, but that is a different question.
I'll send a patch. Ext3 is there as well.
Best regards,
Krzysztof
On Wed, Feb 21, 2024 at 04:41:38PM +0100, Arnd Bergmann wrote:
> On Wed, Feb 21, 2024, at 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
> > 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.
>
> It's definitely enough for me. It makes a lot of sense to have
> a defconfig that boots common and popular distros.
>
> I don't use ZRAM either, but I can see that being useful to
> avoid swapping to SD cards or eMMC when that is the only
> available swap device.
>
> >> >> I kind of repeat comments from similar patch earlier:
> >> >> https://lore.kernel.org/all/[email protected]/
> >> >>
> >> >> 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.
>
> I think we want all of the above. We can probably drop ext2 since
> we already need ext4, but that is a different question.
>
> >> 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.
>
> We had previously discussed adding config fragments for common
> distros the way we have kvm_guest.config, but if the Javier's
> patch is all that is actually needed for Fedora, that seems better
> to me than the added complexity of fragments.
Oh, right. Fragments would be a great tool to reconcile the need for
minimal boot time and supporting reasonable use-cases.
I guess it's even more of a struggle with the single arm64 defconfig vs
the minimal vs batteries included defconfig setup we had for arm.
Maxime
On Wed, Feb 21, 2024 at 04:53:26PM +0100, Krzysztof Kozlowski wrote:
> It would be cool to group also all the per-SoC needs in dedicated
> fragments...
It would also be nice to have a fragment to enable the various tracing
options.
Brian
On 21/02/2024 16:51, Maxime Ripard wrote:
>>> 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.
>>
>> We had previously discussed adding config fragments for common
>> distros the way we have kvm_guest.config, but if the Javier's
>> patch is all that is actually needed for Fedora, that seems better
>> to me than the added complexity of fragments.
>
> Oh, right. Fragments would be a great tool to reconcile the need for
> minimal boot time and supporting reasonable use-cases.
>
> I guess it's even more of a struggle with the single arm64 defconfig vs
> the minimal vs batteries included defconfig setup we had for arm.
It would be cool to group also all the per-SoC needs in dedicated
fragments...
Best regards,
Krzysztof
On Wed, Feb 21, 2024 at 10:56:20AM -0500, Brian Masney wrote:
> On Wed, Feb 21, 2024 at 04:53:26PM +0100, Krzysztof Kozlowski wrote:
> > It would be cool to group also all the per-SoC needs in dedicated
> > fragments...
>
> It would also be nice to have a fragment to enable the various tracing
> options.
+1, I cannot tell you the number of times I've been burned by the
defconfig not having those enabled and me forgetting :)
Krzysztof Kozlowski <[email protected]> writes:
> 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...
>
I usually try hard not to be vague. There was a why, it wasn't enough for
you and that's fair.
But I think the crux of the why was explained: I don't want to remember
each time that need to troubleshoot something, what options are missing
in order to boot Fedora.
>> 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 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
another thing to remember when trying to boot an upstream kernel built.
Could had added all this information to the commit message but I thought
that it would be too much...
>>
>>>> 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/[email protected]/
>>>>>
>>>>> 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.
>
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.
>>
>>>>> 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.
>>
Which distro? Every one uses a different filesystem. SUSE uses btrfs,
Debian I think ext4, Fedora uses xfs and so on. It's OK if the policy
is that the defconfig should only be compatible with Debian, but then
should be written somewhere.
>> 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.
>
And not having it enabled makes my life (and other fedora users) harder
because xfs needs to be enabled every time that an upstream kernel needs
to be tested.
>>
>> 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.
>
It's not a distro need in my opinion but an upstream kernel developer
need. If I have had chosen xfs for personal preference, would that be
any different?
>
>> 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"
>
The benefit is for developers who use Fedora to be able to boot their
kernels built using defconfig, just like developers using other distros
can now. We already have ext4 and btrfs, but somehow xfs is not OK.
> Best regards,
> Krzysztof
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Maxime Ripard <[email protected]> writes:
> On Wed, Feb 21, 2024 at 04:41:38PM +0100, Arnd Bergmann wrote:
>> On Wed, Feb 21, 2024, at 16:24, Maxime Ripard wrote:
[...]
>> > 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.
>>
>> We had previously discussed adding config fragments for common
>> distros the way we have kvm_guest.config, but if the Javier's
>> patch is all that is actually needed for Fedora, that seems better
>> to me than the added complexity of fragments.
>
> Oh, right. Fragments would be a great tool to reconcile the need for
> minimal boot time and supporting reasonable use-cases.
>
> I guess it's even more of a struggle with the single arm64 defconfig vs
> the minimal vs batteries included defconfig setup we had for arm.
>
I'm OK with using fragments instead and propose a fedora.config or
whatever name is decided for this.
As long as the list is kept in the mainline repo, instead of every
Fedora developer having to make local changes in their .config, it
works for me.
> Maxime
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 21/02/2024 20:34, Javier Martinez Canillas wrote:
> Krzysztof Kozlowski <[email protected]> writes:
>
>> 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...
>>
>
> I usually try hard not to be vague. There was a why, it wasn't enough for
> you and that's fair.
>
> But I think the crux of the why was explained: I don't want to remember
> each time that need to troubleshoot something, what options are missing
> in order to boot Fedora.
>
>>> 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 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.
> another thing to remember when trying to boot an upstream kernel built.
>
> Could had added all this information to the commit message but I thought
> that it would be too much...
>
>>>
>>>>> 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/[email protected]/
>>>>>>
>>>>>> 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.
>>
>
> 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
about it, but since Arnd agrees on XFS I won't fight that battle.
>
>>>
>>>>>> 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.
>>>
>
> Which distro? Every one uses a different filesystem. SUSE uses btrfs,
> Debian I think ext4, Fedora uses xfs and so on. It's OK if the policy
> is that the defconfig should only be compatible with Debian, but then
> should be written somewhere.
Hm, don't all these distros support choosing the filesystem? I did not
propose Ext4 because Debian is more important or something, but because
we need to choose something and it is kind of default for many people.
>
>>> 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.
>>
>
> And not having it enabled makes my life (and other fedora users) harder
> because xfs needs to be enabled every time that an upstream kernel needs
> to be tested.
We can here disagree that we might have a bit different needs... I just
provided argument why I object.
>
>>>
>>> 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.
>>
>
> It's not a distro need in my opinion but an upstream kernel developer
> need. If I have had chosen xfs for personal preference, would that be
> any different?
>
>>
>>> 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"
>>
>
> The benefit is for developers who use Fedora to be able to boot their
> kernels built using defconfig, just like developers using other distros
> can now. We already have ext4 and btrfs, but somehow xfs is not OK.
I would drop btrfs :)
Best regards,
Krzysztof
Krzysztof Kozlowski <[email protected]> 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
On 22/02/2024 10:09, Javier Martinez Canillas wrote:
> Krzysztof Kozlowski <[email protected]> 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