From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Cc: Richard Henderson <richard.henderson@linaro.org>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H . Peter Anvin" <hpa@zytor.com>,
linux-alpha@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] remove the last bits of a.out support
Date: Fri, 24 Nov 2023 00:00:15 -0600 [thread overview]
Message-ID: <87plzzu1w0.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <20231123180246.750674-1-dimitri.ledkov@canonical.com> (Dimitri John Ledkov's message of "Thu, 23 Nov 2023 18:02:40 +0000")
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
next prev parent reply other threads:[~2023-11-24 6:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-23 18:02 [PATCH 0/5] remove the last bits of a.out support Dimitri John Ledkov
2023-11-23 18:02 ` [PATCH 1/5] alpha: remove a.out support from tools/objstrip Dimitri John Ledkov
2023-11-23 18:02 ` [PATCH 2/5] alpha: stop shipping a.out.h uapi headers Dimitri John Ledkov
2023-11-23 18:02 ` [PATCH 3/5] m68k: " Dimitri John Ledkov
2023-11-23 18:48 ` Geert Uytterhoeven
2023-11-23 18:02 ` [PATCH 4/5] x86: " Dimitri John Ledkov
2023-11-30 19:25 ` Ingo Molnar
2023-11-23 18:02 ` [PATCH 5/5] uapi: remove a.out.h uapi header Dimitri John Ledkov
2023-11-24 6:00 ` Eric W. Biederman [this message]
2023-11-24 14:36 ` [PATCH 0/5] remove the last bits of a.out support Dimitri John Ledkov
2023-11-24 18:06 ` Dimitri John Ledkov
2023-11-25 4:31 ` Eric W. Biederman
2023-11-24 20:47 ` Michael Cree
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87plzzu1w0.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dimitri.ledkov@canonical.com \
--cc=geert@linux-m68k.org \
--cc=hpa@zytor.com \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=mattst88@gmail.com \
--cc=mingo@redhat.com \
--cc=richard.henderson@linaro.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).