Re: [PATCH] x86: Deprecate a.out support
Hi Linus, I'm Jon, and I just bought my first Alpha. What can I say, I was late to the party, and I probably need to get out more. Actually, I wanted it for its memory consistency model, or (some would say) lack thereof. On 3/11/19 3:03 PM, Linus Torvalds wrote: > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård wrote: >> >> The latest version I have is 5.1, and that uses ECOFF. > > ECOFF _is_ a.out as far as Linux is concerned. > > So Linux basically treats ECOFF as "regular a.out with just some > header extensions". > > We don't have any specific support for ECOFF. > > I _think_. Again, it's been years and years. ...so removing a.out would break various boot tooling as well. I'm still working on getting my Miata up and running upstream kernels (should be shortly) but I'm happy to help out testing any proposals. Jon.
Re: [PATCH] x86: Deprecate a.out support
On Tue, Mar 12, 2019 at 9:46 AM Geert Uytterhoeven wrote: > > Yeah, the alphas on the server side, powering AltaVista, are also long > gone... As usual with these things, people can still use older Linux releases for a very long time. If they really need it (e.g. commercially), they have the reference code and can bring it up to speed again relatively easily. It is not as if they have no way to submit it back again. Cheers, Miguel
Re: [PATCH] x86: Deprecate a.out support
On Mon, Mar 11, 2019 at 10:46 PM Linus Torvalds
wrote:
> On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann wrote:
> > The main historic use case I've heard of was running Netscape
> > Navigator on Alpha Linux, before there was an open source version.
> > Doing this today to connect to the open internet is probably
> > a bit pointless, but there may be other use cases.
>
> The _really_ main version was that I decided to make my life easier
> for the initial alpha port by trying to run basic (tested) OSF/1
> binaries directly.
>
> Netscape may have been one of the binaries people actually ended up
> using, but it's probably not a reason any more, since the internet has
> moved past that anyway.
Yeah, the alphas on the server side, powering AltaVista, are also long
gone...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] x86: Deprecate a.out support
On Mon, Mar 11, 2019 at 03:11:55PM -0700, Matt Turner wrote: > On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann wrote: > > On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård wrote: > > > Linus Torvalds writes: > > > > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård wrote: > > > > We don't have any specific support for ECOFF. > > > > > > > > I _think_. Again, it's been years and years. I agree. I personally have never run any OSF/1 executables on Linux Alpha and have no interest in doing so. > > The main historic use case I've heard of was running Netscape > > Navigator on Alpha Linux, before there was an open source version. > > Doing this today to connect to the open internet is probably > > a bit pointless, but there may be other use cases. > > The best use case I know of is to run their C compiler. Måns sent > patches in fact to make it work. > > There is a Linux version of the same compiler but I have a vague > memory that it's broken in various ways that the Tru64 version is > not. The last time I tried the Compaq C compiler for Alpha-Linux it still worked, well, that is, the compiler worked, but the library header files are broken and haven't worked with glibc for a long time. So it is only useful as a free-standing compiler. In the past it also produced better code than gcc, but gcc is now so vastly improved w.r.t. optimisation and compliance to more recent standards, that I would be surprised if there is any real use for the Compaq compiler. Cheers, Michael.
Re: [PATCH] x86: Deprecate a.out support
Linus Torvalds writes: > On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann wrote: >> >> The main historic use case I've heard of was running Netscape >> Navigator on Alpha Linux, before there was an open source version. >> Doing this today to connect to the open internet is probably >> a bit pointless, but there may be other use cases. > > The _really_ main version was that I decided to make my life easier > for the initial alpha port by trying to run basic (tested) OSF/1 > binaries directly. > > Netscape may have been one of the binaries people actually ended up > using, but it's probably not a reason any more, since the internet has > moved past that anyway. > >> Looking at the system call table in the kernel >> (arch/alpha/kernel/syscalls/syscall.tbl), we seem to support a >> specific subset that was required for a set of applications, and >> not much more. > > Yeah, it never supported arbitrary binaries, particularly since > there's often lots of other issues too with running things like that > (ie filesystem layout etc). It worked for normal fairly well behaved > stuff, but wasn't ever a full OSF/1 emulation environment. > > I _suspect_ nobody actually runs any OSF/1 binaries any more, but it > would obviously be good to verify that. Your argument that timeval > handling was broken _may_ be an indication of that (or may just mean > very few apps care). Does it count if I fire up an Alpha and run a few OSF/1 binaries right now? :-) -- Måns Rullgård
Re: [PATCH] x86: Deprecate a.out support
On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann wrote: > > On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård wrote: > > Linus Torvalds writes: > > > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård wrote: > > >> > > >> The latest version I have is 5.1, and that uses ECOFF. > > > > > > ECOFF _is_ a.out as far as Linux is concerned. > > > > > > So Linux basically treats ECOFF as "regular a.out with just some > > > header extensions". > > > > > > We don't have any specific support for ECOFF. > > > > > > I _think_. Again, it's been years and years. > > > > Right, which is why killing a.out entirely would have the unfortunate > > effect of also removing the OSF/1 compatibility on Alpha. > > > > If we are to support Alpha as an architecture at all, it makes sense to > > support the things people actually use it for. > > > > Now, personally I can live without it. I just don't like to see > > features removed without due consideration. > > The main historic use case I've heard of was running Netscape > Navigator on Alpha Linux, before there was an open source version. > Doing this today to connect to the open internet is probably > a bit pointless, but there may be other use cases. The best use case I know of is to run their C compiler. Måns sent patches in fact to make it work. There is a Linux version of the same compiler but I have a vague memory that it's broken in various ways that the Tru64 version is not.
Re: [PATCH] x86: Deprecate a.out support
Arnd Bergmann writes:
> On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård wrote:
>> Linus Torvalds writes:
>> > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård wrote:
>> >>
>> >> The latest version I have is 5.1, and that uses ECOFF.
>> >
>> > ECOFF _is_ a.out as far as Linux is concerned.
>> >
>> > So Linux basically treats ECOFF as "regular a.out with just some
>> > header extensions".
>> >
>> > We don't have any specific support for ECOFF.
>> >
>> > I _think_. Again, it's been years and years.
>>
>> Right, which is why killing a.out entirely would have the unfortunate
>> effect of also removing the OSF/1 compatibility on Alpha.
>>
>> If we are to support Alpha as an architecture at all, it makes sense to
>> support the things people actually use it for.
>>
>> Now, personally I can live without it. I just don't like to see
>> features removed without due consideration.
>
> The main historic use case I've heard of was running Netscape
> Navigator on Alpha Linux, before there was an open source version.
> Doing this today to connect to the open internet is probably
> a bit pointless, but there may be other use cases.
Once upon a time, I used it to run Matlab.
> Looking at the system call table in the kernel
> (arch/alpha/kernel/syscalls/syscall.tbl), we seem to support a
> specific subset that was required for a set of applications, and
> not much more. Old system calls (osf_old_open, osf_execve,
> osf_old_sigaction) are listed but not implemented, and the same
> is true for most of the later calls (osf_fuser, osf_sigsendset,
> osf_waitid, osf_signal, ...), just the ones in the middle are there.
> This would also indicate that it never really worked as a
> general-purpose emulation layer but was only there for a specific
> set of applications.
It works for many applications, though I did have to add a few syscalls
myself (yes, I sent patches).
> Another data point I have is that osf1 emulation was broken
> between linux-4.13 and linux-4.16 without anyone noticing, see
> 47669fb6b595 ("alpha: osf_sys.c: fix put_tv32 regression").
That's interesting, but it doesn't mean nobody is using it. I tend to
run the LTS branches and switch to a new one only once it seems to have
settled a bit, so when 4.16 was released, I was probably still running
4.9. I don't think I'm the only one using this strategy.
--
Måns Rullgård
Re: [PATCH] x86: Deprecate a.out support
On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann wrote: > > The main historic use case I've heard of was running Netscape > Navigator on Alpha Linux, before there was an open source version. > Doing this today to connect to the open internet is probably > a bit pointless, but there may be other use cases. The _really_ main version was that I decided to make my life easier for the initial alpha port by trying to run basic (tested) OSF/1 binaries directly. Netscape may have been one of the binaries people actually ended up using, but it's probably not a reason any more, since the internet has moved past that anyway. > Looking at the system call table in the kernel > (arch/alpha/kernel/syscalls/syscall.tbl), we seem to support a > specific subset that was required for a set of applications, and > not much more. Yeah, it never supported arbitrary binaries, particularly since there's often lots of other issues too with running things like that (ie filesystem layout etc). It worked for normal fairly well behaved stuff, but wasn't ever a full OSF/1 emulation environment. I _suspect_ nobody actually runs any OSF/1 binaries any more, but it would obviously be good to verify that. Your argument that timeval handling was broken _may_ be an indication of that (or may just mean very few apps care). I think we should try the a.out removal and see if anybody notices. Linus
Re: [PATCH] x86: Deprecate a.out support
On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård wrote:
> Linus Torvalds writes:
> > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård wrote:
> >>
> >> The latest version I have is 5.1, and that uses ECOFF.
> >
> > ECOFF _is_ a.out as far as Linux is concerned.
> >
> > So Linux basically treats ECOFF as "regular a.out with just some
> > header extensions".
> >
> > We don't have any specific support for ECOFF.
> >
> > I _think_. Again, it's been years and years.
>
> Right, which is why killing a.out entirely would have the unfortunate
> effect of also removing the OSF/1 compatibility on Alpha.
>
> If we are to support Alpha as an architecture at all, it makes sense to
> support the things people actually use it for.
>
> Now, personally I can live without it. I just don't like to see
> features removed without due consideration.
The main historic use case I've heard of was running Netscape
Navigator on Alpha Linux, before there was an open source version.
Doing this today to connect to the open internet is probably
a bit pointless, but there may be other use cases.
Looking at the system call table in the kernel
(arch/alpha/kernel/syscalls/syscall.tbl), we seem to support a
specific subset that was required for a set of applications, and
not much more. Old system calls (osf_old_open, osf_execve,
osf_old_sigaction) are listed but not implemented, and the same
is true for most of the later calls (osf_fuser, osf_sigsendset,
osf_waitid, osf_signal, ...), just the ones in the middle are there.
This would also indicate that it never really worked as a
general-purpose emulation layer but was only there for a specific
set of applications.
Another data point I have is that osf1 emulation was broken
between linux-4.13 and linux-4.16 without anyone noticing, see
47669fb6b595 ("alpha: osf_sys.c: fix put_tv32 regression").
Arnd
Re: [PATCH] x86: Deprecate a.out support
On Mon, Mar 11, 2019 at 12:47 PM Måns Rullgård wrote: > > Linus Torvalds writes: > > > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård wrote: > >> > >> The latest version I have is 5.1, and that uses ECOFF. > > > > ECOFF _is_ a.out as far as Linux is concerned. > > > > So Linux basically treats ECOFF as "regular a.out with just some > > header extensions". > > > > We don't have any specific support for ECOFF. > > > > I _think_. Again, it's been years and years. > > Right, which is why killing a.out entirely would have the unfortunate > effect of also removing the OSF/1 compatibility on Alpha. > > If we are to support Alpha as an architecture at all, it makes sense to > support the things people actually use it for. I agree. I was not aware that a.out was effectively the same as ECOFF.
Re: [PATCH] x86: Deprecate a.out support
Linus Torvalds writes: > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård wrote: >> >> The latest version I have is 5.1, and that uses ECOFF. > > ECOFF _is_ a.out as far as Linux is concerned. > > So Linux basically treats ECOFF as "regular a.out with just some > header extensions". > > We don't have any specific support for ECOFF. > > I _think_. Again, it's been years and years. Right, which is why killing a.out entirely would have the unfortunate effect of also removing the OSF/1 compatibility on Alpha. If we are to support Alpha as an architecture at all, it makes sense to support the things people actually use it for. Now, personally I can live without it. I just don't like to see features removed without due consideration. -- Måns Rullgård
Re: [PATCH] x86: Deprecate a.out support
On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård wrote: > > The latest version I have is 5.1, and that uses ECOFF. ECOFF _is_ a.out as far as Linux is concerned. So Linux basically treats ECOFF as "regular a.out with just some header extensions". We don't have any specific support for ECOFF. I _think_. Again, it's been years and years. Linus
Re: [PATCH] x86: Deprecate a.out support
On Mon, Mar 11, 2019 at 9:26 AM Måns Rullgård wrote: > > Linus Torvalds writes: > > > On Sun, Mar 10, 2019 at 2:37 PM Matt Turner wrote: > >> > >> I'm not aware of a reason to keep a.out support on alpha. > > > > Hmm. I was looking at removing a.out support entirely, but it's > > actually fairly incestuous on alpha. > > > > For example, arch/alpha/boot/tools/objstrip.c very much has some a.out > > support in it. Maybe it can just be removed entirely. > > > > There's also an a.out.h include in arch/alpha/kernel/binfmt_loader.c. > > > > Finally, note that CONFIG_OSF4_COMPAT also no longer makes sense > > without a.out support. > > Anyone running an Alpha machine likely also has some old OSF/1 binaries > they may wish to use. It would be a shame to remove this feature, IMO. Tru64 5.1 uses ECOFF binaries, I believe. Do you know when OSF/1 / Digital UNIX / Tru64 switched from a.out to ECOFF?
Re: [PATCH] x86: Deprecate a.out support
Linus Torvalds writes: > On Mon, Mar 11, 2019 at 9:26 AM Måns Rullgård wrote: >> >> Anyone running an Alpha machine likely also has some old OSF/1 binaries >> they may wish to use. It would be a shame to remove this feature, IMO. > > If that's the case then we'd have to keep a.out alive for alpha, since > that's the OSF/1 binary format (at least the only one we support - I'm > not sure if later versions of OSF/1 ended up getting ELF). The latest version I have is 5.1, and that uses ECOFF. > Which I guess we could do, but the question is whether people really > do have OSF/1 binaries. It was really useful early on as a source of > known-good binaries to test with, but I'm not convinced it's still in > use. > > It's not like there were OSF/1 binaries that we didn't havce access to > natively (well, there _were_ special ones that didn't have open source > versions, but most of them required more system-side support than > Linux ever implemented, afaik). I don't have any specific examples, but I can well imagine people keeping an Alpha machine for no other reason than the ability to run some (old) application only available (to them) for OSF/1. Running them on Linux rather than Tru64 brings the advantage of being a modern system in other regards. For anything open source, there's little reason to keep the Alpha at all. -- Måns Rullgård
Re: [PATCH] x86: Deprecate a.out support
On Mon, Mar 11, 2019 at 9:26 AM Måns Rullgård wrote: > > Anyone running an Alpha machine likely also has some old OSF/1 binaries > they may wish to use. It would be a shame to remove this feature, IMO. If that's the case then we'd have to keep a.out alive for alpha, since that's the OSF/1 binary format (at least the only one we support - I'm not sure if later versions of OSF/1 ended up getting ELF). Which I guess we could do, but the question is whether people really do have OSF/1 binaries. It was really useful early on as a source of known-good binaries to test with, but I'm not convinced it's still in use. It's not like there were OSF/1 binaries that we didn't havce access to natively (well, there _were_ special ones that didn't have open source versions, but most of them required more system-side support than Linux ever implemented, afaik). Linus
Re: [PATCH] x86: Deprecate a.out support
Linus Torvalds writes: > On Sun, Mar 10, 2019 at 2:37 PM Matt Turner wrote: >> >> I'm not aware of a reason to keep a.out support on alpha. > > Hmm. I was looking at removing a.out support entirely, but it's > actually fairly incestuous on alpha. > > For example, arch/alpha/boot/tools/objstrip.c very much has some a.out > support in it. Maybe it can just be removed entirely. > > There's also an a.out.h include in arch/alpha/kernel/binfmt_loader.c. > > Finally, note that CONFIG_OSF4_COMPAT also no longer makes sense > without a.out support. Anyone running an Alpha machine likely also has some old OSF/1 binaries they may wish to use. It would be a shame to remove this feature, IMO. -- Måns Rullgård
Re: [PATCH] x86: Deprecate a.out support
On Sun, Mar 10, 2019 at 11:46 PM Linus Torvalds wrote: > > On Sun, Mar 10, 2019 at 2:37 PM Matt Turner wrote: > > > > I'm not aware of a reason to keep a.out support on alpha. > > Hmm. I was looking at removing a.out support entirely, but it's > actually fairly incestuous on alpha. > > For example, arch/alpha/boot/tools/objstrip.c very much has some a.out > support in it. Maybe it can just be removed entirely. > > There's also an a.out.h include in arch/alpha/kernel/binfmt_loader.c. > > Finally, note that CONFIG_OSF4_COMPAT also no longer makes sense > without a.out support. > > So this attached patch does not compile on alpha, but it's been many > many years since I had an alpha to test with, so I'm stuck. > > Matt, can you fill in the details and complete this patch? I wonder if we could remove the osf time32 compat code as well, this was one of the areas that kept causing problems with the y2038 rework. (I think it's all good now, but it's never been tested as far as I can tell). For some syscalls (e.g. brk, mmap, getxuid, ...) we definitely need to keep the osf1 version, since it is the only supported ABI. I just looked up some really old source trees and found that glibc-2.1 was the first release to use 64-bit time_t the way we do it today, as implemented in [1], so all Debian and SuSE releases for alpha had it, but any ELF binaries built on Red Hat Linux 4.x and 5.x (released 1996 through 1998) or earlier would use 32-bit time_t osf1 syscalls. Red Hat 2.x and 3.x were a.out based on alpha. Arnd [1] https://repo.or.cz/glibc/history.git/commitdiff/64819b5c3a94e81e4
Re: [PATCH] x86: Deprecate a.out support
Hi Linus! On 3/11/19 7:40 AM, Linus Torvalds wrote: > So this attached patch does not compile on alpha, but it's been many > many years since I had an alpha to test with, so I'm stuck. Michael Cree (CC'ed) has several Alpha servers running which are also used for building Debian packages and testing kernels. I also have four AlphaStations (233, 433au and XP-1000) on which I could test any patch. But I'm currently in Japan until Friday next week, so I don't have any means to access the machines. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] x86: Deprecate a.out support
On Sun, Mar 10, 2019 at 03:40:20PM -0700, Linus Torvalds wrote:
> SYSCALL_DEFINE3(osf_readv, unsigned long, fd,
> const struct iovec __user *, vector, unsigned long, count)
> {
> -#ifdef CONFIG_OSF4_COMPAT
> - if (unlikely(personality(current->personality) == PER_OSF4))
> - if (osf_fix_iov_len(vector, count))
> - return -EFAULT;
> -#endif
> -
> return sys_readv(fd, vector, count);
> }
>
> SYSCALL_DEFINE3(osf_writev, unsigned long, fd,
> const struct iovec __user *, vector, unsigned long, count)
> {
> -#ifdef CONFIG_OSF4_COMPAT
> - if (unlikely(personality(current->personality) == PER_OSF4))
> - if (osf_fix_iov_len(vector, count))
> - return -EFAULT;
> -#endif
> return sys_writev(fd, vector, count);
> }
Might as well kill those two off, while we are at it - just use
sys_readv/sys_writev
in arch/alpha/kernel/syscalls/syscall.tbl and be done with that...
Re: [PATCH] x86: Deprecate a.out support
On Sun, Mar 10, 2019 at 2:37 PM Matt Turner wrote:
>
> I'm not aware of a reason to keep a.out support on alpha.
Hmm. I was looking at removing a.out support entirely, but it's
actually fairly incestuous on alpha.
For example, arch/alpha/boot/tools/objstrip.c very much has some a.out
support in it. Maybe it can just be removed entirely.
There's also an a.out.h include in arch/alpha/kernel/binfmt_loader.c.
Finally, note that CONFIG_OSF4_COMPAT also no longer makes sense
without a.out support.
So this attached patch does not compile on alpha, but it's been many
many years since I had an alpha to test with, so I'm stuck.
Matt, can you fill in the details and complete this patch?
Linus
arch/alpha/Kconfig | 1 -
arch/alpha/kernel/osf_sys.c | 30
arch/m68k/Kconfig | 1 -
arch/x86/Kconfig| 7 -
arch/x86/ia32/Makefile | 2 -
arch/x86/ia32/ia32_aout.c | 330 --
fs/Kconfig.binfmt | 33 -
fs/Makefile | 1 -
fs/binfmt_aout.c| 343
include/linux/a.out.h | 18 ---
10 files changed, 766 deletions(-)
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 584a6e114853..9b9770b45f36 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -10,7 +10,6 @@ config ALPHA
select FORCE_PCI if !ALPHA_JENSEN
select PCI_DOMAINS if PCI
select PCI_SYSCALL if PCI
- select HAVE_AOUT
select HAVE_IDE
select HAVE_OPROFILE
select HAVE_PCSPKR_PLATFORM
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index bf497b8b0ec6..09a0746c9681 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1342,45 +1342,15 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
return addr;
}
-#ifdef CONFIG_OSF4_COMPAT
-/* Clear top 32 bits of iov_len in the user's buffer for
- compatibility with old versions of OSF/1 where iov_len
- was defined as int. */
-static int
-osf_fix_iov_len(const struct iovec __user *iov, unsigned long count)
-{
- unsigned long i;
-
- for (i = 0 ; i < count ; i++) {
- int __user *iov_len_high = (int __user *)[i].iov_len + 1;
-
- if (put_user(0, iov_len_high))
- return -EFAULT;
- }
- return 0;
-}
-#endif
-
SYSCALL_DEFINE3(osf_readv, unsigned long, fd,
const struct iovec __user *, vector, unsigned long, count)
{
-#ifdef CONFIG_OSF4_COMPAT
- if (unlikely(personality(current->personality) == PER_OSF4))
- if (osf_fix_iov_len(vector, count))
- return -EFAULT;
-#endif
-
return sys_readv(fd, vector, count);
}
SYSCALL_DEFINE3(osf_writev, unsigned long, fd,
const struct iovec __user *, vector, unsigned long, count)
{
-#ifdef CONFIG_OSF4_COMPAT
- if (unlikely(personality(current->personality) == PER_OSF4))
- if (osf_fix_iov_len(vector, count))
- return -EFAULT;
-#endif
return sys_writev(fd, vector, count);
}
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index b54206408f91..65d263c60669 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -8,7 +8,6 @@ config M68K
select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select ARCH_NO_PREEMPT if !COLDFIRE
select HAVE_IDE
- select HAVE_AOUT if MMU
select HAVE_DEBUG_BUGVERBOSE
select GENERIC_IRQ_SHOW
select GENERIC_ATOMIC64
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c1f9b3cf437c..4a9438e4fba6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2836,13 +2836,6 @@ config IA32_EMULATION
64-bit kernel. You should likely turn this on, unless you're
100% sure that you don't have any 32-bit programs left.
-config IA32_AOUT
- tristate "IA32 a.out support"
- depends on IA32_EMULATION
- depends on BROKEN
- ---help---
- Support old a.out binaries in the 32bit emulation.
-
config X86_X32
bool "x32 ABI for 64-bit mode"
depends on X86_64
diff --git a/arch/x86/ia32/Makefile b/arch/x86/ia32/Makefile
index cd4339bae066..b98fedaa7642 100644
--- a/arch/x86/ia32/Makefile
+++ b/arch/x86/ia32/Makefile
@@ -4,7 +4,5 @@
obj-$(CONFIG_IA32_EMULATION) := sys_ia32.o ia32_signal.o
-obj-$(CONFIG_IA32_AOUT) += ia32_aout.o
-
audit-class-$(CONFIG_AUDIT) := audit.o
obj-$(CONFIG_IA32_EMULATION) += $(audit-class-y)
diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
deleted file mode 100644
index 3c135084e1eb..
--- a/arch/x86/ia32/ia32_aout.c
+++ /dev/null
@@ -1,330 +0,0 @@
-/*
- * a.out loader for x86-64
- *
- * Copyright (C) 1991, 1992, 1996 Linus Torvalds
- * Hacked together by Andi Kleen
- */
-
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-
-#undef WARN_OLD
-
-static int load_aout_binary(struct linux_binprm *);
-static int load_aout_library(struct file *);
-
-static struct linux_binfmt
Re: [PATCH] x86: Deprecate a.out support
On Tue, Mar 5, 2019 at 11:04 AM Borislav Petkov wrote: > > On Tue, Mar 05, 2019 at 07:11:38PM +0100, Borislav Petkov wrote: > > I guess you could Cc arch maintainers with the a.out-core.h removal > > patch to see if anyone screams. > > And they're like two for which we need confirmation: > > $ git ls-files | grep a.out-core.h > arch/alpha/include/asm/a.out-core.h > arch/m68k/include/asm/a.out-core.h > arch/um/include/asm/a.out-core.h > arch/x86/include/asm/a.out-core.h > > um and x86 are clear. > > Adding alpha and m68k MLs to Cc. I'm not aware of a reason to keep a.out support on alpha.
Re: [PATCH] x86: Deprecate a.out support
Hi Borislav,
On Tue, Mar 5, 2019 at 8:04 PM Borislav Petkov wrote:
> On Tue, Mar 05, 2019 at 07:11:38PM +0100, Borislav Petkov wrote:
> > I guess you could Cc arch maintainers with the a.out-core.h removal
> > patch to see if anyone screams.
>
> And they're like two for which we need confirmation:
>
> $ git ls-files | grep a.out-core.h
> arch/alpha/include/asm/a.out-core.h
> arch/m68k/include/asm/a.out-core.h
> arch/um/include/asm/a.out-core.h
> arch/x86/include/asm/a.out-core.h
>
> um and x86 are clear.
>
> Adding alpha and m68k MLs to Cc.
Thanks!
The oldest binaries I still have lying around (an ext2 ramdisk image,
still used from time to time) are ELF, from just after the a.out to ELF
transition on m68k.
I think it's safe to assume no one still runs a.out binaries on m68k.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] x86: Deprecate a.out support
On Tue, Mar 05, 2019 at 07:11:38PM +0100, Borislav Petkov wrote: > I guess you could Cc arch maintainers with the a.out-core.h removal > patch to see if anyone screams. And they're like two for which we need confirmation: $ git ls-files | grep a.out-core.h arch/alpha/include/asm/a.out-core.h arch/m68k/include/asm/a.out-core.h arch/um/include/asm/a.out-core.h arch/x86/include/asm/a.out-core.h um and x86 are clear. Adding alpha and m68k MLs to Cc. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
