From: Ian Campbell <ian.campbell@citrix.com>
To: Thanos Makatos <thanos.makatos@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH 09 of 16 RFC] blktap3: Introduce the tapdisk control function prototypes
Date: Tue, 30 Oct 2012 11:43:04 +0100 [thread overview]
Message-ID: <1351593784.16017.0.camel@hastur.hellion.org.uk> (raw)
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CB7@LONPMAILBOX01.citrite.net>
> > Anyway, since I think this header is intended to be used by consumers
> > of blktap (rather than internally) I think you need to namespace the
> > macros. See tools/include/xen-external/bsd-sys-queue-h-seddery and its
> > usages in tools/libxl/Makefile and extras/mini-os/Makefile to create
> > local namespaced versions for libxl and mini-os.
> >
> Just out of curiosity, what are the benefits of namespacing the
> macros? Google doesn't give anything relevant.
It's just good policy for libraries to avoid clashing with names defined
by the application which uses them, or with other libraries which that
library might be using simultaneously.
IOW an application might have it's own TAILQ_ENTRY macro which has
nothing to do with the one you would like to use. By naming it
BLKTAP_TAILQ_ENTRY in blktap (and in general avoiding generic sounding
names) you minimise the chances of this sort of thing.
Of course if a header/type is purely internal to blktap then this
doesn't matter.
Ian.
next prev parent reply other threads:[~2012-10-30 10:43 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-24 17:02 [PATCH 00 of 16 RFC] add libxl support for blktap3 and introduce the blktap3 build system Thanos Makatos
2012-10-24 17:02 ` [PATCH 01 of 16 RFC] blktap3: Introduce the blktap3 device type Thanos Makatos
2012-10-26 11:17 ` Ian Campbell
2012-10-29 17:35 ` Thanos Makatos
2012-10-24 17:02 ` [PATCH 02 of 16 RFC] blktap3: Introduce blktap3 support for libxl Thanos Makatos
2012-10-24 17:02 ` [PATCH 03 of 16 RFC] blktap3: support for blktap3 in libxl Makefile Thanos Makatos
2012-10-26 11:19 ` Ian Campbell
2012-10-30 10:49 ` Thanos Makatos
2012-10-24 17:02 ` [PATCH 04 of 16 RFC] blktap3: change libxl__blktap_devpath prototype to return an error code Thanos Makatos
2012-10-26 11:21 ` Ian Campbell
2012-10-29 17:41 ` Thanos Makatos
2012-10-30 7:40 ` Ian Campbell
2012-10-24 17:02 ` [PATCH 05 of 16 RFC] blktap3: Don't check if blktap is available Thanos Makatos
2012-10-26 11:23 ` Ian Campbell
2012-10-29 17:43 ` Thanos Makatos
2012-10-30 7:41 ` Ian Campbell
2012-10-30 9:07 ` Roger Pau Monné
2012-10-30 9:30 ` Thanos Makatos
2012-10-24 17:02 ` [PATCH 06 of 16 RFC] blktap3: Remove physical device creation for libxl Thanos Makatos
2012-10-24 17:02 ` [PATCH 07 of 16 RFC] blktap3: Introduce blktap3 top-level Makefile Thanos Makatos
2012-10-26 11:25 ` Ian Campbell
2012-10-26 20:04 ` Philipp Hahn
2012-10-29 11:05 ` Ian Campbell
2012-10-24 17:02 ` [PATCH 08 of 16 RFC] blktap3: Introduce message types and structures Thanos Makatos
2012-10-26 11:27 ` Ian Campbell
2012-10-29 17:47 ` Thanos Makatos
2012-10-24 17:02 ` [PATCH 09 of 16 RFC] blktap3: Introduce the tapdisk control function prototypes Thanos Makatos
2012-10-26 11:32 ` Ian Campbell
2012-10-30 10:04 ` Thanos Makatos
2012-10-30 10:43 ` Ian Campbell [this message]
2012-10-24 17:02 ` [PATCH 10 of 16 RFC] blktap3: Introduce the blktap header file Thanos Makatos
2012-10-26 11:36 ` Ian Campbell
2012-10-29 17:34 ` Thanos Makatos
2012-10-24 17:02 ` [PATCH 11 of 16 RFC] blktap3: Provide empty implementation for the tap_ctl_list and tap_ctl_list_free functions Thanos Makatos
2012-10-26 11:37 ` Ian Campbell
2012-10-30 10:29 ` Thanos Makatos
2012-10-24 17:02 ` [PATCH 12 of 16 RFC] blktap3: Provide empty implementation for tap_ctl_destroy Thanos Makatos
2012-10-24 17:02 ` [PATCH 13 of 16 RFC] blktap3: Provide empty implementation for tap_ctl_create Thanos Makatos
2012-10-24 17:02 ` [PATCH 14 of 16 RFC] blktap3: Provide Makefile for compiling the blktap3 control library Thanos Makatos
2012-10-26 11:40 ` Ian Campbell
2012-10-30 11:11 ` Thanos Makatos
2012-10-30 11:22 ` Ian Campbell
2012-10-24 17:02 ` [PATCH 15 of 16 RFC] blktap3: Include the blktap3/control Makefile in the blktap3 compilation Thanos Makatos
2012-10-24 17:02 ` [PATCH 16 of 16 RFC] blktap3: Implement libxl__blktap_devpath and libxl__device_destroy_tapdisk Thanos Makatos
2012-10-26 11:46 ` Ian Campbell
2012-10-30 11:24 ` Thanos Makatos
2012-10-30 11:25 ` Ian Campbell
2012-10-30 11:29 ` Thanos Makatos
2012-10-26 11:14 ` [PATCH 00 of 16 RFC] add libxl support for blktap3 and introduce the blktap3 build system Ian Campbell
2012-10-29 16:33 ` Thanos Makatos
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=1351593784.16017.0.camel@hastur.hellion.org.uk \
--to=ian.campbell@citrix.com \
--cc=thanos.makatos@citrix.com \
--cc=xen-devel@lists.xensource.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 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).