|
[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 |