On Aug 31 2007 02:11, Satyam Sharma wrote:
>> So that you can actually pass in a const struct task_struct * without having
>> to cast it back to [non-const].
>
>... which makes zero sense, because ...
>
>> Why one would have a const struct task_struct * in the first place
>> is a different matter.
>
>... exactly.
>
>> But see
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=77adbfbf4cf96fedf9b75bb330704828c187b190
>
>That commit const-ified struct timespec * or struct timeval * arguments,
>which made sense because: (1) those functions really did not modify the
>passed structs, and, (2) callers that pass in const struct timeval *
>or const struct timespec * are indeed plausible (because one can plausibly
>have const timeval/timespec structs). As the changelog suggested, those
>callers
>
>were having to cast away the const qualifier before passing to
>these functions to avoid seeing "passing argument discards qualifiers"
>warnings. While (1) holds true for the sched.h case here, (2) does not
>(and there are no warnings to shut up either).
"those callers". There was _exactly one_ caller, and that was an out-of-tree
module. There were not any in-kernel callers before, and it did not generate
any warning. That is perhaps why no one had constified it before me. This does
not mean we should wait for a caller to pop up before constifying IMHO.
>If one really wants to go about "constifying" the kernel, then I think
>there's a lot of _data_ out there that should first be made const-
>qualified. xxx_ops function tables, and the like.
I think it is equally 'necessary'.
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
