firstly, thank you for not Cc:-ing me. I learned about this revert only
once it was done deal in Linus' tree. You objected to the patch
originally when it was submitted to lkml, and plausible arguments were
presented against your (bogus) objection:
http://article.gmane.org/gmane.linux.kernel.janitors/14623
in that thread, two months ago, you essentially conceded Jan
Engelhardt's argument by not replying to his points, so i kept Joe's
patch. And now you continue this "discussion" by asking for a revert and
not Cc:-ing me, Joe or Jan - which is quite sneaky.
the const markers indeed had no real purpose in terms of code generation
(gcc can figure it out whether something is modified by an inline
function), but they had a documentation/intent purpose, and they are
plausible if a non-inlined function uses a const task struct in the
future. For example any of these functions could be un-inlined and could
use (internally) one of the remaining inlines - in that case code
generation gets better from the constifying as well. There are also a
good deal of helper functions around task struct which could be marked
with const.
we do have other inline functions in include/linux/*.h with 'const'
arguments, so marking arguments with const is not without precedent and
this was pointed out to you in the original discussion.
-ENOPARSE. 'const struct task_struct *' says that the task struct is not
supposed to be modified within that (inline) function. That _does_ make
sense.
so unless i'm missing something, your request for revert was pretty
rude, technically incorrect and you also tried to circumvent the normal
course of discussion. I have no strong feelings either way technically
(the patch is borderline - we dont actively pass around const
task_struct pointers at the moment - but we could start doing so, if we
had the constification), but i do have strong feelings against the kind
of behavior you showed here.
Ingo
-
