2012/4/17 Ezequiel García <elezegarcia@xxxxxxxxx>:
> On Mon, Apr 16, 2012 at 7:16 PM, Marcin Ślusarz
> <marcin.slusarz@xxxxxxxxx> wrote:
>>
>> It's better to replace it with:
>> static inline int flat_set_persistent(unsigned long relval,
>> unsigned long *persistent)
>> {
>> return 0;
>> }
>>
>> No warnings, same generated code, type safety.
>> Look around the code. It's a very common pattern.
>>
>
> Yes, I guess you're right.
> Plus it's even easier to understand than that #define in arch/sh.
>
> Are these changes suitable, or am I being too picky?
Well, it depends. If you see warnings from the code, go for it.
If there's none and code is trivial or in little used module, don't bother.
In other cases, it depends on the maintainer of changed code - some
maintainers apply cleanups eagerly, others... ignore them. You will soon
learn which subsystems to avoid :(
Little advice: You will learn more if you concentrate on improving
one subsystem. Find something that interest you and dive into the code.
Small cleanups are easy, but they should only be a warm up.
Marcin
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
