Re: [systemd-devel] Fixup-support for kernel command line provided from UKI in systemd-stub
HI @Luca Boccassi, Looks like this addons is to append additional cmd-line parameters with static data. Our requirement is to append additional cmd-line parameters with dynamic device specific data like, serial number read from the device during runtime. Thanks & Regards, Venkat Thogaru -Original Message- From: Luca Boccassi Sent: Tuesday, November 28, 2023 4:34 PM To: VENKAT Nagaraj THOGARU (QUIC) Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Fixup-support for kernel command line provided from UKI in systemd-stub On Tue, 28 Nov 2023 at 10:30, VENKAT Nagaraj THOGARU (QUIC) wrote: > > Hi @systemd-devel@lists.freedesktop.org, > > > > We have a query on Fixup-support for kernel command line provided from UKI in > system-stub. > > > > Just like we have the Fixup support for DTB provided from UKI in > systemd-stub[via EFI_DT_FIXUP_PROTOCOL], do we have any similar fixup support > for Kernel command line provided from UKI ? If not, is there any ongoing > effort to support this? > > > > Our requirement is to dynamically append the additional command line > parameters to the command line provided from UKI. Check the addons section: https://www.freedesktop.org/software/systemd/man/latest/systemd-stub.html#Companion%20Files
Re: [systemd-devel] Fixup-support for kernel command line provided from UKI in systemd-stub
HI @Aleksandar Kostadinov, Yeah, we already passed this cmd line from UKI, generated with ukify the same way. Our requirement is to update the command line with additional parameters on top of cmd-line passed from UKI dynamically. Thanks & Regards, Venkat Thogaru -Original Message- From: Aleksandar Kostadinov Sent: Tuesday, November 28, 2023 3:26 PM To: VENKAT Nagaraj THOGARU (QUIC) Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Fixup-support for kernel command line provided from UKI in systemd-stub How do you create the UKI? What I do is adding `--cmdline=@/etc/kernel/cmdline` to the ukify command line. On Tue, Nov 28, 2023 at 11:30 AM VENKAT Nagaraj THOGARU (QUIC) wrote: > > Hi @systemd-devel@lists.freedesktop.org, > > > > We have a query on Fixup-support for kernel command line provided from UKI in > system-stub. > > > > Just like we have the Fixup support for DTB provided from UKI in > systemd-stub[via EFI_DT_FIXUP_PROTOCOL], do we have any similar fixup support > for Kernel command line provided from UKI ? If not, is there any ongoing > effort to support this? > > > > Our requirement is to dynamically append the additional command line > parameters to the command line provided from UKI. > > > > Thanks & Regards, > > Venkat Thogaru
Re: [systemd-devel] How to properly wait for udev?
On Wed, Nov 29, 2023 at 9:48 AM Lennart Poettering wrote: > > Why doesn't udev flock() every device it is probing? > > Or asked differently, why is this feature opt-in instead of opt-out? > > Some software really doesn't like it if we take BSD locks on their > devices, hence we don't take it blanket everywhere. And what's more > important even: for various devices it simply isn't safe to just > willy-nilly even open them (tape drivers and things, which might start > to pull in a tape if we do). For others we might not be able to even > open thing at all with the wrong flags (for example, because they are > output only). > > Bock devices have relatively well defined semantics, there it's > generally safe to do this, hence we do. I see. > Hence, it might be safe for UBI, but for the general case it might > not be. > > That said, would BSD locking even address your issue? If you devices > are exclusive access things and we first open() them and then flock() > them, then that's not atomic. So if your test cases open the devices, > then flock() them you might still get into conflict udev because it > just open()ed the device, but didn#t get to call flock() yet. > > Doesn't UBI have something like O_EXCL-behaviour that grants true > exclusive access? It has in-kernel support for that but not from userspace, I'm currently evaluating whether it's worth exposing exclusive access to userspace. Stay tuned. :-) -- Thanks, //richard
Re: [systemd-devel] [help] Benchmarking software shows degraded performance
On Wed, Nov 29, 2023 at 09:36:04PM -0800, Christian Hergert wrote: > On 11/29/23 8:09 PM, nayabbasha.sa...@microchip.com wrote: > > One of the benchmark case is, where it simply opens graphical window on > > LCD screen and then simply closes it. For this case, the egt-benchmark > > shows 9 iterations/sec for busybox init. And it's only 5 iterations/sec > > for systemd init. > > Have you run perf or some other whole-system profiler on the system to see > what time is spent in what process and how the systemd case differs from the > busybox case? Does perf even support these single core SoCs? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] [help] Benchmarking software shows degraded performance
On Thu, Nov 30, 2023 at 1:17 AM wrote: > Hi all, > > We have decided to replace buysbox init with systemd in our development > boards Buildroot images. > > One of the boards - > https://www.microchip.com/en-us/development-tool/atsama5d27-som1-ek1 > > While we notice the reduction in boot time as well as the systemd > features useful (ex: systemd-networkd), we notice the degraded > performance when we run bench-marking software. > > Benchmarking software uri - https://github.com/linux4sam/egt-benchmark. > > One of the benchmark case is, where it simply opens graphical window on > LCD screen and then simply closes it. For this case, the egt-benchmark > shows 9 iterations/sec for busybox init. And it's only 5 iterations/sec > for systemd init. > > We have gone through some of the techniques mentioned in the bootlin's > debugging slides > (https://bootlin.com/doc/training/debugging/debugging-slides.pdf) to > optimize the system performance. Didn't help much. > > Note that all the development boards we use are single core SoCs. > > Any pointers that would lead to narrow down the issue would be grateful > here. Thanks in advance. > > -- > Thanks, > Nayab > > Nayab: Without profiler data before/after it is just speculation that systemd got anything to do with this.
