All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: Miroslav Benes <mbenes@suse.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] module: make it clearer when we're handling kallsyms symbols vs exported symbols
Date: Thu, 22 Nov 2018 14:00:39 +0100	[thread overview]
Message-ID: <20181122130038.GA21394@linux-8ccs> (raw)
In-Reply-To: <alpine.LSU.2.21.1811221109220.6711@pobox.suse.cz>

+++ Miroslav Benes [22/11/18 11:19 +0100]:
>On Wed, 21 Nov 2018, Jessica Yu wrote:
>
>> The module loader internally works with both exported symbols
>> represented as struct kernel_symbol, as well as Elf symbols from a
>> module's symbol table. It's hard to distinguish sometimes which type of
>> symbol we're handling given that some helper function names are not
>> consistent or helpful. Take get_ksymbol() for instance - are we
>> looking for an exported symbol or a kallsyms symbol here? Or symname()
>> and kernel_symbol_name() - which function handles an exported symbol and
>> which one an Elf symbol?
>>
>> Clean up and unify the function naming scheme a bit to make it clear
>> which kind of symbol we're handling. This change only affects static
>> functions internal to the module loader.
>>
>> Signed-off-by: Jessica Yu <jeyu@kernel.org>
>
>Great. It should help a lot. Pity we cannot rename find_symbol() as well.
>
>I have only a naming nit. I think it is nice to have
><verb>_exported_<noun> convention. New kallsyms_ names don't hold it
>though. Wouldn't it be better to be consistent and have
>find_kallsyms_symbol() instead of kallsyms_find_symbol()? Or we could do
>the opposite and have a "namespace" prefix first. That is,
>exported_<verb>_<noun>. However, I don't like it that much.
>
>To be honest, your approach may be the best in the end.
>
>What do you think?

Hi Miroslav, thank you for the comment!

Yeah, that bothered me partially too. And a lot of existing helper
functions in the module loader already have a <verb>_ type prefix.

Hm, how about we use <symbol_type>_* prefixes if we are just extracting a
value, and <verb>_* prefixes for functions actually performing an
action? 

Kallsyms:

   kallsyms_symbol_name()
   kallsyms_symbol_value()
   
   find_kallsyms_symbol()
   find_kallsyms_symbol_value()
 
   etc.

Exported syms:

   kernel_symbol_name()
   kernel_symbol_value()
   
   lookup_exported_symbol()
   check_exported_symbol()
 
   etc.

I had left the kernel_symbol_* functions alone since I guess they do
describe what they're handling, they're handling struct kernel_symbol's.
But maybe I will change that to exported_symbol_name() and
exported_symbol_value() to be consistent with the naming scheme..

Thanks!

Jessica    

  reply	other threads:[~2018-11-22 13:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-21 17:51 [PATCH] module: make it clearer when we're handling kallsyms symbols vs exported symbols Jessica Yu
2018-11-22 10:19 ` Miroslav Benes
2018-11-22 13:00   ` Jessica Yu [this message]
2018-11-22 16:15     ` Miroslav Benes

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=20181122130038.GA21394@linux-8ccs \
    --to=jeyu@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbenes@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.