Re: binfmt_aout.c

Andries.Brouwer@cwi.nl
Sat, 23 Oct 1999 15:33:13 +0200 (MET DST)


From andrea@suse.de Sat Oct 23 03:30:34 1999

The binfmt_aout patch I sent to Alan was a one liner (see l-k) for an
obvious bug and it had nothing to do with the binfmt_aout stuff that is
been merged into 2.2.13.

The patch I produced starting from the 2.3.x code - and that is been
merged in 2.2.13 - instead has a very good object that is to allow the old
binaries to run even on filesystems with a blocksize > 1k.

Yes.
I sent my patch mainly so that you could see what was wrong in 2.2.13
and make sure that similar bugs in 2.3.*, if any, were fixed.
The main bug in 2.2.13, failure to allocate bss for libraries,
does not occur in 2.3.*: I see
do_mmap(..., ex.a_text + ex.a_data + ex.a_bss, ...)
in do_load_aout_library().
And indeed, I can run 2.3.21 without getting segfaults.

>Discussion:
>1. Warnings: I hate getting a printk every 5 seconds.
> Getting three warnings at boot time to remind me of
> the fact (which I am well aware of) that there still
> are many old ZMAGIC binaries, is amply sufficient.

I backported the messages from 2.3.x and I think the point of the messages
is exactly to remind to to the binary only people to produced ELF
binaries.

Yes, but please, change things from
if (jiffies - lasttime > HZ/100) {
printk("You are using ancient stuff, you fool!\n");
lasttime = jiffies;
}
into
static int count=0;
if (count++ < 3)
printk("You still have a genuine ZMAGIC binary!\n");

Really - it is stupid to get warnings all the time.
One has to go in and edit the kernel source just to avoid them.
A few at boot time is enough. It is not an error to use old stuff,
and in some cases it is unavoidable. Part of a stable system is
that it doesnt break old stuff, at least not without very good reason.

Andries

[And apart from the above reasons, somehow it violates my
sense of esthetics to see jiffies used in such a context.
Running a binary has nothing to do with the time-of-day.
There should be no reference to jiffies in binfmt_aout.c.]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/