Message-ID: <CADWks+YUm+kCfZZkrCHE+x1ygdqLawyk+h4_ahac9+7b_AvbUw@mail.gmail.com>
Date:   Fri, 24 Nov 2023 18:06:01 +0000
From:   Dimitri John Ledkov <dimitri.ledkov@...onical.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Richard Henderson <richard.henderson@...aro.org>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Matt Turner <mattst88@...il.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H . Peter Anvin" <hpa@...or.com>, linux-alpha@...r.kernel.org,
        linux-m68k@...ts.linux-m68k.org, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] remove the last bits of a.out support

On Fri, 24 Nov 2023 at 14:36, Dimitri John Ledkov
<dimitri.ledkov@...onical.com> wrote:
>
> On Fri, 24 Nov 2023 at 06:01, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> >
> > Dimitri John Ledkov <dimitri.ledkov@...onical.com> writes:
> >
> > > I was working on how linux-libc-dev headers are shipped in Ubuntu and
> > > stumbled upon seemingly unused and useless linux/a.out.h header. It
> > > seems like it is an accidental leftover at this point.
> >
> > How do you see that they are unused?

When I did my code search the only and last remaining userspace code
that imports linux/a.out.h it is the objtool that is patched in these
patch series.
It is also vendored as copy in aboot tool, which has been patched in
many downstreams to use a.out.h instead of linux/a.out.h.

> >
> > Are they never exported to userspace?
> >

Yes it is exported for user-code to compile against. The question is
if any of them import it, or use it.

> > Are there any userspace programs that care?

Just the alpha objstrip tool in these series.

> >
> > Performing a quick debian code search I see chromium, qt6, ruby-rogue, hurd,
> > bazel_bootstrap, aboot, cde.
> >

chromium qt6 bazel cde - vendor a full linux source tree with
manifests, to build actual linux kernel as offered by a vendored
project or for bootstrapping toolchains. These are all unused by the
resulting userspace.

aboot - has the copy of arch/alpha/boot/tools/objstrip.c which is
patched in these series, to support booting a.out based alpha which is
gone. So self-referencing.

ruby-rogue is syntax highlight for Syzlang which is kernel syscall
fuzzing language, by definition it highlights things inside kernel,
and thus will be unused highlight code for kernel sources that dropped
a.out.h support and will do correctly syntax highlight for syszlang
source code that targets a.out.h capable kernels.

hurd - it is a pfinet server based on a vendored copy of linux source
tree, with its own copy of linux/a.out.h and its own copy of
affs_fs_i.h. It is based on the linux 2.2.12 partial tree. If they
upgrade networking code to a newer linux copy, it will be gone there
too.

> > I can imagine all kinds of reasons old code could be using headers for a
> > historical format.  Some of them are quite legitimate, and some of them
> > are quite silly.  If it is old code like aboot it may be that it is
> > difficult to test any changes.  If memory serves you have to flash your
> > firmware to change/test aboot.
> >
> > Because showing userspace does not care about the definitions in a file
> > is a completely different problem then showing the kernel does not care
> > about the definitions I left them, last time I was working in this area.
> > Keeping headers that will never change is not cost to the kernel so it
> > doesn't hurt us to be nice to historical userspace.
> >
> > My quick debian code search suggests that there are pieces of userspace
> > that still use linux/a.out.h.  Are you seeing something I am not?

Was your search
https://codesearch.debian.net/search?q=linux%2Fa.out.h&literal=1&perpkg=1
?

In which case none of them are header imports as compiled into any of
the userspace code. They are all vendored copies of linux code, either
unused or compiled as a kernel.

> > Do all of those pieces of code compile just fine with a.out.h missing?
> >

Yes, as none of them import it =) with objstrip being the last one.

>
> I will recheck the above mentioned things again, but as far as I could
> tell up to this point, is that things mostly use a.out.h provided by
> glibc.
>
> Separately, I can do this change in a test-rebuild of ubuntu archive
> of all packages on amd64,. as that's the only Ubuntu arch that ships
> linux/a.out.h.
>
> As far as I can tell, the legacy userspace access to linux/a.out.h can
> use glibc's a.out.h instead. But yes, it would be pain, if code
> changes are required to things.
>
> > Eric
> >
> >
> > > Dimitri John Ledkov (5):
> > >   alpha: remove a.out support from tools/objstrip
> > >   alpha: stop shipping a.out.h uapi headers
> > >   m68k: stop shipping a.out.h uapi headers
>
> I think above three patches still can be merged in m68k & alpha trees.
>
> > >   x86: stop shipping a.out.h uapi headers
> > >   uapi: remove a.out.h uapi header
> > >
>
> And these two need further validation now, based on Eric's input.

I believe all examples Eric pointed out are false-positives of Linux
source tree itself dating back to copies of 2.1.22.
Thus this should all be merged.

>
> > >  arch/alpha/boot/tools/objstrip.c    |  52 +-----
> > >  arch/alpha/include/uapi/asm/a.out.h |  92 ----------
> > >  arch/m68k/include/uapi/asm/a.out.h  |  21 ---
> > >  arch/x86/include/uapi/asm/a.out.h   |  21 ---
> > >  include/uapi/Kbuild                 |   4 -
> > >  include/uapi/linux/a.out.h          | 251 ----------------------------
> > >  6 files changed, 6 insertions(+), 435 deletions(-)
> > >  delete mode 100644 arch/alpha/include/uapi/asm/a.out.h
> > >  delete mode 100644 arch/m68k/include/uapi/asm/a.out.h
> > >  delete mode 100644 arch/x86/include/uapi/asm/a.out.h
> > >  delete mode 100644 include/uapi/linux/a.out.h

-- 
okurrr,

Dimitri

Powered by blists - more mailing lists