mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®