On 1/19/24 12:58 PM, Robert Marcano wrote:
On 12/28/23 1:25 PM, Robert Marcano wrote:
On 12/28/23 12:58 PM, Chris Adams wrote:
Once upon a time, Aoife Moloney <amoloney@xxxxxxxxxx> said:
Systemd will be modified to insert the additional directories into the
`$PATH` environment variable (affecting all programs on the system)
Anything that depends on PATH entries is IMHO doomed to failure. There
are way too many things that explicitly set PATH to "known" values (for
good and bad reasons) to be able to depend on extending it. Heck, it
took a long time to get sudo just to include /usr/local/{bin,sbin}.
Maybe replacing the /usr/bin related entries with a generic wrapper
that launch the best binary from the per architecture directories.
Note: This may affect a few programs that use argv[0] for something
meaningful.
The more I think about this, I am more convinced that /usr/bin installed
binaries must do this redirection too even in the case the PATH is
modified as this proposal states.
What about programs intentionally use absolute paths? These programs
will not take advantage of the optimizations of the binary they are
trying to start.
There many reasons for sometimes using an absolute path is agood idea,
like:
1. Security: avoid depending on a PATH that can be user manipulated.
2. Configuration files that allow to switch to alternate implementation
of the tool they call. I found a few on my installation, and their
defaults include /usr/bin absolute paths.
3. Programs that run inside PATH is reset for security like sudo,
CGI-BIN, etc.
Notice this PATH based optimization will only work when callers invoke
the program by name only, relative paths will not get optimized either,
a rare case but it could happen.
I have a counter proposal without modifying $PATH:
With the already defined directories
/usr/bin/glibc-hwcaps/x86-64-v{2,3,4}/ add two new ones:
/usr/bin/glibc-hwcaps/x86-64
/usr/bin/glibc-hwcaps/x86-64-dynamic
Applications with optimized binaries will continue to install them on
/usr/bin/glibc-hwcaps/x86-64-v{2,3,4}/ but the non optimized version
isn't installed on /usr/bin but on /usr/bin/glibc-hwcaps/x86-64.
/usr/bin/glibc-hwcaps/x86-64-dynamic will be a read only overlayfs
mounted by systemd, stacked with x86-64v4 on top and x86-64 on the bottom.
There will not be /usr/bin binaries for the optimized packages but
symlinks to /usr/bin/glibc-hwcaps/x86-64-dynamic
Advantages for systemd based environment:
1. The optimized binaries are available to all the system, without
worrying about applications that reset $PATH, or executions by relative
or absolute paths and not only by name.
2. Imagine if and application like Firefox (only an example) get a boost
by having the main binary optimized. /usr/bin/firefox currently is a
shell script, there is no way optimize it with the current proposal,
only if the script duplicates the microachitecture selection logic. With
this proposal, modifying /usr/lib64/firefox/firefox to point to
/usr/bin/glibc-hwcaps/x86-64-dynamic/firefox could work to. In reality
it can work for all binaries outside of $PATH.
There are two downsides I could find:
1. Fedora Container images must be build with
/usr/bin/glibc-hwcaps/x86-64-dynamic being a symlink to
/usr/bin/glibc-hwcaps/x86-64 in order to non optimized binaries to be
the default. This current proposal doesn't optimize either for
containers runtimes that don't run systemd inside the container. Maybe
in the future if this kind of layout get adoption on other
distributions, container runtimes could do the overlay mount by themselves
2. In the case of trying to rescue the system, the process to create a
chroot from the installation media will need and extra bind mount for
/usr/bin/glibc-hwcaps/x86-64-dynamic pointing to
/usr/bin/glibc-hwcaps/x86-64
Note aside: I think that the Live CD image should get an script
available that do the same rescue boot option when trying to build the
disk tree on /mnt/sysimage, if that script were available on LiveCD,
rescue operations would be easier.
--
_______________________________________________
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
