Xen devel - Jan 2013 - [PATCH] tools: revert to using /var and /etc/

26470:acaf29203cf9 "tools+stubdom: install under /usr/local by
default" moved more stuff under /usr/local than was desirable.

In particular SYSCONFIG_DIR (configuration for initscripts) moved to
/usr/local/etc/{sysconfig,defaults} while the initscripts themselves
(correctly) remained in /etc/init.d. Moving /etc/xen/scripts breaks
the udev bakcned rules file. Lastly stuff under /var was moved to
/usr/local/var.

Move these back to /etc/ and /var. Moving /etc wholesale rather thsn
just the problematic bits is preferable for consistency.

Although there seems to be some disagreement about /usr/local/var vs
/var using /var is compatible with the FHS and what we think most
people will expect.

Most of this impacts Linux only but NetBSD appears to have been using
/usr/local/var/lib which I have also reset to /var/lib.

Note that we already paid no attention to autoconf --sysconfdir or
--localstatedir (''etc'' and ''var''
respectively) so there is no change
from that PoV.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>
Cc: Ian Jackson <ian.jackson@citrix.com?
---
 config/NetBSD.mk |    4 ----
 config/StdGNU.mk |    7 -------
 2 files changed, 0 insertions(+), 11 deletions(-)

diff --git a/config/NetBSD.mk b/config/NetBSD.mk
index 12c8a34..141de7c 100644
--- a/config/NetBSD.mk
+++ b/config/NetBSD.mk
@@ -6,10 +6,6 @@ PRIVATE_BINDIR = $(BINDIR)
 
 DLOPEN_LIBS  
-ifeq ($(PREFIX),/usr)
 XEN_LOCK_DIR = /var/lib
-else
-XEN_LOCK_DIR = $(PREFIX)/var/lib
-endif
 
 WGET = ftp
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 3febe8d..25fc594 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -41,17 +41,10 @@ XENFIRMWAREDIR = $(PREFIX)/lib/xen/boot
 PRIVATE_PREFIX = $(LIBDIR)/xen
 PRIVATE_BINDIR = $(PRIVATE_PREFIX)/bin
 
-ifeq ($(PREFIX),/usr)
 CONFIG_DIR = /etc
 XEN_LOCK_DIR = /var/lock
 XEN_RUN_DIR = /var/run/xen
 XEN_PAGING_DIR = /var/lib/xen/xenpaging
-else
-CONFIG_DIR = $(PREFIX)/etc
-XEN_LOCK_DIR = $(PREFIX)/var/lock
-XEN_RUN_DIR = $(PREFIX)/var/run/xen
-XEN_PAGING_DIR = $(PREFIX)/var/lib/xen/xenpaging
-endif
 
 SYSCONFIG_DIR = $(CONFIG_DIR)/$(CONFIG_LEAF_DIR)
 
-- 
1.7.2.5

On 25/01/13 14:10, Ian Campbell wrote:
> 26470:acaf29203cf9 "tools+stubdom: install under /usr/local by
> default" moved more stuff under /usr/local than was desirable.
> 
> In particular SYSCONFIG_DIR (configuration for initscripts) moved to
> /usr/local/etc/{sysconfig,defaults} while the initscripts themselves
> (correctly) remained in /etc/init.d. Moving /etc/xen/scripts breaks
> the udev bakcned rules file. Lastly stuff under /var was moved to
> /usr/local/var.
> 
> Move these back to /etc/ and /var. Moving /etc wholesale rather thsn
> just the problematic bits is preferable for consistency.
> 
> Although there seems to be some disagreement about /usr/local/var vs
> /var using /var is compatible with the FHS and what we think most
> people will expect.
> 
> Most of this impacts Linux only but NetBSD appears to have been using
> /usr/local/var/lib which I have also reset to /var/lib.
> 
> Note that we already paid no attention to autoconf --sysconfdir or
> --localstatedir (''etc'' and ''var''
respectively) so there is no change
> from that PoV.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Roger Pau Monne <roger.pau@citrix.com>
> Cc: Ian Jackson <ian.jackson@citrix.com?
Acked-by: Roger Pau Monné <roger.pau@citrix.com>

