Re: [PATCH 03 of 30] tools: vnet: Remove

Re: [PATCH 03 of 30] tools: vnet: Remove

[Ian Jackson]

Ian Campbell writes ("[PATCH 03 of 30] tools: vnet: Remove"):
> tools: vnet: Remove

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

For reasons I don't understand, this doesn't seem to apply to my tree.
I get a lot of:
Reversed (or previously applied) patch detected!  Assume -R? [n] 

Ian.

Re: [PATCH 03 of 30] tools: vnet: Remove

[Ian Campbell]

On Mon, 2011-03-21 at 17:42 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 03 of 30] tools: vnet: Remove"):
> > tools: vnet: Remove
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> For reasons I don't understand, this doesn't seem to apply to my tree.
> I get a lot of:
> Reversed (or previously applied) patch detected!  Assume -R? [n] 

Under tools/vnet I presume? How odd. Nothing in "hg incoming" looks
likely to have caused anything along those lines. The last patch to
touch it was "Make XEN_ROOT an absolute path." from last week

Do you want me to regenerate and resend tomorrow or are you happy to
just run the obvious "hg rm" rune during commit?

Ian.

Re: [PATCH 03 of 30] tools: vnet: Remove

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 03 of 30] tools: vnet: Remove"):
> Do you want me to regenerate and resend tomorrow or are you happy to
> just run the obvious "hg rm" rune during commit?

Is it as simple as deleting the tools/vnet directory ?  AFAICT it's
not referred to from tools/Makefile any more so I guess so.

Ian.

Re: [PATCH 03 of 30] tools: vnet: Remove

[Ian Campbell]

On Thu, 2011-03-31 at 18:08 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 03 of 30] tools: vnet: Remove"):
> > Do you want me to regenerate and resend tomorrow or are you happy to
> > just run the obvious "hg rm" rune during commit?
> 
> Is it as simple as deleting the tools/vnet directory ?  AFAICT it's
> not referred to from tools/Makefile any more so I guess so.

There is some stuff not under tools/vnet (the xend bits) but if all your
rejects are under tools/vnet it is safe to just hg rm whatever remains
after applying the patch.

Ian.

Re: Re: [PATCH 03 of 30] tools: vnet: Remove

[Keir Fraser]

On 01/04/2011 11:21, "Ian Campbell" <Ian.Campbell@eu.citrix.com> wrote:

> On Thu, 2011-03-31 at 18:08 +0100, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [PATCH 03 of 30] tools: vnet: Remove"):
>>> Do you want me to regenerate and resend tomorrow or are you happy to
>>> just run the obvious "hg rm" rune during commit?
>> 
>> Is it as simple as deleting the tools/vnet directory ?  AFAICT it's
>> not referred to from tools/Makefile any more so I guess so.
> 
> There is some stuff not under tools/vnet (the xend bits) but if all your
> rejects are under tools/vnet it is safe to just hg rm whatever remains
> after applying the patch.

I already did the deleting last Friday. :-)

 -- Keir

> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH 20 of 30] tools: ocaml: push CFLAGS usage down into the specific bindings

[Ian Jackson]

Ian Campbell writes ("[PATCH 20 of 30] tools: ocaml: push CFLAGS usage down into the specific bindings"):
> -
> -#ifndef xen_mb
> -#define xen_mb()	mb()
> -#endif

This may be unneeded (I haven't checked) but if so shouldn't it be
mentioned in the commit message ?

> -#xs.cmxa: $(foreach obj,$(OBJS),$(obj).cmx)
etc.

Also.

Ian.

Re: [PATCH 20 of 30] tools: ocaml: push CFLAGS usage down into the specific bindings

[Ian Campbell]

On Wed, 2011-03-23 at 15:40 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 20 of 30] tools: ocaml: push CFLAGS usage down into the specific bindings"):
> > -
> > -#ifndef xen_mb
> > -#define xen_mb()	mb()
> > -#endif
> 
> This may be unneeded (I haven't checked) but if so shouldn't it be
> mentioned in the commit message ?
> 
> > -#xs.cmxa: $(foreach obj,$(OBJS),$(obj).cmx)
> etc.
> 
> Also.

Sorry, they both should have been separate patches. I'll wait till
you've applied the bits you are going to apply and then resend the bits
you didn't.

Ian.

Re: [PATCH 24 of 30] tools: Remove $(CFLAGS) from links lines

[Ian Jackson]

Ian Campbell writes ("[PATCH 24 of 30] tools: Remove $(CFLAGS) from links lines"):
> tools: Remove $(CFLAGS) from links lines.

I get a lot of rejects from this one.

Ian.

Re: [PATCH 25 of 30] libxl: move libxl_doimid_valid_guest out of line

[Ian Jackson]

Ian Campbell writes ("[PATCH 25 of 30] libxl: move libxl_doimid_valid_guest out of line"):
> libxl: move libxl_doimid_valid_guest out of line

Why ?

Ian.

Re: [PATCH 25 of 30] libxl: move libxl_doimid_valid_guest out of line

[Ian Campbell]

On Wed, 2011-03-23 at 15:52 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 25 of 30] libxl: move libxl_doimid_valid_guest out of line"):
> > libxl: move libxl_doimid_valid_guest out of line
> 
> Why ?

Why should it be inline?

What actually led to the changes was that a subsequent patch removed the
indirect dependency which defined DOMID_FIRST_RESERVED. Rather than
finding and adding the appropriate xen header to libxl.h (which is a
valid option) I decided that the function shouldn't have been inline in
the first place...

Ian.

Re: [PATCH 25 of 30] libxl: move libxl_doimid_valid_guest out of line

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 25 of 30] libxl: move libxl_doimid_valid_guest out of line"):
> Why should it be inline?

In general, I think it's fine to have trivial operations like this
inlined.  Things which one would otherwise maybe use a macro for.

> What actually led to the changes was that a subsequent patch removed the
> indirect dependency which defined DOMID_FIRST_RESERVED. Rather than
> finding and adding the appropriate xen header to libxl.h (which is a
> valid option) I decided that the function shouldn't have been inline in
> the first place...

I think it's fine to import Xen headers into libxl.h.

Ian.

Re: [PATCH 25 of 30] libxl: move libxl_doimid_valid_guest out of line

[Ian Campbell]

On Wed, 2011-03-23 at 16:57 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 25 of 30] libxl: move libxl_doimid_valid_guest out of line"):
> > Why should it be inline?
> 
> In general, I think it's fine to have trivial operations like this
> inlined.  Things which one would otherwise maybe use a macro for.
> 
> > What actually led to the changes was that a subsequent patch removed the
> > indirect dependency which defined DOMID_FIRST_RESERVED. Rather than
> > finding and adding the appropriate xen header to libxl.h (which is a
> > valid option) I decided that the function shouldn't have been inline in
> > the first place...
> 
> I think it's fine to import Xen headers into libxl.h.

In any case whatever it was which caused me to do this is not present in
the final series I ended up sending and neither this patch nor any
additional #includes are required AFAICT.

Ian.

Re: [PATCH 28 of 30] libxl: do not expose libxenctrl/libxenstore headers via libxl.h

[Ian Jackson]

Ian Campbell writes ("[PATCH 28 of 30] libxl: do not expose libxenctrl/libxenstore headers	via libxl.h"):
> libxl: do not expose libxenctrl/libxenstore headers via libxl.h

Doesn't apply to my current tip (but that could be because of earlier
patches not being applied).

Ian.

Re: [PATCH 30 of 30] tools: remove pattern matched linking rules

[Ian Jackson]

Ian Campbell writes ("[PATCH 30 of 30] tools: remove pattern matched linking rules"):
> tools: remove pattern matched linking rules

This one doesn't apply any more either.

I think I've now either acked, committed and applied, or commented on,
every patch in this series, thanks :-).

Ian.

Re: [PATCH 30 of 30] tools: remove pattern matched linking rules

[Ian Campbell]

On Wed, 2011-03-23 at 16:01 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 30 of 30] tools: remove pattern matched linking rules"):
> > tools: remove pattern matched linking rules
> 
> This one doesn't apply any more either.
> 
> I think I've now either acked, committed and applied, or commented on,
> every patch in this series, thanks :-).

I'll rebase the remainder, address your comments and resend. Thanks.

Ian.

[PATCH 00 of 30] tools: shave build yaks

[Ian Campbell]

Clean up a bunch of inconsistency, wierdness, cut-and-paste etc in the
tools/ build system. All in all it's a bit of a grab bag of stuff I
happened to notice as I was trawling 

One specific useful thing which comes out of it is to isolate users of
libxl from needing to know about libxenstore or libxenctrl.

[PATCH 25 of 30] libxl: move libxl_doimid_valid_guest out of line

[Ian Campbell]

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1300718506 0
# Node ID 825082d71dd594e0eee41a4cb3b8006ea9e31451
# Parent  83ba7f8b634d542fea896ab16ce3f80220d14cb1
libxl: move libxl_doimid_valid_guest out of line

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 83ba7f8b634d -r 825082d71dd5 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Mar 21 14:41:46 2011 +0000
+++ b/tools/libxl/libxl.h	Mon Mar 21 14:41:46 2011 +0000
@@ -561,12 +561,7 @@ int libxl_cpupool_cpuremove_node(libxl_c
 int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus);
 int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid);
 
-static inline int libxl_domid_valid_guest(uint32_t domid)
-{
-    /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
-     * does not check whether the domain actually exists */
-    return domid > 0 && domid < DOMID_FIRST_RESERVED;
-}
+int libxl_domid_valid_guest(uint32_t domid);
 
 /* common paths */
 const char *libxl_sbindir_path(void);
diff -r 83ba7f8b634d -r 825082d71dd5 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Mon Mar 21 14:41:46 2011 +0000
+++ b/tools/libxl/libxl_utils.c	Mon Mar 21 14:41:46 2011 +0000
@@ -55,6 +55,13 @@ const char *libxl_basename(const char *n
     if (filename)
         return strdup(filename+1);
     return strdup(name);
+}
+
+int libxl_domid_valid_guest(uint32_t domid)
+{
+    /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
+     * does not check whether the domain actually exists */
+    return domid > 0 && domid < DOMID_FIRST_RESERVED;
 }
 
 unsigned long libxl_get_required_shadow_memory(unsigned long maxmem_kb, unsigned int smp_cpus)