Xen devel - Nov 2009 - [PATCH] xapi toolstack (xen-api-libs): fix compile errors

Hello!

There are two compile errors when ''make allxen'' in
xen-api-libs.

o XS_RESTRICT is not defined (c compiler error)
o xb.mli file was checked in (ocaml error)

The attached patch should remove those problems.

Kind regards - Andreas



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

Hi Andreas,

XS_RESTRICT is defined in this Xen patch-queue:
http://xenbits.xen.org/xapi/xen-3.4.pq.hg?file/c01d38e7092a/restrict_xenstored

Basically, it is used by xapi/oxenstored to drop the xenstore permissions of
qemu inside dom0. This gives to qemu processes the same permissions than their
associated domU concerning read/write of xenstore nodes. It is quite useful to
avoid any security issue with qemu backends.

Because of that, your patch will broke the starting of HVM domains for XCP. I
believe the best fix for this is to upstream our Xen patch-queue :-) and in a
more practical way, I believe we should do something like:
1. Add a #define XS_RESTRICT in
http://xenbits.xen.org/xapi/xen-3.4.pq.hg?file/c01d38e7092a/restrict_xenstored
2. In xen-api-libs.hg/xb/xb_stubs.c, test if XS_RESTRICT is defined. If yes, use
the value if XS_RESTRICT, else use a default value (128, as defined in the patch
queue, for example).

About xb.mli file: it is supposed to be the exposed interface, which contains
some bits of documentation, so it cannot be auto-generated. Thus, it would be
better to not remove it.

Cheers,
Thomas


> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Andreas Florath
> Sent: Friday, November 06, 2009 12:51 PM
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] xapi toolstack (xen-api-libs): fix compile
> errors
> 
> Hello!
> 
> There are two compile errors when ''make allxen'' in
xen-api-libs.
> 
> o XS_RESTRICT is not defined (c compiler error) o xb.mli file was checked
> in (ocaml error)
> 
> The attached patch should remove those problems.
> 
> Kind regards - Andreas

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-api

Hello!

One part of the patch is not correct:
The ''stub_get_internal_offset'' is used in the xen-api. Sorry
for this!
(IMHO the other part - e.g. removing the xb.mli makes sense.)

But:

Then there is the problem of the undefined symbol XS_RESTRICT.

I had a closer look at this and found, that there are (at least) three
different definitions of xsd_sockmsg_type in the current XEN source.
o ./linux-2.6-pvops.git/include/xen/interface/io/xs_wire.h
   18 entries; tail is:
     XS_WATCH_EVENT,
     XS_ERROR,
     XS_IS_DOMAIN_INTRODUCED
o ./xen/include/public/io/xs_wire.h (which IMHO is used in the xc-lib)
   20 entries; tail is:
     XS_WATCH_EVENT,
     XS_ERROR,
     XS_IS_DOMAIN_INTRODUCED,
     XS_RESUME,
     XS_SET_TARGET
o xen-api-libs.hg/xb/op.ml:
   21 entries; tail is:
	| Watchevent		-> "WATCH_EVENT"
	| Error			-> "ERROR"
	| Isintroduced		-> "IS_INTRODUCED"
	| Resume		-> "RESUME"
	| Set_target		-> "SET_TARGET"
	| Restrict		-> "RESTRICT"
o Additionally there is a relict (??) [1]:
   20 entries; tail is
     XS_WATCH_EVENT,
     XS_ERROR,
     XS_IS_DOMAIN_INTRODUCED,
     XS_RESUME,
     XS_RESTRICT

I''m a little bit confused - can anybody please tell me which is the
correct set?  Why are there differences (i.e. why differs the linux  
pvops kernel one from the xc one)?  Is there a XS_RESTRICT or not?

Kind regards - Andreas Florath


[1]  
http://lists.xensource.com/archives/cgi-bin/extract-mesg.cgi?a=xen-devel&m=2008-05&i=1209573173.32716.62.camel%40zakaz.uk.xensource.com


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

Hello Thomas,

looks that our mails crossed in time.

Thanks for your answer about the XS_RESTRICT.  It answers my questions  
from the other mail.
> XS_RESTRICT is defined in this Xen patch-queue:
Does this mean, that the xen-api toolchain does not work (compile)  
with xen-unstable or some currently released Xen?  Does it only  
compile with some Citrix internal available source?
> About xb.mli file: it is supposed to be the exposed interface ...
Yes - you are right - there are comments in this file.

