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.

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
  x86: stop shipping a.out.h uapi headers
  uapi: remove a.out.h uapi header

 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

-- 
2.34.1

Dimitri John Ledkov <dimitri.ledkov@canonical.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?

Are they never exported to userspace?

Are there any userspace programs that care?

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

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?
Do all of those pieces of code compile just fine with a.out.h missing?

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
>   x86: stop shipping a.out.h uapi headers
>   uapi: remove a.out.h uapi header
>
>  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

On Fri, Nov 24, 2023 at 12:00:15AM -0600, Eric W. Biederman wrote:
> Dimitri John Ledkov <dimitri.ledkov@canonical.com> writes:
> 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.

No, aboot is written to the first sectors of the boot disk. Yes, there
is a special utilty in the aboot tools to write aboot to the boot
sectors and make sure that there is no overlap with the first
partition.

Cheers
Michael.

On Fri, 24 Nov 2023 at 06:01, Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> Dimitri John Ledkov <dimitri.ledkov@canonical.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?
>
> Are they never exported to userspace?
>
> Are there any userspace programs that care?
>
> Performing a quick debian code search I see chromium, qt6, ruby-rogue, hurd,
> bazel_bootstrap, aboot, cde.
>
> 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?
> Do all of those pieces of code compile just fine with a.out.h missing?
>

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.

> >  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

On Fri, 24 Nov 2023 at 14:36, Dimitri John Ledkov
<dimitri.ledkov@canonical.com> wrote:
>
> On Fri, 24 Nov 2023 at 06:01, Eric W. Biederman <ebiederm@xmission.com> wrote:
> >
> > Dimitri John Ledkov <dimitri.ledkov@canonical.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

Dimitri John Ledkov <dimitri.ledkov@canonical.com> writes:

> On Fri, 24 Nov 2023 at 14:36, Dimitri John Ledkov
> <dimitri.ledkov@canonical.com> wrote:
>>
>> On Fri, 24 Nov 2023 at 06:01, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> >
>> > Dimitri John Ledkov <dimitri.ledkov@canonical.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.

It sounds like you have done your homework.

Please just document (as you in your reply to me) in your cover letter
or elsewhere in the changes so that it is clear that due diligence has
been performed and userspace should not break with this change.

[snip]

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

Pretty much.  I didn't have the perpkg=1.

Debian code search is the most comprehensive code search I am aware
of so I took a quick look.

Since it appears the only users are vendored versions of linux/a.out.h
then it should be possible to make this change without breaking
userspace.  If it turns that is wrong the changes can be reverted.

Eric