[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
From: Neal Becker <ndbecker2 () gmail ! com>
Date: 2023-12-29 12:29:32
Message-ID: CAG3t+pE6LyCdyeaMAny3kxjmx0NKN2AMfvB3RMGDCv8N+rtS5A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Dec 29, 2023 at 6:43 AM Zbigniew Jędrzejewski-Szmek <
zbyszek@in.waw.pl> wrote:
> On Thu, Dec 28, 2023 at 05:07:09PM +0000, Barry Scott wrote:
> >
> >
> > > On 28 Dec 2023, at 16:58, Chris Adams <linux@cmadams.net> wrote:
> > >
> > > 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}.
>
> Things that reset $PATH to "known" values are usually breaking things
> and doing unnecessary work. It is OK to extend the $PATH by inserting
> something (usually at the front), but systemd sets it to something
> appropriate on a given system for _everything_ that is started, so
> resetting it is not useful.
>
> It was very common to set the $PATH via .bash_profile or other
> shell-specific mechanisms. This is flexible and convenient, but the
> problem with that approach is that it happens too late: since now the
> system may get all the way the graphical interface without going
> through a shell, if we want $PATH to be set properly for the whole
> environment including service binaries started directly by systemd,
> this needs to be done by systemd itself. And once it has done that,
> it's not helpful if the shell also plays with $PATH, affecting some
> processes but not others.
>
> But yeah, it's possible that sometimes we'll and up with an environment
> with $PATH without the additional directories. That's OK: it will
> gracefully fall back to the generic versions. Hopefully, people
> will fix those environments over time.
>
> (Sudo is a special case: it needs to reset the path to avoid being
> influenced by the calling environment. But things started through sudo
> are generally not CPU-intenstive, so using the generic versions should
> be OK.)
>
> > Indeed, how would my shell get the right micro architecture into its
> PATH?
> > Would konsole on plasma desktop picking up PATH from systemd?
>
> Yes. If should already be doing that.
>
> > The alternative would be to symlink the "right" version of a
> program/library from
> > the micro architecture dir into /usr/bin and /usr/lib maybe?
>
> The approaches with glibc-hwcaps and the proposed path-based thing for
> binaries
> have the advantage that they are dynamic. The same image can be used on
> different
> machines. It may even be read-only. In particular, in case of VMs, if we
> stop
> the VM, move it to a different host or change it's CPU settings, and
> restart it,
> it'll gracefully DTRT. It also important that the system remains functional
> even if a CPU downgrade happens for any reason.
>
> We _could_ take the approach with symlinks. Most likely, this would be
> handled
> via alternatives, i.e. the symlinks would go through /etc, i.e.
> /usr/bin/foo
> → /etc/alternatives/foo → /usr/lib-something/bin/foo. This is doable, but I
> like the dynamic approach much more.
>
> Also, glibc-hwcaps are implemented and available since glibc 2.33.
> Combining a static symlink-based system for binaries with a dynamic
> path-based system for libraries would be very strange.
>
> On a philosophical note, I once worked on Apollo workstations. These
could switch behavior between sysv and bsd unix. To do this, the kernel
would interpret e.g. /usr/bin/$arch, substituting the env variable arch.
At least that is my recollection of how this worked. Elegant I think, but
some might see this as a security problem.
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Fri, Dec 29, 2023 at 6:43 AM Zbigniew Jędrzejewski-Szmek \
<<a href="mailto:zbyszek@in.waw.pl">zbyszek@in.waw.pl</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Dec 28, 2023 \
at 05:07:09PM +0000, Barry Scott wrote:<br> > <br>
> <br>
> > On 28 Dec 2023, at 16:58, Chris Adams <<a \
href="mailto:linux@cmadams.net" target="_blank">linux@cmadams.net</a>> wrote:<br> \
> > <br> > > Anything that depends on PATH entries is IMHO doomed to \
failure.<br> > > There are way too many things that explicitly set PATH to \
"known"<br> > > values (for good and bad reasons) to be able to \
depend on<br> > > extending it. Heck, it took a long time to get sudo just \
to<br> > > include /usr/local/{bin,sbin}.<br>
<br>
Things that reset $PATH to "known" values are usually breaking things<br>
and doing unnecessary work. It is OK to extend the $PATH by inserting<br>
something (usually at the front), but systemd sets it to something<br>
appropriate on a given system for _everything_ that is started, so<br>
resetting it is not useful.<br>
<br>
It was very common to set the $PATH via .bash_profile or other<br>
shell-specific mechanisms. This is flexible and convenient, but the<br>
problem with that approach is that it happens too late: since now the<br>
system may get all the way the graphical interface without going<br>
through a shell, if we want $PATH to be set properly for the whole<br>
environment including service binaries started directly by systemd,<br>
this needs to be done by systemd itself. And once it has done that,<br>
it's not helpful if the shell also plays with $PATH, affecting some<br>
processes but not others.<br>
<br>
But yeah, it's possible that sometimes we'll and up with an environment<br>
with $PATH without the additional directories. That's OK: it will<br>
gracefully fall back to the generic versions. Hopefully, people<br>
will fix those environments over time.<br>
<br>
(Sudo is a special case: it needs to reset the path to avoid being<br>
influenced by the calling environment. But things started through sudo<br>
are generally not CPU-intenstive, so using the generic versions should<br>
be OK.)<br>
<br>
> Indeed, how would my shell get the right micro architecture into its PATH?<br>
> Would konsole on plasma desktop picking up PATH from systemd?<br>
<br>
Yes. If should already be doing that.<br>
<br>
> The alternative would be to symlink the "right" version of a \
program/library from<br> > the micro architecture dir into /usr/bin and /usr/lib \
maybe?<br> <br>
The approaches with glibc-hwcaps and the proposed path-based thing for binaries<br>
have the advantage that they are dynamic. The same image can be used on different<br>
machines. It may even be read-only. In particular, in case of VMs, if we stop<br>
the VM, move it to a different host or change it's CPU settings, and restart \
it,<br> it'll gracefully DTRT. It also important that the system remains \
functional<br> even if a CPU downgrade happens for any reason.<br>
<br>
We _could_ take the approach with symlinks. Most likely, this would be handled<br>
via alternatives, i.e. the symlinks would go through /etc, i.e. /usr/bin/foo<br>
→ /etc/alternatives/foo → /usr/lib-something/bin/foo. This is doable, but I<br>
like the dynamic approach much more. <br>
<br>
Also, glibc-hwcaps are implemented and available since glibc 2.33.<br>
Combining a static symlink-based system for binaries with a dynamic<br>
path-based system for libraries would be very strange.<br>
<br></blockquote><div>On a philosophical note, I once worked on Apollo workstations. \
These could switch behavior between sysv and bsd unix. To do this, the kernel would \
interpret e.g. /usr/bin/$arch, substituting the env variable arch. At least that is \
my recollection of how this worked. Elegant I think, but some might see this as a \
security problem. </div></div></div>
[Attachment #6 (text/plain)]
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic