From: Rusty Russell <rusty@rustcorp.com.au>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Minfei Huang <mhuang@redhat.com>,
rob.jones@codethink.co.uk, amhyung@kernel.org,
linux-kernel@vger.kernel.org, Minfei Huang <mnfhuang@gmail.com>
Subject: Re: [PATCH 1/2] Define find_symbol_in_section_t as function type to simplify the code
Date: Thu, 16 Jul 2015 20:59:47 +0930 [thread overview]
Message-ID: <87mvywmjbo.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20150715133126.c13ff1e75bf36eb0a85dcb3f@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> On Wed, 15 Jul 2015 07:22:32 +0930 Rusty Russell <rusty@rustcorp.com.au> wrote:
>> It's shorter, but it's less clear. typedefs on functions are not very
>> useful:
>> 1) They require readers to look in two places to see how to use the
>> function (ie each_symbol_section).
>> 2) They can't use the typedef to declare their function, since that
>> doesn't work in C.
>>
>> If the function were being used many times, it makes sense. But
>> it's only used twice, once static inside module.c.
>>
>
> Using a foo_t typedef for a function callback is a common pattern.
> It's (almost) the only approved use of typedefs. The usage is
> widespread enough that when one sees a foo_t type, one says "ahah,
> that's a function pointer".
I always thought of a type which can map to varying types under
different arch/configs as the typical typedef.
> Sorry, but I don't think "Rusty doesn't like it" is a good reason for
> the module code to be different.
But "Rusty has to maintain it" is a pretty strong counter argument,
IMHO.
> All of us dislike some aspects of
> kernel coding practices, but we go along because consistency is more
> important.
Consistency is important when it makes things more readable, sure.
I don't think any kernel devs are going to get confused seeing a
function pointer, and I think this patch makes the code slightly
less readable.
Enough not to apply the patch, but not enough waste more time on it.
Cheers,
Rusty.
next prev parent reply other threads:[~2015-07-16 11:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-14 6:59 [PATCH 0/2] Using function type to cleanup the function parament Minfei Huang
2015-07-14 6:59 ` [PATCH 1/2] Define find_symbol_in_section_t as function type to simplify the code Minfei Huang
2015-07-14 7:04 ` Minfei Huang
2015-07-14 21:52 ` Rusty Russell
2015-07-15 2:11 ` Minfei Huang
2015-07-15 20:31 ` Andrew Morton
2015-07-16 11:29 ` Rusty Russell [this message]
2015-07-14 6:59 ` [PATCH 2/2] Define kallsyms_cmp_symbol_t " Minfei Huang
2015-07-14 7:05 ` Minfei Huang
2015-07-14 7:06 ` [PATCH 0/2] Using function type to cleanup the function parament Minfei Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mvywmjbo.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=akpm@linux-foundation.org \
--cc=amhyung@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhuang@redhat.com \
--cc=mnfhuang@gmail.com \
--cc=rob.jones@codethink.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox