On Wed, Nov 6, 2024 at 11:32 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > That's not how standards work. It's behaviour undefined by the > > standard, i.e. undefined behaviour. If it isn't forbidden, or strictly > > defined, it's still standard compliant. > > I think we'll have to agree to disagree. If it's "undefined behaviour" > than it's not "standard compliant". > OK, let's agree to disagree. My point was that an implementation that has features undefined by some standard can be still standard compliant. And probably the one real noncompliance here is initrds on one line instead of multiline, which is a minor implementation problem. Although BLS isn't our primary goal (and it isn't enforced by any guideline) we are ready to fix it. > > But again, we are not implementing a boot loader or writing > > standard, we are using existing tool and its features. > > Well, no, that's just part of the situation. You are relying on the > quirks of a specific tool that has a known-buggy implementation of a > generic idea. Relying on those quirks was arguably never a good idea. > But what we're discussing in this thread is the fact that _your_ > implementation breaks boot and this is what needs to be fixed. > It wasn't TunedD who broke the boot. The boot worked with the default Fedora bootloader which is grub, which was de facto the standard for booting for decades. It broke because systemd-boot isn't drop in replacement and didn't care about backward compatibility. We have Fedora test days to catch such problems, but AFAIK nobody reported this problem. > > On a more constructive note, we need to add/remove kernel args and > > initrd overlays, because people, users, and customers want it. Telling > > them: do not touch it, will not work. Providing them instructions on > > how to do it... well it isn't rocket science, but it also isn't easy > > and good luck supporting it. Editing/parsing/generating the BLS > > entries: why reinvent the wheel here. Variables are a good compromise, > > because you can just set/edit variables through some API/tool and you > > don't need to touch the low level stuff. But we don't care about > > variables, if there will be some simple API/interface that will work > > across implementations we will happily switch to it and it would save > > us lot of time and possible troubles > > Sure, being able to change boot config is a real problem. If there > is an idea how to extend the standard to support new features, > please propose this and let's discuss the options. Any extension > may be accepted or rejected. But the approach of assuming that you > can just inject additional incomatible syntax downstream because > one specific tool supports this is wrong. > I don't think it's a good approach to break things and then search for standardization. Nevertheless, I think TuneD isn't the only project that would be interested in such an interface (for kernel args/initrds customization). Also TuneD upstream discussion: https://github.com/redhat-performance/tuned/pull/705 thanks & regards Jaroslav -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
