On 16.02.2010, at 01:52, Rob Landley wrote: > On Monday 15 February 2010 07:08:33 Michael S. Tsirkin wrote: >> On Mon, Feb 15, 2010 at 06:58:33AM -0600, Rob Landley wrote: >>> On Monday 15 February 2010 05:19:24 Alexander Graf wrote: >>>> On 15.02.2010, at 12:10, Rob Landley wrote: >>>>> On Sunday 14 February 2010 08:41:00 Alexander Graf wrote: >>>>>> So the only case I can imagine that this breaks anything is that >>>>>> uClibc requires register state to be 0. >>>>> >>>>> Yes, r3 (which is the exit code from the "exec" syscall, and thus 0 >>>>> if it worked). In the BSD layout, it's argc (which can never be 0). >>>>> >>>>> http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00720.html >>>> >>>> So what you really want is something like >>>> >>>> #ifdef CONFIG_LINUX_USER >>>> /* exec return value is always 0 */ >>>> env->gpr[3] = 0; >>>> #endif >>>> >>>> just after the #endif in your patch. If you had inlined your patch I >>>> could've commented it there. >>> >>> Unfortunately kmail plays fast and loose with whitespace when I inline >>> stuff. (Not always, but I can't tell by inspection when it's decided it >>> was hungry for tabs or wanted to throw in that horrible UTF8 escaped >>> whitespace.) >> >> See Documentation/email-clients.txt under linux source tree. > > I did. That doesn't cover the different bugs in different versions, what > happens when you use kmail under xfce, and so on. (It also doesn't mention > that you have to disable wordwrap for the entire message and hit return by > hand at the end of each line to get kmail not to wrap inline includes. Or > that some versions of kmail embed NUL bytes into inline includes, for some > reason.) > > I could make it work, just didn't know this list had a tropism for inline. > (Varies per list and I wander through a bunch of 'em.) Over on the -hda sets > /dev/hdc topic I posted a patch inline which was ignored because the behavior > the Linux kernel has consistently had for the past decade or more isn't > considered especially important. Thus I didn't think you were likely > following lkml tropes.
If swapping the parameter was the right solution I would've submitted a patch long ago :-). Unfortunately it's not as easy. But the inlining is really only about simple commenting. It's a lot nicer to have context when you say "this doesn't make sense" or so :-). Either way - it's good to see someone interested in the topic actually sending patches. Reviewing and commenting doesn't mean I don't like what you're doing. In this case it just means I'm pretty sure it doesn't solve the problem, but only the symptoms. Alex