But I''m not sure if this is the best place for comments. IMHO when  
somebody changes the xb.ml file, the xb.mli file will be overwritten;  
see Makefile:
%.mli: %.ml
         $(OCAMLC) -i $< > $@

Who will re-add the comments?

I think it would be better here to have a separate file for the  
comments and let the mli file be created automatically.

To reproduce my original problem:
make && make allxen && emacs xb/xb_stubs.c

Replace XS_REPLACE with 128

Then ''make allxen'' prints:
File "xb.ml", line 1, characters 0-1:
Error: The files op.cmi and xb.cmi make inconsistent assumptions
        over interface Op

A ''touch xb/xb.mli && make allxen'' works.

IMHO this is because of missing dependencies in the Makefile. Try to  
add one additional operation in op.ml and type ''make''.
You''ll see a
similar error. It looks that dependency tracking is missing:
Example: xb.ml uses op.ml but it is not rebuild when op.ml changes.

Kind regards - Andreas



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

Andreas wrote:
> Does this mean, that the xen-api toolchain does not work (compile)  
> with xen-unstable or some currently released Xen?  Does it only  
> compile with some Citrix internal available source?
It only currently compiles with this xen patchqueue applied:

http://xenbits.xen.org/xapi/xen-3.4.pq.hg
(applied to the tag RELEASE-3.4.1 in xen-3.4-testing.hg)

We haven't done any recent testing against xen-unstable... but we probably
should! Perhaps we could fix this XS_RESTRICT problem with some #ifdef magic for
the time-being.

We're keen to get rid of these patchqueues but it will take some time.
> But I'm not sure if this is the best place for comments. IMHO when  
> somebody changes the xb.ml file, the xb.mli file will be overwritten;  
> see Makefile:
> %.mli: %.ml
>         $(OCAMLC) -i $< > $@
Oops :) 
We've been trying to add ocamldoc comments to .mli files which we can use to
generate stuff like:
  http://www.xen.org/files/XenCloud/ocamldoc/

I think we should zap this Makefile rule and keep our comments. 
> Then 'make allxen' prints:
> File "xb.ml", line 1, characters 0-1:
> Error: The files op.cmi and xb.cmi make inconsistent assumptions
>        over interface Op
>
> A 'touch xb/xb.mli && make allxen' works.
> 
> IMHO this is because of missing dependencies in the Makefile. Try to  
> add one additional operation in op.ml and type 'make'. You'll
see a
> similar error. It looks that dependency tracking is missing:
> Example: xb.ml uses op.ml but it is not rebuild when op.ml changes.
I'm sure you're right. We've been a bit lazy with our dependencies
in this repo, falling back to 'make clean && make'. Things are
better in xen-api.hg where 'omake' (like 'make' but with a bit
more ocaml-awareness) is quite good at tracking dependencies itself.

Cheers,
Dave

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-api

On 6 Nov 2009, at 09:16, Dave Scott wrote:
>
> Andreas wrote:
>> Does this mean, that the xen-api toolchain does not work (compile)
>> with xen-unstable or some currently released Xen?  Does it only
>> compile with some Citrix internal available source?
>
> It only currently compiles with this xen patchqueue applied:
>
> http://xenbits.xen.org/xapi/xen-3.4.pq.hg
> (applied to the tag RELEASE-3.4.1 in xen-3.4-testing.hg)
>
> We haven''t done any recent testing against xen-unstable... but we
> probably should! Perhaps we could fix this XS_RESTRICT problem with  
> some #ifdef magic for the time-being.
It might be easier to just integrate autoconf in with the OCaml m4  
macros, and use its header checking and AC_SUBST for this sort of  
thing.  I have the m4 stuff in my local xen-api-libs tree to deselect  
the stuff that will never compile on MacOS except for the fakeserver,  
so could clean that up at some point if you want...

-anil

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

Dave wrote:
> > We haven''t done any recent testing against xen-unstable...
but we
> > probably should! Perhaps we could fix this XS_RESTRICT problem with  
> > some #ifdef magic for the time-being.
Anil replied:
> It might be easier to just integrate autoconf in with the OCaml m4  
> macros, and use its header checking and AC_SUBST for this sort of  
> thing.  I have the m4 stuff in my local xen-api-libs tree to deselect  
> the stuff that will never compile on MacOS except for the fakeserver,  
> so could clean that up at some point if you want...
That sounds useful -- could you knock up a patch and send it over?

Cheers,
Dave

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