| Message ID | 20240221141350.3740488-1-javierm@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] arm64: defconfig: Enable zram, xfs and loading compressed FW support | expand |
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.
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.
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.
Best regards,
Krzysztof
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? 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. > 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. > 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. Maxime
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> writes: > 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. > I haven't used Debian in ages so I don't know why is not a problem there. But Fedora is using zram by default and if is not enabled in the kernel, the boot is delayed considerably due the systemd zram-generator. > I kind of repeat comments from similar patch earlier: > https://lore.kernel.org/all/fe1e74a2-e933-7cd9-f740-86d871076191@linaro.org/ > Ah! I forgot that posted the same change for exynos_defconfig some time ago and I see that you nacked. Now I understand why all my Exynos boards are in a drawer. > About XFS: I don't think it is needed to boot anything. > How are you supposed to mount a XFS rootfs without at least have support for it as a module? > This is a defconfig, not a distro config. Please don't make it distro. > It seems that's a Debian distro config though, since you brought Debian as an example. > I will gladly support things needed by systemd or equivalent, but not > unusual filesystems needed by distro. > Fair. But then you should probably remove all the other filesystems that are already in the defconfig then? $ grep "_FS=" arch/arm64/configs/defconfig | wc -l 15 Or it is OK to have support for btrfs, overlayfs, even plan9 fs but XFS is where you draw the line?? > Best regards, > Krzysztof >
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. 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. > >> 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. > >> 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. I was working in distro so trust me - they do stuff differently and they not need XFS in our defconfig for anything. Best regards, Krzysztof
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 <krzysztof.kozlowski@linaro.org> 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
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/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. > >> 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/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
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/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. 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/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. > > 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/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. > > 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 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 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 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 <krzysztof.kozlowski@linaro.org> 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/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. > 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 >
Maxime Ripard <mripard@redhat.com> 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
On 21/02/2024 20:34, Javier Martinez Canillas wrote: > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> 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/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. >> > > 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 <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...
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
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