On Fri, 2013-01-25 at 13:41 +0000, Roger Pau Monne
wrote:
> On 25/01/13 14:10, Ian Campbell wrote:
> > 26470:acaf29203cf9 "tools+stubdom: install under /usr/local by
> > default" moved more stuff under /usr/local than was desirable.
> > 
> > In particular SYSCONFIG_DIR (configuration for initscripts) moved to
> > /usr/local/etc/{sysconfig,defaults} while the initscripts themselves
> > (correctly) remained in /etc/init.d. Moving /etc/xen/scripts breaks
> > the udev bakcned rules file. Lastly stuff under /var was moved to
> > /usr/local/var.
> > 
> > Move these back to /etc/ and /var. Moving /etc wholesale rather thsn
> > just the problematic bits is preferable for consistency.
> > 
> > Although there seems to be some disagreement about /usr/local/var vs
> > /var using /var is compatible with the FHS and what we think most
> > people will expect.
> > 
> > Most of this impacts Linux only but NetBSD appears to have been using
> > /usr/local/var/lib which I have also reset to /var/lib.
> > 
> > Note that we already paid no attention to autoconf --sysconfdir or
> > --localstatedir ('etc' and 'var' respectively) so
there is no change
> > from that PoV.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Roger Pau Monne <roger.pau@citrix.com>
> > Cc: Ian Jackson <ian.jackson@citrix.com?
> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Applied, thanks.


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

Friday, January 25, 2013, 5:15:24 PM, you wrote:
> On Fri, 2013-01-25 at 13:41 +0000, Roger Pau Monne wrote:
>> On 25/01/13 14:10, Ian Campbell wrote:
>> > 26470:acaf29203cf9 "tools+stubdom: install under /usr/local
by
>> > default" moved more stuff under /usr/local than was
desirable.
>> > 
>> > In particular SYSCONFIG_DIR (configuration for initscripts) moved
to
>> > /usr/local/etc/{sysconfig,defaults} while the initscripts
themselves
>> > (correctly) remained in /etc/init.d. Moving /etc/xen/scripts
breaks
>> > the udev bakcned rules file. Lastly stuff under /var was moved to
>> > /usr/local/var.
>> > 
>> > Move these back to /etc/ and /var. Moving /etc wholesale rather
thsn
>> > just the problematic bits is preferable for consistency.
>> > 
>> > Although there seems to be some disagreement about /usr/local/var
vs
>> > /var using /var is compatible with the FHS and what we think most
>> > people will expect.
>> > 
>> > Most of this impacts Linux only but NetBSD appears to have been
using
>> > /usr/local/var/lib which I have also reset to /var/lib.
>> > 
>> > Note that we already paid no attention to autoconf --sysconfdir or
>> > --localstatedir ('etc' and 'var' respectively) so
there is no change
>> > from that PoV.
>> > 
>> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> > Cc: Roger Pau Monne <roger.pau@citrix.com>
>> > Cc: Ian Jackson <ian.jackson@citrix.com?
>> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
> Applied, thanks.
Hmm all the initscripts and the SYSCONFIG_DIR scripts still have hardcoded paths
to /usr/bin or /usr/sbin in them.
Changed them by hand for the moment, but still no succes booting.
Perhaps there are some more places where paths are hardcoded and not derived
from the result of ./configure ?

--

Sander


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

