> Nice, we should have unified the compat ptrace code long ago.
There is still more consolidation that can be done, but this is a first step.
> Any chance you could make the ifdef symetric to the native ptrace
> where an arch defines a symbol if it has it's own ptrace?
That would require touching each and every arch's headers so as
not to break it with the generic changes. I seem to get berated
for that sort of thing more often than asked for it.
> Also when prototyping something like this I was wondering whether we
> really want a separate compat function. Lots of the ptrace requests
> mostly depend on the target processes abi, not the ptrace caller, [...]
That's not really true of any ptrace request that isn't already
wholly arch-dependent, and not true of any majority of those either.
For all of the things that are likely to be handled in generic code
any time soon, it's the caller of ptrace whose natural data formats
reign.
> [...] Anyway, that's probably something to worry about
> later one the arch-specific compat ptrace implementations are gone.
Indeed.
Thanks,
Roland
--
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]
