Messages in this thread | | | Date | Tue, 9 Feb 2010 18:03:33 -0800 | Subject | Re: [patch v2 4/4] ptrace: Add support for generic PTRACE_GETREGSET/PTRACE_SETREGSET | From | "H.J. Lu" <> |
| |
On Tue, Feb 9, 2010 at 5:52 PM, Roland McGrath <roland@redhat.com> wrote: >> 'addr' parameter for the ptrace system call encode the REGSET type and >> the buffer length. 'data' parameter points to the user buffer. >> >> ptrace(PTRACE_GETREGSET/PTRACE_SETREGSET, pid, >> (NT_TYPE << 20) | buf_length, buf); > > IMHO this bit swizzling is a non-starter. The NT_* codes can use a full 32 > bits. NT_PRXFPREG uses 31 bits. The comments about ignoring the high bits > for this as a special case just seem insane to me. Pass a full 32 bit word > for NT_* and a full word for the buffer size. What's so terrible about > just having an obvious and comprehensible API? > > IMHO if you insist on an insane bit swizzling approach, you should mix the > buffer size bits into the request code, leaving the "addr" argument free > for the unmolested NT_* code. There is just no earthly reason that we > should suddenly impose a new and arcane constraint on what NT_* values can > be, even if there is no particular reason for future values not to be small. > >> +int generic_ptrace_regset(struct task_struct *child, long request, long addr, >> + long data); > > There is no need for a global function for this. It should all be static > in kernel/ptrace.c, called only by ptrace_request()/compat_ptrace_request(). >
Won't it be called by ptrace emulation in utrace?
-- H.J. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |