[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1784.1194478233@redhat.com>
Date: Wed, 07 Nov 2007 23:30:33 +0000
From: David Howells <dhowells@...hat.com>
To: David Woodhouse <dwmw2@...radead.org>
Cc: dhowells@...hat.com, torvalds@...l.org, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, linux-am33-list@...hat.com
Subject: Re: [PATCH 1/2] Suppress A.OUT library support in ELF binfmt if !CONFIG_BINFMT_AOUT [try #3]
David Woodhouse <dwmw2@...radead.org> wrote:
> Ew, no. This is horridly broken. You should never use CONFIG_xxx_MODULE
> in the static kernel at all -- and you should _especially_ not be using
> it in header files which are exported to userspace.
AOUT support can be mostly built into a module, but a small part of it that is
arch-specific still gets built into the main kernel. *That* is the main thing
that is wrong.
I suppose it might be possible to move those bits of the main kernel into
inline functions in asm/a.out.h and thus include them directly in
binfmt_aout.ko.
> This abomination certainly doesn't seem to have any direct relation to
> mn10300 support -- I think all you really need there is not to attempt
> to export {asm,linux}/a.out.h if asm/a.out.h doesn't exist, which is
> something you haven't attempted here anyway.
No, it's not that simple. If asm/a.out.h doesn't exist, then various bits of
the kernel break that shouldn't. fs/binfmt_elf.c for example. fs/exec.c for
another. They *expect* bits of the asm/a.out.h and linux/a.out.h to exist -
which they shouldn't.
Not exporting them isn't by itself sufficient. The required constants
themselves are not defined for an arch that doesn't have the support, and so
the core code must not depend on them. This patch fixes that.
Furthermore, STACK_TOP and STACK_TOP_MAX don't belong in asm/a.out.h as far as
I can tell. They should probably be wherever TASK_SIZE resides (ie:
asm/processor.h).
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists