Messages in this thread | | | From | Kees Cook <> | Date | Sun, 3 Sep 2017 13:18:44 -0700 | Subject | Re: Converting struct timer_list callback argument to struct timer_list * |
| |
On Sun, Sep 3, 2017 at 12:37 AM, Christoph Hellwig <hch@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
| |