On Wed, Jan 18, 2012 at 1:21 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > Roland, could you refresh my memory what your objection to this was? Sorry, I don't really recall. I could dig through old email archives, but they'd be archives of messages I sent to you, so you should have them too. The only principle in this area I recall having an opinion about is that we should not mix up things that are bona fide user-visible state with things that aren't. (By "user-visible" I mean things that the task in question can see or affect by just doing normal instructions, as opposed to things only controlled via ptrace, such as the debug registers.) But that principle is not really being violated here. I recall that you and I discussed making the path-of-entry visible somehow and I was in favor of doing that. As I recall it, we just never bothered to follow through. There are all the concerns about obscure ABI compatibility with expectations of existing debuggers and so forth, which Linus has mentioned. For that I can accept his point that things today so mishandle the int80-from-64 case that something like a new meaning for high bits of orig_ax or whatnot in just that case would not be actually problematic. When you and I were discussing a more general feature of distinguishing int80 from sysenter from syscall from traps from asynchronous interrupts, that was of more concern. I do feel strongly that any new means of exposing bona fide user state ought to be done via the user_regset mechanism. (i.e., either overloading some existing user_regs_struct bits if that truly is harmless to compatibility, or adding a new regset flavor.) That way it is automatically recorded in core files, accessible with PTRACE_GETREGSET, etc. (But I'm not really working on this stuff any more, so I'm out of the business of arguing strenuously about such opinions.) Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
