From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Jon Masters <jonathan@jonmasters.org>
Cc: Tilman Schmidt <t.schmidt@phoenixsoftware.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: should new kfifo implementation really be exporting that much?
Date: Mon, 22 Mar 2010 10:32:32 -0400 (EDT) [thread overview]
Message-ID: <alpine.LFD.2.00.1003221030360.25001@localhost> (raw)
In-Reply-To: <20100321093207.GX4426@perihelion.bos.jonmasters.org>
On Sun, 21 Mar 2010, Jon Masters wrote:
> On Sun, Mar 14, 2010 at 12:49:08PM -0400, Robert P. J. Day wrote:
> > On Sun, 14 Mar 2010, Tilman Schmidt wrote:
> >
> > > Am 14.03.2010 15:57 schrieb Robert P. J. Day:
> > > > as a short followup, kfifo.h strongly implies that a lot of the
> > > > above shouldn't be exported:
> > > >
> > > > ...
> > > > /*
> > > > * __kfifo_in_... internal functions for put date into the fifo
> > > > * do not call it directly, use kfifo_in_rec() instead
> > > > */
> > > > ...
> > > >
> > > > anyway, you get the idea. it would seem that a lot of those EXPORTs
> > > > should be removed, no?
> > >
> > > If you look at kfifo_in_rec(), it's a static inline void
> > > function defined in kfifo.h and which calls __kfifo_in_generic()
> > > or __kfifo_in_rec(). I don't think you'll be able to make that
> > > work without exporting those functions.
> >
> > huh. i believe you're correct. i'll take a closer look but i
> > still get this feeling that there's something ... messy about that
> > API. case in point: kfifo_in_rec() is *not* being exported, but a
> > routine that it invokes -- __kfifo_in_generic() -- *is* being
> > exported. doesn't that just seem a bit backwards?
>
> I believe it would be a good idea to have an export type explicitly
> covering symbols that are exported solely for the use of inlines,
> just for tidying up these situations. EXPORT_SYMBOL_INTERNAL?
i wasn't suggesting anything as drastic as inventing a new export
level :-), i just wanted to verify that the current situation as to
what's currently exported related to kfifo just seemed a bit odd and
inconsistent. but a new export level might support the removal of a
considerable amount from the fully-exported namespace.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
prev parent reply other threads:[~2010-03-22 14:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-14 13:32 should new kfifo implementation really be exporting that much? Robert P. J. Day
2010-03-14 14:57 ` Robert P. J. Day
2010-03-14 16:37 ` Tilman Schmidt
2010-03-14 16:49 ` Robert P. J. Day
2010-03-21 9:32 ` Jon Masters
2010-03-22 14:32 ` Robert P. J. Day [this message]
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=alpine.LFD.2.00.1003221030360.25001@localhost \
--to=rpjday@crashcourse.ca \
--cc=jonathan@jonmasters.org \
--cc=linux-kernel@vger.kernel.org \
--cc=t.schmidt@phoenixsoftware.de \
/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.