[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios stubdom
On Fri, 27 Jan 2012, Daniel De Graaf wrote: > >> @@ -1664,6 +1664,19 @@ static void corrupt(struct connection *conn, const > >> char *fmt, ...) > >> } > >> > >> > >> +#ifdef __MINIOS__ > >> +static void write_pidfile(const char *pidfile) > >> +{ > >> +} > >> + > >> +static void daemonize(void) > >> +{ > >> +} > >> + > >> +static void finish_daemonize(void) > >> +{ > >> +} > >> +#else > >> static void write_pidfile(const char *pidfile) > >> { > >> char buf[100]; > >> @@ -1711,6 +1724,19 @@ static void daemonize(void) > >> umask(0); > >> } > >> > >> +static void finish_daemonize(void) > >> +{ > >> + int devnull = open("/dev/null", O_RDWR); > >> + if (devnull == -1) > >> + barf_perror("Could not open /dev/null\n"); > >> + dup2(devnull, STDIN_FILENO); > >> + dup2(devnull, STDOUT_FILENO); > >> + dup2(devnull, STDERR_FILENO); > >> + close(devnull); > >> + xprintf = trace; > >> +} > >> +#endif > >> + > >> #ifdef NO_SOCKETS > >> static void init_sockets(int **psock, int **pro_sock) > >> { > > > > At this point we could have the MiniOS version of write_pidfile, > > daemonize, finish_daemonize in tools/xenstore/xenstored_minios.c and the > > Linux/NetBSD version of them in tools/xenstore/xenstored_linux.c. > > > > Are you suggesting this for just these functions, or all functions that are > different on minios? All the functions that are different on minios and these three in particular. > Since we already have xenstored_{linux,netbsd,solaris}.c, should the POSIX > versions be duplicated or placed in a common POSIX file (as Ian suggested)? Better not duplicating code when possible, so I support Ian's idea. > >> --- > >> tools/xenstore/Makefile | 9 ++++- > >> tools/xenstore/utils.h | 2 + > >> tools/xenstore/xenstored_core.c | 74 > >> +++++++++++++++++++++++------------- > >> tools/xenstore/xenstored_domain.c | 11 +++++ > >> 4 files changed, 68 insertions(+), 28 deletions(-) > >> > >> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile > >> index 4facb62..be892fd 100644 > >> --- a/tools/xenstore/Makefile > >> +++ b/tools/xenstore/Makefile > >> @@ -28,6 +28,10 @@ endif > >> > >> ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored > >> > >> +ifdef CONFIG_STUBDOM > >> +CFLAGS += -DNO_SOCKETS=1 > >> +endif > > > >> @@ -1822,6 +1848,11 @@ int main(int argc, char *argv[]) > >> int evtchn_fd = -1; > >> struct timeval *timeout; > >> > >> +#ifdef __MINIOS__ > >> + /* minios always uses internal DB */ > >> + tdb_flags = TDB_INTERNAL|TDB_NOLOCK; > >> +#endif > > > > can you use the "internal-db" command line option? > > > > Yes, but that begins to clutter up the xenstore stub domain's command line > with mandatory options (which seems self-contradictory). I can see your point, but they are not mandatory per se: it is possible to have a fully working POSIX open/read/write interface implementation on top of Minios one day. For example the files could reside entirely in memory, a bit like tmpfs. > >> while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options, > >> NULL)) != -1) { > >> switch (opt) { > >> @@ -1874,20 +1905,10 @@ int main(int argc, char *argv[]) > >> > >> reopen_log(); > >> > >> - /* make sure xenstored directory exists */ > >> - if (mkdir(xs_daemon_rundir(), 0755)) { > >> - if (errno != EEXIST) { > >> - perror("error: mkdir daemon rundir"); > >> - exit(-1); > >> - } > >> - } > >> - > >> - if (mkdir(xs_daemon_rootdir(), 0755)) { > >> - if (errno != EEXIST) { > >> - perror("error: mkdir daemon rootdir"); > >> - exit(-1); > >> - } > >> - } > >> + /* make sure xenstored directories exist */ > >> + /* Errors ignored here, will be reported when we open files */ > >> + mkdir(xs_daemon_rundir(), 0755); > >> + mkdir(xs_daemon_rootdir(), 0755); > >> > >> if (dofork) { > >> openlog("xenstored", 0, LOG_DAEMON); > >> @@ -1905,9 +1926,14 @@ int main(int argc, char *argv[]) > >> > >> init_sockets(&sock, &ro_sock); > >> > >> +#ifdef __MINIOS__ > >> + reopen_log_pipe[0] = -1; > >> + reopen_log_pipe[1] = -1; > >> +#else > >> if (pipe(reopen_log_pipe)) { > >> barf_perror("pipe"); > >> } > >> +#endif > > > > maybe we could have open/read/write_log_pipe functions? > > That would be useless here, since the pipe is only used to receive signals > (which minios can't do) in order to reopen a log file that minios doesn't > open. In that case Minios' implementaton would just be empty. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |