9:02 a.m.
This patch is in preparation for allowing libguestfs to use alternate
"vmchannel" implementations.
Although it's not a functional change, I think it is worthwhile on its
own because use of the term "vmchannel" in the names of constants is
inappropriate since (a) the "-net channel" option is now properly
known upstream as "guestfwd", and (b) no one can agree on what
"vmchannel" really means.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
9:44 a.m.
Richard W.M. Jones wrote:
This patch is in preparation for allowing libguestfs to use
alternate
"vmchannel" implementations.
Although it's not a functional change, I think it is worthwhile on its
own because use of the term "vmchannel" in the names of constants is
inappropriate since (a) the "-net channel" option is now properly
known upstream as "guestfwd", and (b) no one can agree on what
"vmchannel" really means.
...
>From 45630d4ac47511c5c0dc55a22fadba4b9236bf61 Mon Sep 17 00:00:00
2001
From: Richard Jones <rjones(a)trick.home.annexia.org>
Date: Tue, 15 Sep 2009 17:14:44 +0100
Subject: [PATCH 4/5] Remove explicit guestfs=10.0.2.4:6666 kernel command line
parameter.
Since we control the appliance tightly, we can just specify
that it will always use a particular host and port, and we
don't need to pass it on the command line each time.
Also the VMCHANNEL_* constants are only relevant to the
particular guestfwd vmchannel implementation, so we rename
them as GUESTFWD_*.
---
daemon/guestfsd.c | 78 ++++++++++++++--------------------------------------
src/guestfs.c | 10 +++----
2 files changed, 25 insertions(+), 63 deletions(-)
diff --git a/daemon/guestfsd.c b/daemon/guestfsd.c
index af554bf..ebaf960 100644
--- a/daemon/guestfsd.c
+++ b/daemon/guestfsd.c
@@ -43,8 +43,8 @@
static void usage (void);
/* Also in guestfs.c */
-#define VMCHANNEL_PORT "6666"
-#define VMCHANNEL_ADDR "10.0.2.4"
+#define GUESTFWD_PORT "6666"
+#define GUESTFWD_ADDR "10.0.2.4"
All looks good, though this seems like it *is* a functional
change, since it removes the -h and -p options below.
Two questions:
First, note the definition of GUESTFWD_ADDR above
Why the commented-out one below (in src/guestfs.c):
//#define GUESTFWD_ADDR "10.0.2.4"
Second, I saw this in the context:
/* Make sure SIGPIPE doesn't kill us. */
memset (&sa, 0, sizeof sa);
sa.sa_handler = SIG_IGN;
Have you considered alternate ways of ignoring SIGPIPE?
Ignoringn SIGPIPE across the board can cause problems (albeit subtle)
in unsuspecting child processes.
9:52 a.m.
On Thu, Sep 17, 2009 at 04:44:11PM +0200, Jim Meyering wrote:
All looks good, though this seems like it *is* a functional
change, since it removes the -h and -p options below.
Ah yes, you're right. Removing these is OK I think because no one
would ever have used them, and they are not used by the appliance init
script.
Two questions:
First, note the definition of GUESTFWD_ADDR above
Why the commented-out one below (in src/guestfs.c):
//#define GUESTFWD_ADDR "10.0.2.4"
This is just commented out because it isn't used, and gcc now gives a
warning when we define but don't use a macro.
Second, I saw this in the context:
> /* Make sure SIGPIPE doesn't kill us. */
> memset (&sa, 0, sizeof sa);
> sa.sa_handler = SIG_IGN;
Have you considered alternate ways of ignoring SIGPIPE?
Ignoringn SIGPIPE across the board can cause problems (albeit subtle)
in unsuspecting child processes.
I didn't know there were alternate ways to ignore SIGPIPE. Can you
give some examples of how it should be done? (Possibly in a new
thread -- seems a separate issue from the patch at hand).
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
11:58 a.m.
New subject: avoid ignoring SIGPIPE globally
Richard W.M. Jones wrote:
On Thu, Sep 17, 2009 at 04:44:11PM +0200, Jim Meyering wrote:
...
> Second, I saw this in the context:
>
> > /* Make sure SIGPIPE doesn't kill us. */
> > memset (&sa, 0, sizeof sa);
> > sa.sa_handler = SIG_IGN;
>
> Have you considered alternate ways of ignoring SIGPIPE?
> Ignoring SIGPIPE across the board can cause problems (albeit subtle)
> in unsuspecting child processes.
I didn't know there were alternate ways to ignore SIGPIPE. Can you
give some examples of how it should be done? (Possibly in a new
thread -- seems a separate issue from the patch at hand).
Depending on portability (this is mandated by POSIX 2006 and in glibc
long before then), and context (sockets) you can use the MSG_NOSIGNAL flag:
The SIGPIPE signal shall be sent to a thread that attempts to send data on
a socket that is no longer able to send (one that is no longer connected),
except that the signal is suppressed if the MSG_NOSIGNAL flag is used
in calls to send(), sendto(), and sendmsg().
From "Socket Types" in
http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#t...
5583
days inactive
5583
days old
3 comments
2 participants
participants (2)
-
Jim Meyering -
Richard W.M. Jones