On Sun, Sep 04, 2005 at 05:02:18PM +0200, Blaisorblade wrote:
> Now, the point is: should I ask Linus to drop it for now, clean the
> interface, and resend the cleaned up one, with different ptrace call codes?
I would be tempted to leave it in and fix it before 2.6.14. We need different
ptrace codes so that UML knows how to switch interception types, I take it?
UML is the only user, so there aren't really any compatibility issues.
> On the host side, instead, supporting both the broken API and the new one is
> more difficult.
Yeah, and it shouldn't be done. This is one reason I'd like to use the same
ptrace codes - it doesn't leave a hole in the codes that says there was a
broken ABI there once.
> What's your opinion on this? The options are:
> 1) merge it as-is
> 2) take it back for now, fix it and merge it for 2.6.15.
Merge as-is, fix it before 2.6.13, and you get the same thing, except
a release earlier. I think this shouldn't be a problem, as after the
floodgates close, you still get to fix things you merged early. This
came about as a result of feedback received because after it went into
-mm, and it seems to me that this is a legitimate change for 2.6.14.
> And then
>
> 2a) drop the trick, and avoid changing ptrace call numbers. Old UMLs
> will run fast, but crash with /proc/sysemu (only root-accessible).
We should drop /proc/sysemu, if it's there at all, since it's only for
debugging sysemu, and maintain it as a private patch. So this doesn't
seem like much of an issue.
Jeff
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
