> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