On Sun, 2013-01-27 at 21:49 +0000, Sander Eikelenboom
wrote:
> Friday, January 25, 2013, 5:15:24 PM, you wrote:
> 
> > On Fri, 2013-01-25 at 13:41 +0000, Roger Pau Monne wrote:
> >> On 25/01/13 14:10, Ian Campbell wrote:
> >> > 26470:acaf29203cf9 "tools+stubdom: install under
/usr/local by
> >> > default" moved more stuff under /usr/local than was
desirable.
> >> > 
> >> > In particular SYSCONFIG_DIR (configuration for initscripts)
moved to
> >> > /usr/local/etc/{sysconfig,defaults} while the initscripts
themselves
> >> > (correctly) remained in /etc/init.d. Moving /etc/xen/scripts
breaks
> >> > the udev bakcned rules file. Lastly stuff under /var was
moved to
> >> > /usr/local/var.
> >> > 
> >> > Move these back to /etc/ and /var. Moving /etc wholesale
rather thsn
> >> > just the problematic bits is preferable for consistency.
> >> > 
> >> > Although there seems to be some disagreement about
/usr/local/var vs
> >> > /var using /var is compatible with the FHS and what we think
most
> >> > people will expect.
> >> > 
> >> > Most of this impacts Linux only but NetBSD appears to have
been using
> >> > /usr/local/var/lib which I have also reset to /var/lib.
> >> > 
> >> > Note that we already paid no attention to autoconf
--sysconfdir or
> >> > --localstatedir ('etc' and 'var'
respectively) so there is no change
> >> > from that PoV.
> >> > 
> >> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >> > Cc: Roger Pau Monne <roger.pau@citrix.com>
> >> > Cc: Ian Jackson <ian.jackson@citrix.com?
> >> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> > Applied, thanks.
> 
> Hmm all the initscripts and the SYSCONFIG_DIR scripts still have
> hardcoded paths to /usr/bin or /usr/sbin in them.
Oh, so they do :-(
> Changed them by hand for the moment, but still no succes booting.
> Perhaps there are some more places where paths are hardcoded and not
> derived from the result of ./configure ?
It does seem likely :-/

I think at this point we should revert this change for now and I'll try
again with a bit more due diligence before pushing the change. Sorry
about this.

Ian.


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

Monday, January 28, 2013, 11:25:38 AM, you wrote:
> On Sun, 2013-01-27 at 21:49 +0000, Sander Eikelenboom wrote:
>> Friday, January 25, 2013, 5:15:24 PM, you wrote:
>> 
>> > On Fri, 2013-01-25 at 13:41 +0000, Roger Pau Monne wrote:
>> >> On 25/01/13 14:10, Ian Campbell wrote:
>> >> > 26470:acaf29203cf9 "tools+stubdom: install under
/usr/local by
>> >> > default" moved more stuff under /usr/local than was
desirable.
>> >> > 
>> >> > In particular SYSCONFIG_DIR (configuration for
initscripts) moved to
>> >> > /usr/local/etc/{sysconfig,defaults} while the initscripts
themselves
>> >> > (correctly) remained in /etc/init.d. Moving
/etc/xen/scripts breaks
>> >> > the udev bakcned rules file. Lastly stuff under /var was
moved to
>> >> > /usr/local/var.
>> >> > 
>> >> > Move these back to /etc/ and /var. Moving /etc wholesale
rather thsn
>> >> > just the problematic bits is preferable for consistency.
>> >> > 
>> >> > Although there seems to be some disagreement about
/usr/local/var vs
>> >> > /var using /var is compatible with the FHS and what we
think most
>> >> > people will expect.
>> >> > 
>> >> > Most of this impacts Linux only but NetBSD appears to
have been using
>> >> > /usr/local/var/lib which I have also reset to /var/lib.
>> >> > 
>> >> > Note that we already paid no attention to autoconf
--sysconfdir or
>> >> > --localstatedir ('etc' and 'var'
respectively) so there is no change
>> >> > from that PoV.
>> >> > 
>> >> > Signed-off-by: Ian Campbell
<ian.campbell@citrix.com>
>> >> > Cc: Roger Pau Monne <roger.pau@citrix.com>
>> >> > Cc: Ian Jackson <ian.jackson@citrix.com?
>> >> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
>> 
>> > Applied, thanks.
>> 
>> Hmm all the initscripts and the SYSCONFIG_DIR scripts still have
>> hardcoded paths to /usr/bin or /usr/sbin in them.
> Oh, so they do :-(
It's also a mix with absolute paths, and no paths.

Another thing is that:
        $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv
-daemonize -monitor /dev/null -pidfile $QEMU_PIDFILE

Doesn't seem to start with upstream qemu, combination of -nographic and
-daemonize doesn't seem to be allowed anymore.
(not a problem for me, because i don't seem to be using it as diskbackend,
but for a 4.3 release ...)
>> Changed them by hand for the moment, but still no succes booting.
>> Perhaps there are some more places where paths are hardcoded and not
>> derived from the result of ./configure ?
> It does seem likely :-/
> I think at this point we should revert this change for now and I'll try
> again with a bit more due diligence before pushing the change. Sorry
> about this.
NP, it was worth a shot :-)
> Ian.



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

On Mon, 2013-01-28 at 10:39 +0000, Sander Eikelenboom
wrote:
> 
> 
> Another thing is that:
>         $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M
> xenpv -daemonize -monitor /dev/null -pidfile $QEMU_PIDFILE
> 
> Doesn''t seem to start with upstream qemu, combination of
-nographic
> and -daemonize doesn''t seem to be allowed anymore.
> (not a problem for me, because i don''t seem to be using it as
> diskbackend, but for a 4.3 release ...) 
Stefano, is this expected?

Ian.

On Mon, 28 Jan 2013, Ian Campbell wrote:
> On Mon, 2013-01-28 at 10:39 +0000, Sander Eikelenboom wrote:
> > Another thing is that:
> >         $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M
> > xenpv -daemonize -monitor /dev/null -pidfile $QEMU_PIDFILE
> > 
> > Doesn''t seem to start with upstream qemu, combination of
-nographic
> > and -daemonize doesn''t seem to be allowed anymore.
> > (not a problem for me, because i don''t seem to be using it as
> > diskbackend, but for a 4.3 release ...) 
> 
> Stefano, is this expected?
 
No, it is not. Sander, thanks for the report.
This is the reason:

/* According to documentation and historically, -nographic redirects
 * serial port, parallel port and monitor to stdio, which does not work
 * with -daemonize.  We can redirect these to null instead, but since
 * -nographic is legacy, let''s just error out.
 * We disallow -nographic only if all other ports are not redirected
 * explicitly, to not break existing legacy setups which uses
 * -nographic _and_ redirects all ports explicitly - this is valid
 * usage, -nographic is just a no-op in this case.
 */

If fact it looks like that the appended patch fixes it, can you please
confirm it?

---

diff --git a/tools/hotplug/Linux/init.d/xencommons
b/tools/hotplug/Linux/init.d/xencommons
index cc8177e..dc40425 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -116,7 +116,7 @@ do_start () {
 	test "`uname`" != "NetBSD" || xenbackendd
$XENBACKENDD_ARGS
 	echo Starting QEMU as disk backend for dom0
 	test -z "$QEMU_XEN" &&
QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
-	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize
-monitor /dev/null
+	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize
-monitor /dev/null -serial /dev/null -parallel /dev/null
 }
 do_stop () {
         echo Stopping xenconsoled

Monday, January 28, 2013, 5:49:28 PM, you wrote:
> On Mon, 28 Jan 2013, Ian Campbell wrote:
>> On Mon, 2013-01-28 at 10:39 +0000, Sander Eikelenboom wrote:
>> > Another thing is that:
>> >         $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic
-M
>> > xenpv -daemonize -monitor /dev/null -pidfile $QEMU_PIDFILE
>> > 
>> > Doesn''t seem to start with upstream qemu, combination of
-nographic
>> > and -daemonize doesn''t seem to be allowed anymore.
>> > (not a problem for me, because i don''t seem to be using
it as
>> > diskbackend, but for a 4.3 release ...) 
>> 
>> Stefano, is this expected?
>  
> No, it is not. Sander, thanks for the report.
> This is the reason:
> /* According to documentation and historically, -nographic redirects
>  * serial port, parallel port and monitor to stdio, which does not work
>  * with -daemonize.  We can redirect these to null instead, but since
>  * -nographic is legacy, let''s just error out.
>  * We disallow -nographic only if all other ports are not redirected
>  * explicitly, to not break existing legacy setups which uses
>  * -nographic _and_ redirects all ports explicitly - this is valid
>  * usage, -nographic is just a no-op in this case.
>  */
> If fact it looks like that the appended patch fixes it, can you please
> confirm it?
Confirmed thx !

--
Sander
> ---
> diff --git a/tools/hotplug/Linux/init.d/xencommons
b/tools/hotplug/Linux/init.d/xencommons
> index cc8177e..dc40425 100644
> --- a/tools/hotplug/Linux/init.d/xencommons
> +++ b/tools/hotplug/Linux/init.d/xencommons
> @@ -116,7 +116,7 @@ do_start () {
>         test "`uname`" != "NetBSD" || xenbackendd
$XENBACKENDD_ARGS
>         echo Starting QEMU as disk backend for dom0
>         test -z "$QEMU_XEN" &&
QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
> -       $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv
-daemonize -monitor /dev/null
> +       $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv
-daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null
>  }
>  do_stop () {
>          echo Stopping xenconsoled

Upstream QEMU doesn''t support -nographic with -daemonize unless
monitor,
serial and parallel outputs are all redirected:

/* According to documentation and historically, -nographic redirects
 * serial port, parallel port and monitor to stdio, which does not work
 * with -daemonize.  We can redirect these to null instead, but since
 * -nographic is legacy, let''s just error out.
 * We disallow -nographic only if all other ports are not redirected
 * explicitly, to not break existing legacy setups which uses
 * -nographic _and_ redirects all ports explicitly - this is valid
 * usage, -nographic is just a no-op in this case.
 */

Considering that we do want to redirect them to /dev/null anyway, do so.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>

---

diff --git a/tools/hotplug/Linux/init.d/xencommons
b/tools/hotplug/Linux/init.d/xencommons
index cc8177e..dc40425 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -116,7 +116,7 @@ do_start () {
 	test "`uname`" != "NetBSD" || xenbackendd
$XENBACKENDD_ARGS
 	echo Starting QEMU as disk backend for dom0
 	test -z "$QEMU_XEN" &&
QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
-	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize
-monitor /dev/null
+	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize
-monitor /dev/null -serial /dev/null -parallel /dev/null
 }
 do_stop () {
         echo Stopping xenconsoled

On 28/01/13 18:46, Sander Eikelenboom wrote:
> 
> Monday, January 28, 2013, 5:49:28 PM, you wrote:
> 
>> On Mon, 28 Jan 2013, Ian Campbell wrote:
>>> On Mon, 2013-01-28 at 10:39 +0000, Sander Eikelenboom wrote:
>>>> Another thing is that:
>>>>         $QEMU_XEN -xen-domid 0 -xen-attach -name dom0
-nographic -M
>>>> xenpv -daemonize -monitor /dev/null -pidfile $QEMU_PIDFILE
>>>>
>>>> Doesn''t seem to start with upstream qemu, combination
of -nographic
>>>> and -daemonize doesn''t seem to be allowed anymore.
>>>> (not a problem for me, because i don''t seem to be
using it as
>>>> diskbackend, but for a 4.3 release ...) 
>>>
>>> Stefano, is this expected?
>>  
>> No, it is not. Sander, thanks for the report.
>> This is the reason:
> 
>> /* According to documentation and historically, -nographic redirects
>>  * serial port, parallel port and monitor to stdio, which does not work
>>  * with -daemonize.  We can redirect these to null instead, but since
>>  * -nographic is legacy, let''s just error out.
>>  * We disallow -nographic only if all other ports are not redirected
>>  * explicitly, to not break existing legacy setups which uses
>>  * -nographic _and_ redirects all ports explicitly - this is valid
>>  * usage, -nographic is just a no-op in this case.
>>  */
> 
>> If fact it looks like that the appended patch fixes it, can you please
>> confirm it?
> 
> Confirmed thx !
Running Qemu using the -daemonize and -nographic options used to left
the console tty in a bad state (which could be reverted by using ''stty
sane''). Do you know if this is also fixed?

On Mon, 28 Jan 2013, Roger Pau Monne wrote:
> On 28/01/13 18:46, Sander Eikelenboom wrote:
> > 
> > Monday, January 28, 2013, 5:49:28 PM, you wrote:
> > 
> >> On Mon, 28 Jan 2013, Ian Campbell wrote:
> >>> On Mon, 2013-01-28 at 10:39 +0000, Sander Eikelenboom wrote:
> >>>> Another thing is that:
> >>>>         $QEMU_XEN -xen-domid 0 -xen-attach -name dom0
-nographic -M
> >>>> xenpv -daemonize -monitor /dev/null -pidfile $QEMU_PIDFILE
> >>>>
> >>>> Doesn''t seem to start with upstream qemu,
combination of -nographic
> >>>> and -daemonize doesn''t seem to be allowed
anymore.
> >>>> (not a problem for me, because i don''t seem to be
using it as
> >>>> diskbackend, but for a 4.3 release ...) 
> >>>
> >>> Stefano, is this expected?
> >>  
> >> No, it is not. Sander, thanks for the report.
> >> This is the reason:
> > 
> >> /* According to documentation and historically, -nographic
redirects
> >>  * serial port, parallel port and monitor to stdio, which does not
work
> >>  * with -daemonize.  We can redirect these to null instead, but
since
> >>  * -nographic is legacy, let''s just error out.
> >>  * We disallow -nographic only if all other ports are not
redirected
> >>  * explicitly, to not break existing legacy setups which uses
> >>  * -nographic _and_ redirects all ports explicitly - this is valid
> >>  * usage, -nographic is just a no-op in this case.
> >>  */
> > 
> >> If fact it looks like that the appended patch fixes it, can you
please
> >> confirm it?
> > 
> > Confirmed thx !
> 
> Running Qemu using the -daemonize and -nographic options used to left
> the console tty in a bad state (which could be reverted by using
''stty
> sane''). Do you know if this is also fixed?
Yes, that is fixed in upstream QEMU.

On Mon, 2013-01-28 at 16:49 +0000, Stefano Stabellini
wrote:
> On Mon, 28 Jan 2013, Ian Campbell wrote:
> > On Mon, 2013-01-28 at 10:39 +0000, Sander Eikelenboom wrote:
> > > Another thing is that:
> > >         $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic
-M
> > > xenpv -daemonize -monitor /dev/null -pidfile $QEMU_PIDFILE
> > > 
> > > Doesn''t seem to start with upstream qemu, combination of
-nographic
> > > and -daemonize doesn''t seem to be allowed anymore.
> > > (not a problem for me, because i don''t seem to be using
it as
> > > diskbackend, but for a 4.3 release ...) 
> > 
> > Stefano, is this expected?
>  
> No, it is not. Sander, thanks for the report.
> This is the reason:
> 
> /* According to documentation and historically, -nographic redirects
>  * serial port, parallel port and monitor to stdio, which does not work
>  * with -daemonize.  We can redirect these to null instead, but since
>  * -nographic is legacy, let''s just error out.
>  * We disallow -nographic only if all other ports are not redirected
>  * explicitly, to not break existing legacy setups which uses
>  * -nographic _and_ redirects all ports explicitly - this is valid
>  * usage, -nographic is just a no-op in this case.
>  */
> 
> If fact it looks like that the appended patch fixes it, can you please
> confirm it?
Is this going to break people using older versions of upstream qemu or
should this change be compatible?

Ian.

On Tue, 29 Jan 2013, Ian Campbell wrote:
> On Mon, 2013-01-28 at 16:49 +0000, Stefano Stabellini wrote:
> > On Mon, 28 Jan 2013, Ian Campbell wrote:
> > > On Mon, 2013-01-28 at 10:39 +0000, Sander Eikelenboom wrote:
> > > > Another thing is that:
> > > >         $QEMU_XEN -xen-domid 0 -xen-attach -name dom0
-nographic -M
> > > > xenpv -daemonize -monitor /dev/null -pidfile $QEMU_PIDFILE
> > > > 
> > > > Doesn''t seem to start with upstream qemu,
combination of -nographic
> > > > and -daemonize doesn''t seem to be allowed anymore.
> > > > (not a problem for me, because i don''t seem to be
using it as
> > > > diskbackend, but for a 4.3 release ...) 
> > > 
> > > Stefano, is this expected?
> >  
> > No, it is not. Sander, thanks for the report.
> > This is the reason:
> > 
> > /* According to documentation and historically, -nographic redirects
> >  * serial port, parallel port and monitor to stdio, which does not
work
> >  * with -daemonize.  We can redirect these to null instead, but since
> >  * -nographic is legacy, let''s just error out.
> >  * We disallow -nographic only if all other ports are not redirected
> >  * explicitly, to not break existing legacy setups which uses
> >  * -nographic _and_ redirects all ports explicitly - this is valid
> >  * usage, -nographic is just a no-op in this case.
> >  */
> > 
> > If fact it looks like that the appended patch fixes it, can you please
> > confirm it?
> 
> Is this going to break people using older versions of upstream qemu or
> should this change be compatible?
They are compatible

On Mon, 2013-01-28 at 18:48 +0000, Stefano Stabellini
wrote:
> Upstream QEMU doesn''t support -nographic with -daemonize unless
monitor,
> serial and parallel outputs are all redirected:
> 
> /* According to documentation and historically, -nographic redirects
>  * serial port, parallel port and monitor to stdio, which does not work
>  * with -daemonize.  We can redirect these to null instead, but since
>  * -nographic is legacy, let''s just error out.
>  * We disallow -nographic only if all other ports are not redirected
>  * explicitly, to not break existing legacy setups which uses
>  * -nographic _and_ redirects all ports explicitly - this is valid
>  * usage, -nographic is just a no-op in this case.
>  */
> 
> Considering that we do want to redirect them to /dev/null anyway, do so.
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
I think I asked you IRL if this would work with older QEMU too and IIRC
you said yes, so :
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied, I had to adjust because of 26352:9a1610c1e564 "xencommons: Stop
QEMU in do_stop()" and I rewrapped it since the line was getting a bit
ridiculous, let me know if I did it wrong...