From: "Chris Leech" <chris.leech@gmail.com>
To: "Andrew Morton" <akpm@osdl.org>
Cc: "Sam Ravnborg" <sam@ravnborg.org>,
jeff@garzik.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: Discourage duplicate symbols in the kernel? [Was: Intel I/O Acc...]
Date: Mon, 6 Mar 2006 11:56:28 -0800 [thread overview]
Message-ID: <41b516cb0603061156n79d1d572n5f376819ad5f3bf4@mail.gmail.com> (raw)
In-Reply-To: <20060305011852.368c016e.akpm@osdl.org>
On 3/5/06, Andrew Morton <akpm@osdl.org> wrote:
> Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > On Sun, Mar 05, 2006 at 12:09:33AM -0800, Andrew Morton wrote:
> > > > +
> > > > +static inline u8 read_reg8(struct cb_device *device, unsigned int offset)
> > > > +{
> > > > + return readb(device->reg_base + offset);
> > > > +}
> > >
> > > These are fairly generic-sounding names. In fact the as-yet-unmerged tiacx
> > > wireless driver is already using these, privately to
> > > drivers/net/wireless/tiacx/pci.c.
> >
> > Do we in general discourage duplicate symbols even if they are static?
>
> Well, it's a bit irritating that it confuses ctags. But in this case, one
> set is in a header file so the risk of collisions is much-increased.
They're in a header file that's specific to a single driver, so I
don't see where a conflict would occur. But I didn't think about
ctags, and these can easily be prefixed so I'll go ahead and change
them.
- Chris
next prev parent reply other threads:[~2006-03-06 19:56 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-03 21:40 [PATCH 0/8] Intel I/O Acceleration Technology (I/OAT) Chris Leech
2006-03-03 21:42 ` [PATCH 1/8] [I/OAT] DMA memcpy subsystem Chris Leech
2006-03-04 1:40 ` David S. Miller
2006-03-06 19:39 ` Chris Leech
2006-03-04 19:20 ` Benjamin LaHaise
2006-03-06 19:48 ` Chris Leech
2006-03-03 21:42 ` [PATCH 3/8] [I/OAT] Setup the networking subsystem as a DMA client Chris Leech
2006-03-03 21:42 ` [PATCH 4/8] [I/OAT] Utility functions for offloading sk_buff to iovec copies Chris Leech
2006-03-05 7:15 ` Andrew Morton
2006-03-03 21:42 ` [PATCH 5/8] [I/OAT] Structure changes for TCP recv offload to I/OAT Chris Leech
2006-03-05 7:19 ` Andrew Morton
2006-03-03 21:42 ` [PATCH 6/8] [I/OAT] Rename cleanup_rbuf to tcp_cleanup_rbuf and make non-static Chris Leech
2006-03-03 21:42 ` [PATCH 7/8] [I/OAT] Add a sysctl for tuning the I/OAT offloaded I/O threshold Chris Leech
2006-03-04 11:22 ` Alexey Dobriyan
2006-03-05 7:21 ` Andrew Morton
2006-03-03 21:42 ` [PATCH 8/8] [I/OAT] TCP recv offload to I/OAT Chris Leech
2006-03-04 16:39 ` Pavel Machek
2006-03-04 23:18 ` Greg KH
2006-03-06 19:28 ` Chris Leech
2006-03-05 7:30 ` Andrew Morton
2006-03-05 8:45 ` Andrew Morton
2006-03-05 10:27 ` David S. Miller
2006-03-06 19:36 ` Chris Leech
2006-03-03 22:27 ` [PATCH 0/8] Intel I/O Acceleration Technology (I/OAT) Jeff Garzik
2006-03-03 22:39 ` Chris Leech
2006-03-03 22:45 ` Jeff Garzik
2006-03-04 11:35 ` Evgeniy Polyakov
2006-03-05 8:09 ` Andrew Morton
2006-03-05 9:02 ` Discourage duplicate symbols in the kernel? [Was: Intel I/O Acc...] Sam Ravnborg
2006-03-05 9:18 ` Andrew Morton
2006-03-06 19:56 ` Chris Leech [this message]
2006-03-03 22:58 ` [PATCH 0/8] Intel I/O Acceleration Technology (I/OAT) Kumar Gala
2006-03-03 23:32 ` Chris Leech
2006-03-04 18:46 ` Jan Engelhardt
2006-03-04 21:41 ` David S. Miller
2006-03-04 22:05 ` Gene Heskett
2006-03-04 22:16 ` David S. Miller
2006-03-05 13:45 ` Jan Engelhardt
2006-03-05 13:55 ` Arjan van de Ven
2006-03-05 16:14 ` Matthieu CASTET
2006-03-05 16:30 ` Jeff Garzik
2006-03-06 19:24 ` Chris Leech
2006-03-06 19:15 ` Chris Leech
2006-03-05 1:43 ` Evgeniy Polyakov
2006-03-05 2:08 ` David S. Miller
2006-03-06 17:44 ` Ingo Oeser
2006-03-07 7:44 ` Evgeniy Polyakov
2006-03-07 9:43 ` Ingo Oeser
2006-03-07 10:16 ` Evgeniy Polyakov
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=41b516cb0603061156n79d1d572n5f376819ad5f3bf4@mail.gmail.com \
--to=chris.leech@gmail.com \
--cc=akpm@osdl.org \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sam@ravnborg.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).