All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Harald Freudenberger <freude@linux.ibm.com>,
	Sebastian Ott <sebott@linux.ibm.com>,
	Tony Krowiak <akrowiak@linux.ibm.com>,
	linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	oberpar@linux.ibm.com, pmorel@linux.ibm.com, pasic@linux.ibm.com
Subject: Re: [PATCH] zcrypt: handle AP Info notification from CHSC SEI command
Date: Thu, 21 Feb 2019 13:55:02 +0100	[thread overview]
Message-ID: <20190221125502.GB4221@osiris> (raw)
In-Reply-To: <20190221131240.0ab463d1.cohuck@redhat.com>

On Thu, Feb 21, 2019 at 01:12:40PM +0100, Cornelia Huck wrote:
> On Thu, 21 Feb 2019 11:42:25 +0100
> Harald Freudenberger <freude@linux.ibm.com> wrote:
> 
> > On 30.01.19 19:32, Sebastian Ott wrote:
> > > On Wed, 30 Jan 2019, Tony Krowiak wrote:  
> 
> > >>  /*
> > >> +* A config change has happened, Force an ap bus rescan.
> > >> +*/
> > >> +void ap_bus_cfg_chg(void)
> > >> +{
> > >> +	AP_DBF(DBF_INFO, "%s config change, forcing bus rescan\n", __func__);
> > >> +
> > >> +	ap_bus_force_rescan();
> > >> +}
> > >> +EXPORT_SYMBOL(ap_bus_cfg_chg);  
> > > There is no need for the export symbol - you don't call that function
> > > from module code.  
> > That's what I have learned now: You don't need to export a symbol
> > as long as the symbol is only called in static code parts of the kernel.
> > But you need to export it when it is intended to be used by code
> > which sits in a kernel module. So now the big question:
> > How does a provider of a function in the kernel know, if the caller is in static
> > code or in module code ? And ... maybe this may even change over
> > the time. So my recommendation is to always export the symbol with
> > the EXPORT_SYMBOL macro. This way you don't need to change the
> > code providing a function when the caller code changes or additional
> > code uses the symbol.
> > 
> > Other opinions ?
> 
> Well, if you know it will be called from module code in upcoming
> patches, export it. If not, I consider it the choice of the maintainer.
> You can easily add the export later on, if needed, anyway, and I don't
> consider changing the code a problem.
> 
> In this particular case, both exporting and not exporting looked like
> reasonable choices to me.

The number of exported symbols should be as small as possible. Each
exported symbol eats up extra memory for meta information, plus I
really do not want to deal with semi-automated bots sending patches to
remove not needed exported symbols.

You can check usage of exported symbols with "make export_report".

  reply	other threads:[~2019-02-21 12:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30 17:48 [PATCH] zcrypt: handle AP Info notification from CHSC SEI command Tony Krowiak
2019-01-30 18:32 ` Sebastian Ott
2019-01-31 23:28   ` Tony Krowiak
2019-02-01  9:01     ` Heiko Carstens
2019-02-01 11:08       ` Martin Schwidefsky
2019-02-01 13:05       ` Heiko Carstens
2019-02-01 15:40         ` Tony Krowiak
2019-02-01 15:38       ` Tony Krowiak
2019-02-04 10:06         ` Harald Freudenberger
2019-02-05 20:26           ` Tony Krowiak
2019-02-04 10:01     ` Sebastian Ott
2019-02-05 20:27       ` Tony Krowiak
2019-02-21 10:42   ` Harald Freudenberger
2019-02-21 12:12     ` Cornelia Huck
2019-02-21 12:55       ` Heiko Carstens [this message]
2019-01-31  9:09 ` Pierre Morel
2019-01-31 23:32   ` Tony Krowiak
2019-01-31  9:23 ` Pierre Morel
2019-01-31  9:55 ` Cornelia Huck
2019-01-31 23:50   ` Tony Krowiak
2019-02-01 14:35     ` Cornelia Huck
2019-02-01 15:50       ` Tony Krowiak
2019-02-04 10:15       ` Harald Freudenberger
2019-02-04 12:07         ` Cornelia Huck
2019-02-05 20:30         ` Tony Krowiak
2019-02-03  9:25 ` kbuild test robot
2019-02-03  9:25   ` kbuild test robot

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=20190221125502.GB4221@osiris \
    --to=heiko.carstens@de.ibm.com \
    --cc=akrowiak@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=freude@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=oberpar@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=pmorel@linux.ibm.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=sebott@linux.ibm.com \
    /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.