More obvious than that, if I've never looked at it before ;-)
> Dave
> They're trying to access the variables that have been pushed onto the
> top of the stack. The thread_info field points to the bottom of the
> kernel's stack (no matter how big it is). I don't know where the -5 and
> -2 come from. It needs a big, fat stinking comment.
OK, so maybe I'm still asleep, but I don't see why the hardcoded
magic constant (grrr) is 4096 in mainline, when the stacksize is 8K.
Presumably the 1019*4 makes up the rest of it? Maybe the real question
is what the hell was whoever wrote that in the first place smoking ? ;-)
Why on earth would you skip halfway through the stack with one stupid
magic constant, and then the rest of the way with another?
Perhaps I'm just making the mistake of assuming the existing code was
sane ... I was just uncomfortable because I didn't understand why it was
like that before, I guess.
> Dave
> I don't know where the -5 and
> -2 come from. It needs a big, fat stinking comment.
>
> Bill
> Those are trying to fish out the 2nd and 5th words from the top of the
> stack. Magic numbers stopped working; symbolic constants save the day.
Right, I see what you're doing now.
But would be nice (as Dave said) if those magic numbers were no longer
magic numbers (as you did for the other part of it), if that's possible,
or commented. Not that you haven't vastly improved it already ;-)
Thanks,
M.
-
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/