Re: [Xen-devel] [PATCH for-4.6 v2] tools/hotplug: Add an initscript to start "xl devd" in a driver domain

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

El 16/07/15 a les 18.58, Ian Campbell ha escrit:
> The removal of the udev rules highlighted that although it has been
> replaced by "xl devd" there isn't an initscript to replace it.
> 
> To enable this add a --pidfile option to xl devd.
> 
> Tested on Linux by running the script in dom0 and checking the daemon
> was started/stopped, but not in an actual driver domain environment
> since I don't have one conveniently available. I also checked that
> running without the --pidfile option still works.
> 
> Scripts mainly cribbed from the xencommons for each platform.
> 
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> Cc: Roger Pau Monnà <roger.pau@xxxxxxxxxx>
> Cc: Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>
> Cc: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
> ---
> For 4.6: I think having removed the udev rules we ought to include
> this, it's basically zero risk to normal operation.
> 
> Nothing seems to start xl devd for domain 0 in *BSD, nor is xenbackend
> started. Is that correct?
> 
> v2: Check in Linux script that we don't start on dom0. I don't know
> the equivalent for *BSD.

At least on FreeBSD there's no easy way to know if we are running on
Dom0 from userspace (unless we start using hypercalls with privcmd).

I could add a dummy device (let's say /dev/xen/control) that's only
present if we are running on Dom0, does that sound reasonable?

Another option would be to add a small C program that can use hypercalls
and privcmd to detect if we are running on Dom0 or not, but that seems
over engineering it.

[...]

> diff --git a/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in 
> b/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
> new file mode 100644
> index 0000000..25e3edd
> --- /dev/null
> +++ b/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
> @@ -0,0 +1,48 @@
> +#!/bin/sh
> +#
> +# PROVIDE: xendriverdomain
> +# REQUIRE: DAEMON
> +#
> +# Should be run in a driver domain, but not in domain 0.
> +
> +. /etc/rc.subr
> +
> +. /etc/xen/scripts/hotplugpath.sh

This should have been:

. @XEN_SCRIPT_DIR@/hotplugpath.sh

I will send a patch ASAP to fix it.

[...]

> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index df89777..483eb71 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -477,7 +477,7 @@ out:
>      flush_stream(fh);
>  }
>  
> -static int do_daemonize(char *name)
> +static int do_daemonize(char *name, const char *pidfile)
>  {
>      char *fullname;
>      pid_t child1;
> @@ -509,6 +509,31 @@ static int do_daemonize(char *name)
>  
>      CHK_SYSCALL(daemon(0, 1));
>  
> +    if (pidfile) {
> +        int fd = open(pidfile, O_RDWR | O_CREAT, S_IRUSR|S_IWUSR);
> +        char *pid = NULL;
> +
> +        if (fd == -1) {
> +            perror("Unable to open pidfile");
> +            exit(1);
> +        }
> +
> +        if (asprintf(&pid, "%ld\n", (long)getpid()) == -1) {
> +            perror("Formatting pid");
> +            exit(1);
> +        }
> +
> +        if (write(fd, pid, strlen(pid)) < 0) {
> +            perror("Writing pid");
> +            exit(1);
> +        }
> +
> +        if ( close(fd) < 0 ) {

<pedantic>
The line above doesn't follow libxl coding style.
</pedantic>

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel