[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.