From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
To: David Howells <dhowells@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] xhci: Rename SEGMENT_SIZE and SEGMENT_SHIFT as the former is used in a.out.h
Date: Tue, 2 Apr 2013 12:37:15 -0700 [thread overview]
Message-ID: <20130402193715.GA3693@xanatos> (raw)
In-Reply-To: <20541.1364926056@warthog.procyon.org.uk>
On Tue, Apr 02, 2013 at 07:07:36PM +0100, David Howells wrote:
> Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:
>
> > I guess my question is a deeper one: do we need to rename all the xHCI
> > macros to have the XHCI_ prefix, in order to avoid future collision?
> > For example, one of the macros is MAX_HC_PORTS, which could possibly be
> > used by other host drivers in the future.
>
> Hmmm...
>
> I suspect the question is whether your symbols are likely to collide with
> core symbols rather than symbols of unrelated drivers - after all, you're
> unlikely to be #including the headers of those drivers.
>
> I personally prefer to prefix the names of symbols in drivers with something
> consistent for that driver to reduce namespace collisions - but I know not
> everyone cares about that. Linux doesn't have much of a policy in this area
> though. I also like it because it makes tags easier to use (fewer definitions
> of the same symbol).
>
> Whether you should go back and rename existing xHCI functions, I don't know.
> I'd be tempted to leave it for now unless there's some collision. However,
> things like MAX_HC_PORTS does seem a little generic. Further #define
> collisions go unnoticed under some circumstances. Two obvious cases are (a)
> redefinition of a symbol because it happens to be the same value and (b) where
> the second one is accidentally suppressed because it is wrapped in a
> conditional.
Hmm, yeah, I think it doesn't make sense to change all the macros now.
If I were starting a new driver, I think I would use a common prefix.
I'll add the macro renaming to my todo list and see if I can get some
newbie to take it on. 8)
> Perhaps we should move to C++ and use namespaces;-)
Hah!
Sarah Sharp
prev parent reply other threads:[~2013-04-02 19:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 18:48 [PATCH 1/2] xhci: Use ilog2() rather than __ffs() for calculating SEGMENT_SHIFT David Howells
2013-03-28 18:48 ` [PATCH 2/2] xhci: Rename SEGMENT_SIZE and SEGMENT_SHIFT as the former is used in a.out.h David Howells
2013-03-28 20:15 ` Sarah Sharp
2013-03-28 22:32 ` David Howells
2013-03-29 0:10 ` Sarah Sharp
2013-04-02 18:07 ` David Howells
2013-04-02 19:37 ` Sarah Sharp [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=20130402193715.GA3693@xanatos \
--to=sarah.a.sharp@linux.intel.com \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.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.