From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: jim.cromie@gmail.com
Cc: kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: is there an efficient module_is_builtin() test ?
Date: Tue, 09 Mar 2021 17:25:08 -0500 [thread overview]
Message-ID: <229754.1615328708@turing-police> (raw)
In-Reply-To: <CAJfuBxxS+x6sWyi5XUW16555MCj=E+-C9usfUNh6RV-Yvv2duw@mail.gmail.com>
On Tue, 09 Mar 2021 12:55:14 -0700, jim.cromie@gmail.com said:
> To use the index, I need &dyndbg_sites[], and that only works
> for builtin-module's callsites. For loaded modules, I can/have
> added a pointer to the section into module load_info, giving me
> the base I will need for the ! builtin branch.
>
> I just need a not expensive is-it-builtin (modref)
One way to sidestep it is to stick in an EXPORT_SYMBOL(dyndbg_sites)
in the .c file you're defining it, and let the module loader do all the heavy
lifting for you. Not sure if some license purist would insist on EXPORT_SYMBOL_GPL
instead - the difference will only matter for out-of-tree non-GPL modules.
An slightly uglier solution is to do something like
#if defined(MODULE)
#define FIND_DEBUG /* code to find via load_info */
#else
#define FIND_DEBUG /* code to load &dyndbg_site directly */
#endif
which you should probably stick into a suitable .h file, and then
stick your newly defined FIND_DEBUG where you need the magic
happen (probably in a .h file as well)
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2021-03-09 22:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-09 19:55 is there an efficient module_is_builtin() test ? jim.cromie
2021-03-09 22:25 ` Valdis Klētnieks [this message]
2021-03-17 4:59 ` jim.cromie
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=229754.1615328708@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=jim.cromie@gmail.com \
--cc=kernelnewbies@kernelnewbies.org \
/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.