Re: i386 memory corrupted by free_initmem()

Linus Torvalds (torvalds@transmeta.com)
Fri, 16 May 1997 18:50:03 -0700 (PDT)


On Sat, 17 May 1997 Andries.Brouwer@cwi.nl wrote:
>
> Note that I'll probably use the "ALIGN(4096)" thing for other things too
> in the near future (getting rid of some of the data stuff in "head.S"),
>
> Well, if it is an important use, then probably you should find out
> what version of ld is required, and let the Makefile test that ld
> is sufficiently recent, like it already does for gcc.
> On the other hand, if the only use is to save a few kB, then I hope
> you will also consider the importance of stability.

It's not actually going to save space, it's more for saving my sanity.
Right now the kernel has various things that require page-alignment for
one reason or another, and the old way was to have them all in head.S
because that was the only way to guarantee the alignment we wanted.

With the new linker features (well, they aren't all that new any more, but
they are only now being used to heir full advantage) we can let the linker
give us the alignment we require, and have a special aligned segment.

One of the main advantages of this is that much that had to be in assembly
can now be moved into a C file instead. I did some of this with some
trickery (look at how "init_task.c" is built up), but that had some other
misfortunate results (mainly that "init_task" is now in the code segment,
which makes it show up on stack traces as a function in panics ;)

The fact that all tasks are now 8kB aligned (yes, that really is 8kb, not
4kB) on x86 allows us to do some strange and wonderful things.

> Stability not only means that the kernel doesn't crash - it also
> means that one doesn't need to upgrade software every few months,
> and that a Linux system is loosely coupled, in the sense that
> all subsystems tolerate great variation in the version of other
> subsystems.

You're right. My main objective has to be to strive to maintain old
binaries for _running_ stuff - which is why a.out still works, and why you
can have binaries from 1992 still working.

However, when it comes to the kernel development environment, I tend to
prefer to use features that make it easier for me to develop (or makes it
possible to do new and clever things - the switch to ELF format for the
kernel really allowed us to do some _really_ good things by using linkage
segments to). So as a kernel developer I don't want to be tied down to
older tools - even though I expect the new kernel to be able to _run_
those older tools.

I certainly try to avoid requiring tools updates for frivolous reasons,
and I heartily agree on making clear which tools are bad and which aren't.
I'm currently using

gcc version 2.7.2.1.f.1
ld version 2.7 (with BFD 2.7.0.2)

in case people are wondering.

Linus