From: "Parag Warudkar" <parag.warudkar@gmail.com>
To: "Andi Kleen" <ak@suse.de>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
joerg@hydrops.han.de, dsd@gentoo.org, paulus@samba.org,
benh@kernel.crashing.org, lethal@linux-sh.org
Subject: Re: [PATCH] Make aout executables work again
Date: Sat, 10 Feb 2007 09:41:34 -0500 [thread overview]
Message-ID: <82e4877d0702100641h7b479c95mce3dfa65b0e6c779@mail.gmail.com> (raw)
In-Reply-To: <200702101524.56098.ak@suse.de>
> > Is there a reason why we specifically want to make a distinction
> > between binfmts having and not having VDSOs and do we want aout to
> > have the possibility of NOT having VDSO when a) It used to have it
> > unconditionally b) nothing special is needed in arch or common code to
> > have it and c) Not letting have it requires special arch-specific
> > code* ?
>
> I mainly did it this way because it was quite a lot simpler.
> I'm not worrying too much about other strange binfmts to be honest
>
Well with your suggestion of using weak definition (BTW, I find that
thing cool :)) for arch_setup_additional_pages() I think my patch is
simpler and it preserves existing behavior - it just boils down to
actually calling the already existing function in binfmt_aout.c.
> > [*] I see the patch handles i386 and x86_64 - but I am not sure if
> > something similar will be needed for the other arches to allow aout
> > executables in absence of VDSO (powerpc, sh).
>
> Neither powerpc nor sh support a.out.
>
Ok, that's not a concern then. Not that I care about aout but if a
simple fix can let it have VDSO and prevent special casing, I would
prefer to let it have VDSO and still work - at least in the interest
of preserving existing behavior.
Parag
next prev parent reply other threads:[~2007-02-10 14:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-10 2:31 Parag Warudkar
2007-02-10 12:58 ` Andi Kleen
2007-02-10 13:50 ` Parag Warudkar
2007-02-10 14:24 ` Andi Kleen
2007-02-10 14:41 ` Parag Warudkar [this message]
2007-02-10 15:12 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=82e4877d0702100641h7b479c95mce3dfa65b0e6c779@mail.gmail.com \
--to=parag.warudkar@gmail.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=dsd@gentoo.org \
--cc=joerg@hydrops.han.de \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®