A Way Out for A.out
lwn.net
lwn.net
The project lead (Linus) pushed back first with reasonable-looking point, but it is hit back by a thorough research. And finally a clever workaround broke it through.
It was very energizing to me who has habit to rely on non-engineering tools to push through these kind of discussions.
Or what I run into “Is this used …. and does it even ‘work’?!?!”
[1] https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
“Beware of the bull”
"Chesterton's Permalinked Fence" is generally straightforward to reason about.
Another system watched the version control system for who added that line of logging, and sent them status emails. After the moribund logging had been in production for two weeks, the emails turned into nag emails to either remove the code, or at least remove the moribund logging if you decided against removing the code.
For several years I didn't get any distribution updates but installed new versions of packages from source instead. It was fighting GNOME updates that finally made me throw in the towel.
> FreeBSD comes from the ``classic'' camp and used the a.out(5) format, a technology tried and proven through many generations of BSD releases, until the beginning of the 3.X branch. Though it was possible to build and run native ELF binaries (and kernels) on a FreeBSD system for some time before that, FreeBSD initially resisted the ``push'' to switch to ELF as the default format.
[...]
> So ELF had to wait until it was more painful to remain with a.out than it was to migrate to ELF.
> However, as time passed, the build tools that FreeBSD derived their build tools from (the assembler and loader especially) evolved in two parallel trees. The FreeBSD tree added shared libraries and fixed some bugs. The GNU folks that originally write these programs rewrote them and added simpler support for building cross compilers, plugging in different formats at will, and so on. Since many people wanted to build cross compilers targeting FreeBSD, they were out of luck since the older sources that FreeBSD had for as and ld were not up to the task. The new GNU tools chain (binutils) does support cross compiling, ELF, shared libraries, C++ extensions, etc. In addition, many vendors are releasing ELF binaries, and it is a good thing for FreeBSD to run them.
> ELF is more expressive than a.out and allows more extensibility in the base system. The ELF tools are better maintained, and offer cross compilation support, which is important to many people. ELF may be a little slower than a.out, but trying to measure it can be difficult. There are also numerous details that are different between the two in how they map pages, handle init code, etc. None of these are very important, but they are differences. In time support for a.out will be moved out of the GENERIC kernel, and eventually removed from the kernel once the need to run legacy a.out programs is past.
It looks like default support of a.out was removed in 5.0 (January 2003), but you can still load a kernel module (shipped with the generic kernel) or compile a custom kernel with support built in. At least on i386/amd64.
[1] https://docs.freebsd.org/doc/4.9-RELEASE/usr/share/doc/handb...
“a.out” is barely a format: just a block of executable, a block of data initialization and an integer to say how large the (uninitialized) heap should be. Later some symbols and a bit of debugging info was added. But remember back then a lot of stuff was still written in assembler and machines were not that powerful, so something simple was not only sufficient but better.
Separating code and data wasn’t even really needed but back then it wasn’t clear that (almost) every machine would be a von Neumann architecture. There were still plenty of Harvard architecture machines (split I/ D) space. Of course these days we’ve partially circled back with write protected executable blocks and execute permission forbidden to data and stack.
When I started designing bfd in 89 or 90 I started with a.out. There were already other formats (predominantly forms of COFF) because the limitations of a.out had started to be a problem.
There are still new harvard architecture microcontrollers being designed. It provides some security in the field as well as simplifying the chip layout.
There's a second insight on the tip of my tongue, here: Harvard architectures can emulate Von Neumann ones, and vice versa. And problems, specific problems, can be solved by either. But it seems to me that there's something interesting about emulation too - That Harvard architectures can open themselves up to precisely the same vectors of attacks if you enable "Copy this data block to code memory".
This approach was pretty common in the 80s Lisp days IIRC.
It would be possible to compile everything to machine code ahead of time (pretty much what GraalVM does), but that would compile everything even if it would never end up being executed*. Without JIT compiler, it would not be possible to recompile code to take advantage of tracing information gathered at runtime. Also, newly loaded Java code would not be able to be optimized at all.
There are workarounds for all of these. For example, the JIT compiler could generate a new executable with the optimized code and migrate execution state to a new process. But it seems very clunky.
*: Not really an issue with microservices and stripped-down binaries. A huge deal for IDEs and environments with plugin architecture though.
Some Harvard architecture implementations provide ways of shoving data into executable space and back (like special copy instructions) but it's not general purpose. Generally you compile on Von Neumann and flash to Harvard.
> "a.out" remains the default output file name for executables created by certain compilers and linkers when no output name is specified, even though the created files actually are not in the a.out format.
1. ELF is OK, but times have changed since ELF was created. The same constraints no longer exist. Personally, I prefer static binaries and can afford the space for them. It is good to have options for people who prefer shared libraries as well as those who prefer static binaries.
I find it surprising that the Kernel doesn't have a formal and easy way to know who is using what for the purpose of dropping support except to go fishing for complaints and hoping by chance nobody bites.
There should be something like a list of legacy features on kernel.org where people can easily subscribe to a mailing list which will ask for them to know if they still need the feature when there are plans to phase it out. A phase-out list so to speak.
Microsoft hasn't solved it, Windows is drowning in its own moat.
Unless you want at least every developer and system administrator in the world to subscribe to that mailing list and regularly read it, I don’t know how this can really solve the problem.
Add to that the fact that the classification of a “feature” is rather fuzzy…
There are already announcements and discussions through various channels, but at the end you can never be sure. Fortunately systems don’t have to always be updated immediately (aside from for security concerns).
1) Some old feature, like an obscure filesystem, is causing some pain to maintain.
2) Therefore people suggest to add it to the phase-out list.
3) After some discussion it is decided it is a worthy candidate for removal and so it is placed on the phase-out list.
4) Some people starts subscribing, but not too much. Turns out it's some obscure distribution for an Atari emulator.
5) Time pass and years later these people have moved on to better things, they reply to the reminder email saying it's fine now.
6) Feature gets removed safely.
Quickly sent a mail to LWN and got their authorization in the next 10 minutes.
Big up to the team and awesome content! This motivated me to buy a subscription to support them.
[0] - https://linuxfr.org/users/linkdd/journaux/lwn-une-porte-de-sortie-pour-a-out-63380a9d-20e0-44de-979d-74afcb6f3910Just to pick one thing, their kernel index has been so useful when I run into an area of the kernel I need to learn about: https://lwn.net/Kernel/Index/
This seems really weird as an a.out removal opposition. If you're already using ancient tools to compile programs for ancient hardware, why do you need the latest kernel for it? Why not keep a VM with a system dedicated for that task which you'll never need to update or change in any way?
There's likely a single digit number of people who actually have that use case, right?
The issue is keeping the code in tree. Its inclusion doesn’t affect the quality of the kernel, its just a maintenance burden.
I'm generally of the mindset to keep something until there's reason to remove it.
When I got Slackware 2.0 as my first Linux distribution, the CD-ROM box had a sticker asserting "now with ELF support!" kind of statement.
I had a good laugh thanks again :)
> "a.out" remains the default output file name for executables created by certain compilers and linkers when no output name is specified, even though the created files actually are not in the a.out format.