On Sun, Sep 3, 2017 at 12:37 AM, Christoph Hellwig <h...@infradead.org> wrote:
> On Fri, Sep 01, 2017 at 09:24:22AM -0700, Kees Cook wrote:
>> #define list_entry(ptr, type, member) container_of(ptr, type, member)
>> #define rb_entry(ptr, type, member) container_of(ptr, type, member)
>>
>> The use of a "timer_entry()" at the start of callbacks repeats the
>> struct name, which I find irritating (and it usually results in split
>> lines). For example:
>>
>> #define timer_entry(ptr, type, member) container_of(ptr, type, member)
>>
>> -static void snd_card_asihpi_timer_function(unsigned long data)
>> +static void snd_card_asihpi_timer_function(struct timer_list *t)
>> {
>> - struct snd_card_asihpi_pcm *dpcm = (struct snd_card_asihpi_pcm
>> *)data;
>> + struct snd_card_asihpi_pcm *dpcm =
>> + timer_entry(t, struct
>> snd_card_asihpi_pcm, timer);
>>
>> I prefer to tie this directly to the variable, so how about renaming
>> TIMER_CONTAINER to timer_of():
>
> The TIMER_CONTAINER semantics are more useful indeed, and I which
> we'd have a general purpose variant of that. But I was complaining
> about the name anyway. timer_of sounds ok, but timer_entry still sounds
> a bit more descriptive. As for the split lines: you'll generally
> get a lot of these, even TIMER_CONTAINER has a quite a few. I generally
> prefer to move everything right of the = to the next line as that
> becomes a lot more redable.
It feels weird to have different semantics from container_of() too, so
I'll probably just switch everything around to be like all the others,
in that they are just direct wrappers around container_of()... I'll
settle on something and switch everything over.
I'm down to about 200 more callsites. :) Found a missed pattern that
coccinelle could handle which caught about 1/3rd of my earlier
300ish...
-Kees
--
Kees Cook
Pixel Security
