caml stubdom crashes

caml stubdom crashes

[Alex Zeffertt]

Hello ocaml minios stubdomain experts (that's narrowed down the list somewhat!)

I've been playing with the caml version of the "hello world" example stubdomain 
that can be found in xen-unstable.hg/stubdom/caml/.

If I make the following trivial modification to stubdom/caml/hello.ml the stub 
domain page faults.  According to addr2line the page fault is in ungetc.c:0.

--- a/stubdom/caml/hello.ml	Mon Mar 30 11:42:16 2009 +0100
+++ b/stubdom/caml/hello.ml	Thu Apr 02 15:15:45 2009 +0100
@@ -1,4 +1,6 @@
+let yr = 2009
+
  let main arg =
-  Printf.printf "Hello, world!\n%!."
+  Printf.printf "Hello, world %d!\n%!." yr

  let _ = Callback.register "main" main


Without the above change the stub domain runs as expected, i.e. it does not page 
fault.

I suspect the problem is that the caml-stubdom target in stubdom/caml/Makefile 
compiles stubdom/caml/hello.ml and links it with $(CAMLLIB)/libasmrun.a.  But 
this is a library compiled for the development machine platform 
(linux-i386-glibc) not for the stubdomain platform (minios-i386-newlib).

Maybe the original hello.ml only worked through luck, and the fact that it used 
so very little of the ocaml language.

In order to run a non trivial ocaml application in a stubdomain (e.g. ocaml 
xenstored) do I need to port ocaml to minios-i386-newlib?

If so, I would really appreciate any pointers(*) on how to go about this as I am 
  an ocaml newbie.

Regards,

Alex

(*) Although I understand you don't get pointers in ocaml.  They would make it 
too easy to do what you want to do, which is probably the wrong thing.  :)

Re: caml stubdom crashes

[Patrick Colp]

Alex Zeffertt wrote:
> Hello ocaml minios stubdomain experts (that's narrowed down the list 
> somewhat!)
> 
> I've been playing with the caml version of the "hello world" example 
> stubdomain that can be found in xen-unstable.hg/stubdom/caml/.
> 
> If I make the following trivial modification to stubdom/caml/hello.ml 
> the stub domain page faults.  According to addr2line the page fault is 
> in ungetc.c:0.
> 
> --- a/stubdom/caml/hello.ml    Mon Mar 30 11:42:16 2009 +0100
> +++ b/stubdom/caml/hello.ml    Thu Apr 02 15:15:45 2009 +0100
> @@ -1,4 +1,6 @@
> +let yr = 2009
> +
>  let main arg =
> -  Printf.printf "Hello, world!\n%!."
> +  Printf.printf "Hello, world %d!\n%!." yr
> 
>  let _ = Callback.register "main" main
> 
> 
> Without the above change the stub domain runs as expected, i.e. it does 
> not page fault.
> 
> I suspect the problem is that the caml-stubdom target in 
> stubdom/caml/Makefile compiles stubdom/caml/hello.ml and links it with 
> $(CAMLLIB)/libasmrun.a.  But this is a library compiled for the 
> development machine platform (linux-i386-glibc) not for the stubdomain 
> platform (minios-i386-newlib).
> 
> Maybe the original hello.ml only worked through luck, and the fact that 
> it used so very little of the ocaml language.

What environment did you use to compile the stubdom? I tried using Ubuntu 
with George Coker's patch and got the same result as you (page faulting). 
Interestingly, I could use a %s and a string and that seems to work OK, but 
not %d with an int.

When I instead used Debian to compile the stubdom (which requires no 
patch), then I could compile and run your code just fine (no page faults). 
Maybe this is the problem you're having?


> In order to run a non trivial ocaml application in a stubdomain (e.g. 
> ocaml xenstored) do I need to port ocaml to minios-i386-newlib?

No, it should be possible as is. In fact, I've gotten my OCaml XenStore to 
run in a caml-stubdom (compiled in a Debian domain).

I'll soon be releasing a patch against the recently released disaggregated 
C xenstored stuff that uses my OCaml XenStore in a caml-stubdom instead.


Patrick

Re: caml stubdom crashes

[George S. Coker, II]

On 4/2/09 12:22 PM, "Patrick Colp" <pjcolp@cs.ubc.ca> wrote:

> Alex Zeffertt wrote:
>> Hello ocaml minios stubdomain experts (that's narrowed down the list
>> somewhat!)
>> 
>> I've been playing with the caml version of the "hello world" example
>> stubdomain that can be found in xen-unstable.hg/stubdom/caml/.
>> 
>> If I make the following trivial modification to stubdom/caml/hello.ml
>> the stub domain page faults.  According to addr2line the page fault is
>> in ungetc.c:0.
>> 
>> --- a/stubdom/caml/hello.ml    Mon Mar 30 11:42:16 2009 +0100
>> +++ b/stubdom/caml/hello.ml    Thu Apr 02 15:15:45 2009 +0100
>> @@ -1,4 +1,6 @@
>> +let yr = 2009
>> +
>>  let main arg =
>> -  Printf.printf "Hello, world!\n%!."
>> +  Printf.printf "Hello, world %d!\n%!." yr
>> 
>>  let _ = Callback.register "main" main
>> 
>> 
>> Without the above change the stub domain runs as expected, i.e. it does
>> not page fault.
>> 
>> I suspect the problem is that the caml-stubdom target in
>> stubdom/caml/Makefile compiles stubdom/caml/hello.ml and links it with
>> $(CAMLLIB)/libasmrun.a.  But this is a library compiled for the
>> development machine platform (linux-i386-glibc) not for the stubdomain
>> platform (minios-i386-newlib).
>>

I don't think this is a linux-i386-glibc vs minios-i386-newlib issue but
rather the FORTIFY compiler options that introduce the
__fprintf_chk/__sprintf_chk funcs.  There is still something about the
behavior of the FORTIFY options that I am still not accounting for.  As
Patrick points out, special ports of ocaml should not be (and have not been)
necessary.
 
>> Maybe the original hello.ml only worked through luck, and the fact that
>> it used so very little of the ocaml language.
> 
> What environment did you use to compile the stubdom? I tried using Ubuntu
> with George Coker's patch and got the same result as you (page faulting).
> Interestingly, I could use a %s and a string and that seems to work OK, but
> not %d with an int.
> 
> When I instead used Debian to compile the stubdom (which requires no
> patch), then I could compile and run your code just fine (no page faults).
> Maybe this is the problem you're having?
> 
> 
>> In order to run a non trivial ocaml application in a stubdomain (e.g.
>> ocaml xenstored) do I need to port ocaml to minios-i386-newlib?
> 
> No, it should be possible as is. In fact, I've gotten my OCaml XenStore to
> run in a caml-stubdom (compiled in a Debian domain).
> 
> I'll soon be releasing a patch against the recently released disaggregated
> C xenstored stuff that uses my OCaml XenStore in a caml-stubdom instead.
> 
> 
> Patrick

-- 
George S. Coker, II <gscoker@alpha.ncsc.mil>

ocaml?? why?? (was: caml stubdom crashes)

[Dan Magenheimer]

At the recent summit, I know I wasn't the only one concerned
about the rise of ocaml as a critical language/tool in the
Xen development world, but I guess I'll be the sacrificial
lamb that starts the discussion, prompted by the thread
about stubdom crashes.

Why ocaml?  Let me make it clear that I know very little
about ocaml... it may be a perfect match for the job and
the best language since sliced bread, but as far as I can
tell it is NOT A WIDELY DEPLOYED language.  As a result,
the Xen community is going to have to work through all
of the little distro/version-dependent idiosyncracies and
bugs that are long since worked through in many other
languages.  That scares me.  I'm happy to learn a new
language... I'm NOT happy to learn how to debug a new
compiler/runtime.

In other words, it may be a very fine academic/research
language... but do we really want enterprise customers'
critical workloads dependent on it?

Okay, the elephant/camel is on the table.  Commence firing.

Dan

Re: ocaml?? why?? (was: caml stubdom crashes)

[Samuel Thibault]

Dan Magenheimer, le Thu 02 Apr 2009 12:39:04 -0700, a écrit :
> In other words, it may be a very fine academic/research
> language... but do we really want enterprise customers'
> critical workloads dependent on it?

They already do: XenEnterprise is mostly implemented in ocaml.  No
problem so far with the language itself.  Personally, the fact that the
ocaml compiler is itself written in ocaml (typesafe blablabla language)
makes me trust it more that any gcc compiler.

Samuel

RE: ocaml?? why?? (was: caml stubdom crashes)

[Dan Magenheimer]

> They already do: XenEnterprise is mostly implemented in ocaml.

Well, I suppose that's a good datapoint.  I wonder if the world's
supply of ocaml programmers all work for Citrix/Xensource. ;-)

But I'd question whether one good datapoint in a controlled
single-product single-company focused startup environment
is a good representation of the problems that might occur
in a broader (e.g. open source) bazaar.

> No problem so far with the language itself. 

This would seem to disagree with *No* problems.
http://cufp.galois.com/2008/slides/MadhavapeddyAnil.pdf

> -----Original Message-----
> From: Samuel Thibault [mailto:samuel.thibault@ens-lyon.org]
> Sent: Thursday, April 02, 2009 3:38 PM
> To: Dan Magenheimer
> Cc: xen-devel; Patrick Colp; Alex Zeffertt; George S. Coker, 
> II; Samuel
> Thibault
> Subject: Re: ocaml?? why?? (was: [Xen-devel] caml stubdom crashes)
> 
> 
> Dan Magenheimer, le Thu 02 Apr 2009 12:39:04 -0700, a écrit :
> > In other words, it may be a very fine academic/research
> > language... but do we really want enterprise customers'
> > critical workloads dependent on it?
> 
> They already do: XenEnterprise is mostly implemented in ocaml.  No
> problem so far with the language itself.  Personally, the 
> fact that the
> ocaml compiler is itself written in ocaml (typesafe blablabla 
> language)
> makes me trust it more that any gcc compiler.
> 
> Samuel
>

Re: ocaml?? why?? (was: caml stubdom crashes)

[Samuel Thibault]

Dan Magenheimer, le Thu 02 Apr 2009 15:13:39 -0700, a écrit :
> > No problem so far with the language itself. 
> 
> This would seem to disagree with *No* problems.
> http://cufp.galois.com/2008/slides/MadhavapeddyAnil.pdf

Right, I was exaggerating, but from the slides I mostly read as a kind
of "bugs"

Supportability:
- Memory usage tracing
- ExceptionHandling
- Tracing and Logging

which is about the same with any highlevel language.

Personally I do not really care about the choice of the language, I
could learn haskell for instance.  It just happens that I already
had tinkered with embedding libcamlrun.a in a small kernel (see the
funk project on gna) so it was quite easy for me to write support for
ocaml-based stubdomains.  Contributions are welcome to do the same for
any other highlevel language ;)

Samuel

RE: ocaml?? why?? (was: caml stubdom crashes)

[Ian Pratt]

> > They already do: XenEnterprise is mostly implemented in ocaml.
> 
> Well, I suppose that's a good datapoint.  I wonder if the world's
> supply of ocaml programmers all work for Citrix/Xensource. ;-)

Microsoft Visual Studio 2008 includes an F# compiler, and I think you'll see Microsoft pushing f# quite heavily over the coming years as a next generation programming language. 

F# is to first approximation OCAML with slightly changed syntax. Rumour has it that the Microsoft F# compiler has a mode where it will even accept plain OCAML... 

Anyhow, I think we're just a bit ahead of the general adoption curve on this one.
 
As regards finding OCAML programmers, many European Universities teach OCAML/ML and have done for many years. Besides, I wouldn't dream of hiring anyone who couldn't become proficient in a new programming language in a couple of weeks just by looking at some existing source code. Beyond XenSource/Citrix there are a bunch of other companies using OCAML in a number of industries, particularly financial. 

It was a big risk when XenSource decided to adopt OCAML back in 2005, but the experience has been very positive and has undoubtedly improved code quality and accelerated development. The tool chain has proved to be remarkably stable -- about par as regards our experience with code generation bugs in gcc over the same period, and certainly the language is a _lot_ more stable as regards compiler warnings -Werror etc. 

Anyhow, I've been converted from an OCAML sceptic, to a "go ahead and use it where it makes sense". I'd be happy to see OCAML in the main xen tree -- in fact there's already quite a bit in the XenClient tree. 

Have a go writing some code and see how you like it in practice.

Ian


> But I'd question whether one good datapoint in a controlled
> single-product single-company focused startup environment
> is a good representation of the problems that might occur
> in a broader (e.g. open source) bazaar.
> 
> > No problem so far with the language itself.
> 
> This would seem to disagree with *No* problems.
> http://cufp.galois.com/2008/slides/MadhavapeddyAnil.pdf
> 
> > -----Original Message-----
> > From: Samuel Thibault [mailto:samuel.thibault@ens-lyon.org]
> > Sent: Thursday, April 02, 2009 3:38 PM
> > To: Dan Magenheimer
> > Cc: xen-devel; Patrick Colp; Alex Zeffertt; George S. Coker,
> > II; Samuel
> > Thibault
> > Subject: Re: ocaml?? why?? (was: [Xen-devel] caml stubdom crashes)
> >
> >
> > Dan Magenheimer, le Thu 02 Apr 2009 12:39:04 -0700, a écrit :
> > > In other words, it may be a very fine academic/research
> > > language... but do we really want enterprise customers'
> > > critical workloads dependent on it?
> >
> > They already do: XenEnterprise is mostly implemented in ocaml.  No
> > problem so far with the language itself.  Personally, the
> > fact that the
> > ocaml compiler is itself written in ocaml (typesafe blablabla
> > language)
> > makes me trust it more that any gcc compiler.
> >
> > Samuel
> >
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

RE: ocaml?? why?? (was: caml stubdom crashes)

[Dan Magenheimer]

> Besides, I wouldn't dream of hiring anyone who couldn't 
> become proficient in a new programming language in a couple 
> of weeks just by looking at some existing source code.

I'm just pointing out that the open source community
is a good deal dependent on developers who are less
than the creme de la creme.  There's many who you (or
I) might not hire that could make a valuable contribution
to an open source project, and might (would!) get scared
away by a completely unfamiliar language... especially
one they've previously never heard of!

> Anyhow, I think we're just a bit ahead of the general 
> adoption curve on this one.

Indeed!  The following websites would imply "well ahead"
rather than "a bit ahead":

http://www.complang.tuwien.ac.at/anton/comp.lang-statistics/
http://www.langpop.com/

On the latter, at least ocaml has passed Lua(??) and is
catching up with assembly and smalltalk!

If ocaml (or haskell or F# or the sum of ALL functional
languages) grows exponentially, no problem.  If it turns
out to be a fad (or even just grows linearly), having
a huge base of code could be a significant albatross for
the future of Xen.  I wonder what would have happened
to Linux if Linus was an Ada fan :-)

Alright then, I'm not going to try to tilt at windmills,
at least by myself.  If nobody else is going to speak up
on the no-ocaml side, I will meekly go back to coding
in C in the hypervisor. :-)


> -----Original Message-----
> From: Ian Pratt [mailto:Ian.Pratt@eu.citrix.com]
> Sent: Thursday, April 02, 2009 5:37 PM
> To: Dan Magenheimer; Samuel Thibault
> Cc: Alex Zeffertt; Patrick Colp; xen-devel; George S. Coker, 
> II; Samuel
> Thibault; Ian Pratt
> Subject: RE: ocaml?? why?? (was: [Xen-devel] caml stubdom crashes)
> 
> 
> > > They already do: XenEnterprise is mostly implemented in ocaml.
> > 
> > Well, I suppose that's a good datapoint.  I wonder if the world's
> > supply of ocaml programmers all work for Citrix/Xensource. ;-)
> 
> Microsoft Visual Studio 2008 includes an F# compiler, and I 
> think you'll see Microsoft pushing f# quite heavily over the 
> coming years as a next generation programming language. 
> 
> F# is to first approximation OCAML with slightly changed 
> syntax. Rumour has it that the Microsoft F# compiler has a 
> mode where it will even accept plain OCAML... 
> 
> Anyhow, I think we're just a bit ahead of the general 
> adoption curve on this one.
>  
> As regards finding OCAML programmers, many European 
> Universities teach OCAML/ML and have done for many years. 
> Besides, I wouldn't dream of hiring anyone who couldn't 
> become proficient in a new programming language in a couple 
> of weeks just by looking at some existing source code. Beyond 
> XenSource/Citrix there are a bunch of other companies using 
> OCAML in a number of industries, particularly financial. 
> 
> It was a big risk when XenSource decided to adopt OCAML back 
> in 2005, but the experience has been very positive and has 
> undoubtedly improved code quality and accelerated 
> development. The tool chain has proved to be remarkably 
> stable -- about par as regards our experience with code 
> generation bugs in gcc over the same period, and certainly 
> the language is a _lot_ more stable as regards compiler 
> warnings -Werror etc. 
> 
> Anyhow, I've been converted from an OCAML sceptic, to a "go 
> ahead and use it where it makes sense". I'd be happy to see 
> OCAML in the main xen tree -- in fact there's already quite a 
> bit in the XenClient tree. 
> 
> Have a go writing some code and see how you like it in practice.
> 
> Ian
> 
> 
> > But I'd question whether one good datapoint in a controlled
> > single-product single-company focused startup environment
> > is a good representation of the problems that might occur
> > in a broader (e.g. open source) bazaar.
> > 
> > > No problem so far with the language itself.
> > 
> > This would seem to disagree with *No* problems.
> > http://cufp.galois.com/2008/slides/MadhavapeddyAnil.pdf
> > 
> > > -----Original Message-----
> > > From: Samuel Thibault [mailto:samuel.thibault@ens-lyon.org]
> > > Sent: Thursday, April 02, 2009 3:38 PM
> > > To: Dan Magenheimer
> > > Cc: xen-devel; Patrick Colp; Alex Zeffertt; George S. Coker,
> > > II; Samuel
> > > Thibault
> > > Subject: Re: ocaml?? why?? (was: [Xen-devel] caml stubdom crashes)
> > >
> > >
> > > Dan Magenheimer, le Thu 02 Apr 2009 12:39:04 -0700, a écrit :
> > > > In other words, it may be a very fine academic/research
> > > > language... but do we really want enterprise customers'
> > > > critical workloads dependent on it?
> > >
> > > They already do: XenEnterprise is mostly implemented in ocaml.  No
> > > problem so far with the language itself.  Personally, the
> > > fact that the
> > > ocaml compiler is itself written in ocaml (typesafe blablabla
> > > language)
> > > makes me trust it more that any gcc compiler.
> > >
> > > Samuel
> > >
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>

RE: ocaml?? why?? (was: caml stubdom crashes)

[Ian Pratt]

> If ocaml (or haskell or F# or the sum of ALL functional
> languages) grows exponentially, no problem.  If it turns
> out to be a fad (or even just grows linearly), having
> a huge base of code could be a significant albatross for
> the future of Xen.  I wonder what would have happened
> to Linux if Linus was an Ada fan :-)

Microsoft Visual Studio 2008 hasn't been out long -- it will be interesting to see how the F#/OCAML stats evolve. 

It's not like there are great alternatives for implementing something like a tool stack where you want a modern GC'ed language with a decent type system, and a small runtime. C/C++ are fairly archaic for this sort of thing. Our experience with python is not entirely happy -- runtime backtraces are a regular occurrence that could easily have been avoided with a statically typed language, and the memory footprint is big. I'm not a big java fan and we don't really want to carry around a JVM, plus calling native code is a mess. C# on mono is certainly plausible, but again, the runtime is quite large and complex. Lazy evaluation just creates more confusion that its worth in this kind of application, so scratch Haskell. OCAML compiles to native code, has an excellent static type system, the runtime is small and simple, and calling C code isn't too bad. 

I don't think any of the options have really changed too much since XenSource picked OCAML in 2005. C# on mono is probably more of a contender, but for the kinds of thing a tool stack has to do I'd still go for OCAML. 

 
Ian

Re: ocaml?? why?? (was: caml stubdom crashes)

[Anil Madhavapeddy]

On 2 Apr 2009, at 23:13, Dan Magenheimer wrote:

>> They already do: XenEnterprise is mostly implemented in ocaml.
>
> Well, I suppose that's a good datapoint.  I wonder if the world's
> supply of ocaml programmers all work for Citrix/Xensource. ;-)
>
> But I'd question whether one good datapoint in a controlled
> single-product single-company focused startup environment
> is a good representation of the problems that might occur
> in a broader (e.g. open source) bazaar.
>
>> No problem so far with the language itself.
>
> This would seem to disagree with *No* problems.
> http://cufp.galois.com/2008/slides/MadhavapeddyAnil.pdf
>

I was merely pointing out in those slides that OCaml wasn't a perfect  
language, and that there were obviously areas where we found it was  
more difficult to do stuff than others.  Please remember the audience;  
I was pointing out areas where FP language researchers could focus  
their attention if they are interested in more "real-world" adoption  
of their particular breed of languages.

Compared to the early sprawling mass of Twisted Python, or a complex C  
implementation riddled with memory corruption, OCaml was (and remains)  
a fantastic choice.

It is a really nice systems language mainly because the run-time is  
very, very simple.  You could read through it in a few hours (src/ 
byterun) and come away with a good idea of how the garbage collector  
and heap representation works.  Because types are stripped away at  
compile-time, the stuff sitting in memory is very regular and simple  
--- and it doesn't matter if the source program had intricate type  
checks in place as they only have to pass the compiler.

You can read a good low-level overview of the native code the compiler  
outputs here:
http://www.ocaml-tutorial.org/performance_and_profiling
(and the rest of the site is an excellent place to get started with  
some simple programs).

Come along to CUFP 2009 in Edinburgh this year and you'll see a really  
vibrant commercial community using FP... and with the heavy MS  
investment in F# (heavily inspired by OCaml); the style of programming  
is really taking off now.  I just bought a copy of "Real World  
Haskell" recently ... you know something's afoot when O'Reilly  
publishes a book with that title and it isn't April 1st :-)

-anil

>> -----Original Message-----
>> From: Samuel Thibault [mailto:samuel.thibault@ens-lyon.org]
>> Sent: Thursday, April 02, 2009 3:38 PM
>> To: Dan Magenheimer
>> Cc: xen-devel; Patrick Colp; Alex Zeffertt; George S. Coker,
>> II; Samuel
>> Thibault
>> Subject: Re: ocaml?? why?? (was: [Xen-devel] caml stubdom crashes)
>>
>>
>> Dan Magenheimer, le Thu 02 Apr 2009 12:39:04 -0700, a écrit :
>>> In other words, it may be a very fine academic/research
>>> language... but do we really want enterprise customers'
>>> critical workloads dependent on it?
>>
>> They already do: XenEnterprise is mostly implemented in ocaml.  No
>> problem so far with the language itself.  Personally, the
>> fact that the
>> ocaml compiler is itself written in ocaml (typesafe blablabla
>> language)
>> makes me trust it more that any gcc compiler.
>>
>> Samuel
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: ocaml?? why?? (was: caml stubdom crashes)

[John Levon]

On Thu, Apr 02, 2009 at 12:39:04PM -0700, Dan Magenheimer wrote:

> Why ocaml?  Let me make it clear that I know very little
> about ocaml... it may be a perfect match for the job and
> the best language since sliced bread, but as far as I can
> tell it is NOT A WIDELY DEPLOYED language.  As a result,
> the Xen community is going to have to work through all
> of the little distro/version-dependent idiosyncracies and

I agree that might well be a concern, but it's not the major one IMHO.
Simply put, the barrier to entry for hacking Xen tools written in ocaml
is much, much higher. Whilst you might be willing to learn a new
language, most people won't be. Never mind re-learn everything they know
about debugging it[1].

Put another way: xenstored is hardly stretching C's capabilities. xend
is hardly stretching Python's (at least now Twisted isn't used). Where
is the /need/ for a new, little-understood, language to be used?

I also find it a little difficult to believe that xenstored-C's
purported defects couldn't have been fixed, and required a total
rewrite.

regards
john

[1] I'm not exactly excited about hacking the OCaml runtime to
reimplement http://blogs.sun.com/levon/entry/dtrace_on_xenstored

Re: ocaml?? why??

[Vincent Hanquez]

John Levon wrote:
> On Thu, Apr 02, 2009 at 12:39:04PM -0700, Dan Magenheimer wrote:
>
>   
>> Why ocaml?  Let me make it clear that I know very little
>> about ocaml... it may be a perfect match for the job and
>> the best language since sliced bread, but as far as I can
>> tell it is NOT A WIDELY DEPLOYED language.  As a result,
>> the Xen community is going to have to work through all
>> of the little distro/version-dependent idiosyncracies and
>>     
>
> I agree that might well be a concern, but it's not the major one IMHO.
> Simply put, the barrier to entry for hacking Xen tools written in ocaml
> is much, much higher. Whilst you might be willing to learn a new
> language, most people won't be. Never mind re-learn everything they know
> about debugging it[1].
>
> Put another way: xenstored is hardly stretching C's capabilities. xend
> is hardly stretching Python's (at least now Twisted isn't used). Where
> is the /need/ for a new, little-understood, language to be used?
>   
I understand what you means (audience wise it's true), however i think 
that's very misleading to say it's a "new/little-understood" language. 
it's has been around for a while (1996, or 1985 for caml light), even 
more considering that the language is a variant of ML (1973). python is 
1991 FTR.
> I also find it a little difficult to believe that xenstored-C's
> purported defects couldn't have been fixed, and required a total
> rewrite.
>   
I'm sure the Xen team would be happy to apply your patch on the C 
version then :-)

OCaml has been great to use. Programming the same functional tree store 
with advanced transaction merging capability in the C version would have 
been a major pain, compared to how (almost) easy it was in OCaml.

-- 
Vincent

Re: ocaml?? why??

[John Levon]

On Mon, Apr 06, 2009 at 02:51:32PM +0100, Vincent Hanquez wrote:

> >Put another way: xenstored is hardly stretching C's capabilities. xend
> >is hardly stretching Python's (at least now Twisted isn't used). Where
> >is the /need/ for a new, little-understood, language to be used?
> >  
> I understand what you means (audience wise it's true), however i think 
> that's very misleading to say it's a "new/little-understood" language. 

Sorry, I wasn't clear: I meant new to Xen. If Xen source base had been
OCaml in the first place, it would be a different matter.

> OCaml has been great to use. Programming the same functional tree store 
> with advanced transaction merging capability in the C version would have 
> been a major pain, compared to how (almost) easy it was in OCaml.

So, I'm interested: why?

regards
john

Re: ocaml?? why??

[Vincent Hanquez]

John Levon wrote:
>> OCaml has been great to use. Programming the same functional tree store 
>> with advanced transaction merging capability in the C version would have 
>> been a major pain, compared to how (almost) easy it was in OCaml.
>>     
>
> So, I'm interested: why?
>   
The initial reason was getting rid of the on-disk database that also 
work as the mechanism for transaction  merging (a language with a GC is 
good for that). However it became quite clear, that we could also solve 
the problem of transaction stalling through the immutable tree and also 
making transactions cheap (the tree representation is shared over all 
transactions) compare to copying the whole database over filesystem of 
the C version.

at this point, making the transaction cheap is almost a given because of 
the language good GC (not referenced base !). the merging mechanism is 
something like 50 lines at this point too, with minimum code 
modifications on operations since that's the normal tree operations. 
(the C version has the same "normal operation" policy by  copying the 
whole database and just changing which database is actually being 
referenced)

So now the reason, why not to modify the C version .. first getting rid 
of disk database to the memory, is quite annoying to do (but relatively 
easy so far) .. then you need to solve the problem of transaction stalling.
there's lots of ways i guess, but i haven't imagine a solution where the 
same thing that the ocaml code does become trivial in C. either you need 
to modify every operation to understand some kind of modification list 
so that the tree get modified only at commit time (compare to now, at 
every operations), or you need to implement some kind of immutable tree 
(careful the C language doesn't prevent you for modifying it) which 
*requires* a GC that you need to implement too (or take one of those 
implementation from somewhere ..).

there's lots of other small reasons too, like the static type system 
that protect a lot during development phase (xenstored is very annoying 
to test, since it requires for full testing, to reboot the machine), and 
it's still an asset when i need to prove that no unexpected type are 
going to appears somehow (try to do the same thing in python and have 
fun :).

But surely xenstored could be implemented in any language, but I 
certainly wouldn't want to be the one fixing the C one, or implementing 
a python xenstored !

-- 
Vincent

Re: ocaml?? why??

[Patrick Colp]

Vincent Hanquez wrote:
> John Levon wrote:
>>> OCaml has been great to use. Programming the same functional tree
>>> store with advanced transaction merging capability in the C version
>>> would have been a major pain, compared to how (almost) easy it was in
>>> OCaml.
>>>     
>>
>> So, I'm interested: why?
>>   
> So now the reason, why not to modify the C version .. first getting rid
> of disk database to the memory, is quite annoying to do (but relatively
> easy so far) .. then you need to solve the problem of transaction stalling.
> there's lots of ways i guess, but i haven't imagine a solution where the
> same thing that the ocaml code does become trivial in C. either you need
> to modify every operation to understand some kind of modification list
> so that the tree get modified only at commit time (compare to now, at
> every operations), or you need to implement some kind of immutable tree
> (careful the C language doesn't prevent you for modifying it) which
> *requires* a GC that you need to implement too (or take one of those
> implementation from somewhere ..).

Not to mention the C version is a complete mess. I worked with it
previously to add XSM style security hooks. The policy and mechanism
were completely entangled, so this was not a trivial task. By the end of
it, there was an obvious conclusion to be draw: xenstored needed to be
re-written.

Beyond the source code itself, as Vincent points out, the old
transaction system was garbage. I wrote and released a DoS attack
earlier this year that brings the C xenstored to its knees (and
consequently Dom0).

When I implemented my version of XenStore in OCaml, I spent less than a
week to code together a ACID transactional system with "intelligent"
merging. In a nut-shell, it does per transaction copy-on-write of the
tree with some record keeping. Once a transaction is complete, it scans
the records to make sure nobody else has read a node that has been
modified by it then simply merges the copy-on-written version of the
tree into the original tree.

> there's lots of other small reasons too, like the static type system
> that protect a lot during development phase (xenstored is very annoying
> to test, since it requires for full testing, to reboot the machine), and
> it's still an asset when i need to prove that no unexpected type are
> going to appears somehow (try to do the same thing in python and have
> fun :).

This was a great win. Development was very quick due to the strong
typing of the language. Not to mention that this also makes the code
easier to understand and reason about. You can easily create immutables
(and I did so wherever possible) and know that they will never differ at
any point during execution than from when you created it. The same
cannot be said about C. A simple typo or pointer arithmetic mistake
somewhere and suddenly you have no idea what's going on and why your
program keeps crashing (or giving erroneous results).


> But surely xenstored could be implemented in any language, but I
> certainly wouldn't want to be the one fixing the C one, or implementing
> a python xenstored !

This is true as well, however as Ian pointed out, OCaml can be compiled
to native code and it is very easy to integrate it with C when needed.


Patrick

Re: ocaml?? why??

[John Levon]

On Mon, Apr 06, 2009 at 04:08:30PM +0100, Vincent Hanquez wrote:

> >>with advanced transaction merging capability in the C version would have 
> >>been a major pain, compared to how (almost) easy it was in OCaml.
> >
> >So, I'm interested: why?
> >  
> The initial reason was getting rid of the on-disk database that also 
> work as the mechanism for transaction  merging (a language with a GC is 

Whilst I agree that xenstored's  transaction-via-cp is incredibly gross,
you can get most of the benefit with a two-line patch to move it onto
tmpfs (as we have done for quite some time).

> same thing that the ocaml code does become trivial in C. either you need 
> to modify every operation to understand some kind of modification list 
> so that the tree get modified only at commit time (compare to now, at 
> every operations)

Well exactly. It's hot air since I haven't actually written it, but a
modification list doesn't seem particularly complex to me.

regards
john

Re: ocaml?? why??

[Vincent Hanquez]

John Levon wrote:
> Whilst I agree that xenstored's  transaction-via-cp is incredibly gross,
> you can get most of the benefit with a two-line patch to move it onto
> tmpfs (as we have done for quite some time).
>   
you're still writing inside a database on a ram filesystem ...  this is 
just a band-aid solution.
>> same thing that the ocaml code does become trivial in C. either you need 
>> to modify every operation to understand some kind of modification list 
>> so that the tree get modified only at commit time (compare to now, at 
>> every operations)
>>     
>
> Well exactly. It's hot air since I haven't actually written it, but a
> modification list doesn't seem particularly complex to me.
>   
Well that's only half the problem (dare i say the easy part ?), you 
still need to merge 2 xenstored databases together in a clever way 
without issuing a EAGAIN to the connection when it's possible (most of 
the cases).

-- 
Vincent

Re: caml stubdom crashes

[Alex Zeffertt]

George S. Coker, II wrote:
> 
> 
> On 4/2/09 12:22 PM, "Patrick Colp" <pjcolp@cs.ubc.ca> wrote:
> 
>> Alex Zeffertt wrote:
>>> Hello ocaml minios stubdomain experts (that's narrowed down the list
>>> somewhat!)
>>>
>>> I've been playing with the caml version of the "hello world" example
>>> stubdomain that can be found in xen-unstable.hg/stubdom/caml/.
>>>
>>> If I make the following trivial modification to stubdom/caml/hello.ml
>>> the stub domain page faults.  According to addr2line the page fault is
>>> in ungetc.c:0.
>>>
>>> --- a/stubdom/caml/hello.ml    Mon Mar 30 11:42:16 2009 +0100
>>> +++ b/stubdom/caml/hello.ml    Thu Apr 02 15:15:45 2009 +0100
>>> @@ -1,4 +1,6 @@
>>> +let yr = 2009
>>> +
>>>  let main arg =
>>> -  Printf.printf "Hello, world!\n%!."
>>> +  Printf.printf "Hello, world %d!\n%!." yr
>>>
>>>  let _ = Callback.register "main" main
>>>
>>>
>>> Without the above change the stub domain runs as expected, i.e. it does
>>> not page fault.
>>>
>>> I suspect the problem is that the caml-stubdom target in
>>> stubdom/caml/Makefile compiles stubdom/caml/hello.ml and links it with
>>> $(CAMLLIB)/libasmrun.a.  But this is a library compiled for the
>>> development machine platform (linux-i386-glibc) not for the stubdomain
>>> platform (minios-i386-newlib).
>>>
> 
> I don't think this is a linux-i386-glibc vs minios-i386-newlib issue but
> rather the FORTIFY compiler options that introduce the
> __fprintf_chk/__sprintf_chk funcs.  There is still something about the
> behavior of the FORTIFY options that I am still not accounting for.  As
> Patrick points out, special ports of ocaml should not be (and have not been)
> necessary.
>  

Hi George, thanks for replying.

Is this an option that was used when the ubuntu package managers built ocaml, 
but was not used by Debian.  Or have I misunderstood.

I'm using your "_chk and _fail canaries" patch (actually I've had to extend it 
as I got even more undefined syms when I tried to compile 
xen-ocaml-tools/xenstored.)  Are you saying that there is a problem with this patch?

Regards,

Alex

Re: caml stubdom crashes

[George S. Coker, II]

On 4/3/09 4:53 AM, "Alex Zeffertt" <alex.zeffertt@eu.citrix.com> wrote:

> George S. Coker, II wrote:
>> 
>> 
>> On 4/2/09 12:22 PM, "Patrick Colp" <pjcolp@cs.ubc.ca> wrote:
>> 
>>> Alex Zeffertt wrote:
>>>> Hello ocaml minios stubdomain experts (that's narrowed down the list
>>>> somewhat!)
>>>> 
>>>> I've been playing with the caml version of the "hello world" example
>>>> stubdomain that can be found in xen-unstable.hg/stubdom/caml/.
>>>> 
>>>> If I make the following trivial modification to stubdom/caml/hello.ml
>>>> the stub domain page faults.  According to addr2line the page fault is
>>>> in ungetc.c:0.
>>>> 
>>>> --- a/stubdom/caml/hello.ml    Mon Mar 30 11:42:16 2009 +0100
>>>> +++ b/stubdom/caml/hello.ml    Thu Apr 02 15:15:45 2009 +0100
>>>> @@ -1,4 +1,6 @@
>>>> +let yr = 2009
>>>> +
>>>>  let main arg =
>>>> -  Printf.printf "Hello, world!\n%!."
>>>> +  Printf.printf "Hello, world %d!\n%!." yr
>>>> 
>>>>  let _ = Callback.register "main" main
>>>> 
>>>> 
>>>> Without the above change the stub domain runs as expected, i.e. it does
>>>> not page fault.
>>>> 
>>>> I suspect the problem is that the caml-stubdom target in
>>>> stubdom/caml/Makefile compiles stubdom/caml/hello.ml and links it with
>>>> $(CAMLLIB)/libasmrun.a.  But this is a library compiled for the
>>>> development machine platform (linux-i386-glibc) not for the stubdomain
>>>> platform (minios-i386-newlib).
>>>> 
>> 
>> I don't think this is a linux-i386-glibc vs minios-i386-newlib issue but
>> rather the FORTIFY compiler options that introduce the
>> __fprintf_chk/__sprintf_chk funcs.  There is still something about the
>> behavior of the FORTIFY options that I am still not accounting for.  As
>> Patrick points out, special ports of ocaml should not be (and have not been)
>> necessary.
>>  
> 
> Hi George, thanks for replying.
> 
> Is this an option that was used when the ubuntu package managers built ocaml,
> but was not used by Debian.  Or have I misunderstood.
> 
> I'm using your "_chk and _fail canaries" patch (actually I've had to extend it
> as I got even more undefined syms when I tried to compile
> xen-ocaml-tools/xenstored.)  Are you saying that there is a problem with this
> patch?
> 
I think my patch is correct, but as you have found out my patch is also
incomplete.  I was not able to test with the ocaml xenstored when I created
the patch.

The issues that this patch and your other patch address are introduced by
the FORTIFY and -Wstack-protector options that are used to compile the
system ocaml libraries.  Debian is the last hold out to implement these
options (and I *think* the most recent versions of Debian have started to
build system tools with these protections).  So I attempted to sketch out a
patch that would point the way for allowing mini-os to be linked with and
leverage these system libraries without pulling in special builds of system
tools or distro development dependencies.

Thanks for your patch.  I'm going to have a further look into this issue
today.

> Regards,
> 
> Alex

-- 
George S. Coker, II <gscoker@alpha.ncsc.mil>

Re: caml stubdom crashes

[Patrick Colp]

[-- Attachment #1: Type: text/plain, Size: 4293 bytes --]

I tried running the regular XenStore (C xenstored) in a stubdomain using 
your patches, but have run into some difficulty.

What revision are the patches against? I noticed that not all of the 
patches applied cleanly. In particular with the xen_use_virq_handler_api 
patch, the files:

   xen/arch/x86/cpu/mcheck/amd_nonfatal.c
   xen/arch/x86/cpu/mcheck/mce_intel.c

failed to patch. I looked at the patch files and made the changes myself 
(as best I could).

I also had some issues with files missing (sysconfig.xenstore)) and some 
missing header files in xen/io/xs_wire.h.

For sysconfig.xenstore I just put one line in the file:

   STUBDOM=yes

Is that sufficient or are there other options that should be in there?

I've attached the patches for the changes I made. I've managed to get 
everything to compile and boot, however when I try to fire up xend, it 
dies. I tried to start xenconsoled by hand. It seems to run OK (no error 
messages or anything printed out), but it doesn't actually run.

Is there something I'm missing? A boot option I need to pass to Xen or 
anything? I used the patches you provided for Linux as well.


Thanks,
Patrick


George S. Coker, II wrote:
> 
> 
> On 4/3/09 4:53 AM, "Alex Zeffertt" <alex.zeffertt@eu.citrix.com> wrote:
> 
>> George S. Coker, II wrote:
>>>
>>> On 4/2/09 12:22 PM, "Patrick Colp" <pjcolp@cs.ubc.ca> wrote:
>>>
>>>> Alex Zeffertt wrote:
>>>>> Hello ocaml minios stubdomain experts (that's narrowed down the list
>>>>> somewhat!)
>>>>>
>>>>> I've been playing with the caml version of the "hello world" example
>>>>> stubdomain that can be found in xen-unstable.hg/stubdom/caml/.
>>>>>
>>>>> If I make the following trivial modification to stubdom/caml/hello.ml
>>>>> the stub domain page faults.  According to addr2line the page fault is
>>>>> in ungetc.c:0.
>>>>>
>>>>> --- a/stubdom/caml/hello.ml    Mon Mar 30 11:42:16 2009 +0100
>>>>> +++ b/stubdom/caml/hello.ml    Thu Apr 02 15:15:45 2009 +0100
>>>>> @@ -1,4 +1,6 @@
>>>>> +let yr = 2009
>>>>> +
>>>>>  let main arg =
>>>>> -  Printf.printf "Hello, world!\n%!."
>>>>> +  Printf.printf "Hello, world %d!\n%!." yr
>>>>>
>>>>>  let _ = Callback.register "main" main
>>>>>
>>>>>
>>>>> Without the above change the stub domain runs as expected, i.e. it does
>>>>> not page fault.
>>>>>
>>>>> I suspect the problem is that the caml-stubdom target in
>>>>> stubdom/caml/Makefile compiles stubdom/caml/hello.ml and links it with
>>>>> $(CAMLLIB)/libasmrun.a.  But this is a library compiled for the
>>>>> development machine platform (linux-i386-glibc) not for the stubdomain
>>>>> platform (minios-i386-newlib).
>>>>>
>>> I don't think this is a linux-i386-glibc vs minios-i386-newlib issue but
>>> rather the FORTIFY compiler options that introduce the
>>> __fprintf_chk/__sprintf_chk funcs.  There is still something about the
>>> behavior of the FORTIFY options that I am still not accounting for.  As
>>> Patrick points out, special ports of ocaml should not be (and have not been)
>>> necessary.
>>>  
>> Hi George, thanks for replying.
>>
>> Is this an option that was used when the ubuntu package managers built ocaml,
>> but was not used by Debian.  Or have I misunderstood.
>>
>> I'm using your "_chk and _fail canaries" patch (actually I've had to extend it
>> as I got even more undefined syms when I tried to compile
>> xen-ocaml-tools/xenstored.)  Are you saying that there is a problem with this
>> patch?
>>
> I think my patch is correct, but as you have found out my patch is also
> incomplete.  I was not able to test with the ocaml xenstored when I created
> the patch.
> 
> The issues that this patch and your other patch address are introduced by
> the FORTIFY and -Wstack-protector options that are used to compile the
> system ocaml libraries.  Debian is the last hold out to implement these
> options (and I *think* the most recent versions of Debian have started to
> build system tools with these protections).  So I attempted to sketch out a
> patch that would point the way for allowing mini-os to be linked with and
> leverage these system libraries without pulling in special builds of system
> tools or distro development dependencies.
> 
> Thanks for your patch.  I'm going to have a further look into this issue
> today.
> 
>> Regards,
>>
>> Alex
> 

[-- Attachment #2: xen_cpu_mcheck_virq_handler_api --]
[-- Type: text/plain, Size: 2836 bytes --]

diff -r d5ddc782bc49 xen/arch/x86/cpu/mcheck/amd_nonfatal.c
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c	Mon Mar 30 16:48:26 2009 +0100
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c	Fri Apr 03 13:53:59 2009 -0700
@@ -103,7 +103,7 @@
 
 		if (event_enabled) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_handler_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff -r d5ddc782bc49 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Mon Mar 30 16:48:26 2009 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Fri Apr 03 13:53:59 2009 -0700
@@ -350,6 +350,7 @@
     }
     /* We choose severity_cpu for further processing */
     if (severity_cpu == cpu) {
+        struct domain *handler;
 
         /* Step1: Fill DOM0 LOG buffer, vMCE injection buffer and
          * vMCE MSRs virtualization buffer
@@ -359,9 +360,10 @@
                      "virtualization data failed!\n");
 
         /* Step2: Send Log to DOM0 through vIRQ */
-        if (dom0 && guest_enabled_event(dom0->vcpu[0], VIRQ_MCA)) {
+        handler = get_global_virq_handler(VIRQ_MCA);
+        if (handler && guest_enabled_event(handler->vcpu[0], VIRQ_MCA)) {
             printk(KERN_DEBUG "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_guest_global_virq(handler, VIRQ_MCA);
         }
 
         /* Step3: Inject vMCE to impacted DOM. Currently we cares DOM0 only */
@@ -591,9 +593,11 @@
         MCA_CMCI_HANDLER, __get_cpu_var(mce_banks_owned), &bs);
 
     if (bs.errcnt && mctc != NULL) {
-        if (guest_enabled_event(dom0->vcpu[0], VIRQ_MCA)) {
+        struct domain *handler;
+        handler = get_global_virq_handler(VIRQ_MCA);
+        if (handler && guest_enabled_event(handler->vcpu[0], VIRQ_MCA)) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_guest_global_virq(handler, VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -705,10 +709,12 @@
         MCA_CMCI_HANDLER, __get_cpu_var(mce_banks_owned), &bs);
 
     if (bs.errcnt && mctc != NULL) {
-        if (guest_enabled_event(dom0->vcpu[0], VIRQ_MCA)) {
+        struct domain *handler;
+        handler = get_global_virq_handler(VIRQ_MCA);
+        if (handler && guest_enabled_event(handler->vcpu[0], VIRQ_MCA)) {
             mctelem_commit(mctc);
             printk(KERN_DEBUG "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_guest_global_virq(handler, VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);

[-- Attachment #3: xs_wire_extra_includes --]
[-- Type: text/plain, Size: 322 bytes --]

diff -r d5ddc782bc49 xen/include/public/io/xs_wire.h
--- a/xen/include/public/io/xs_wire.h	Mon Mar 30 16:48:26 2009 +0100
+++ b/xen/include/public/io/xs_wire.h	Fri Apr 03 13:52:44 2009 -0700
@@ -25,6 +25,9 @@
 
 #ifndef _XS_WIRE_H
 #define _XS_WIRE_H
+
+#include <errno.h>
+#include <stdint.h>
 
 enum xsd_sockmsg_type
 {

[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

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

Re: caml stubdom crashes

[Alex Zeffertt]

Patrick Colp wrote:
> I tried running the regular XenStore (C xenstored) in a stubdomain using 
> your patches, but have run into some difficulty.
> 
> What revision are the patches against? I noticed that not all of the 
> patches applied cleanly. In particular with the xen_use_virq_handler_api 
> patch, the files:
> 
>    xen/arch/x86/cpu/mcheck/amd_nonfatal.c
>    xen/arch/x86/cpu/mcheck/mce_intel.c
> 

My qparent is xen-unstable.hg: 19355:0e1449d6f231.  I'm afraid this is a couple 
of weeks old and I haven't refreshed the patch queue for the current head.


> failed to patch. I looked at the patch files and made the changes myself 
> (as best I could).
> 
> I also had some issues with files missing (sysconfig.xenstore)) and some 
> missing header files in xen/io/xs_wire.h.
> 
> For sysconfig.xenstore I just put one line in the file:
> 
>    STUBDOM=yes

If you run "make dist" you should find that it creates this file in
   dist/install/etc/sysconfig/xenstore

and it's contents should be
   ## Uncomment to start xenstored in a dedicated stub domain (requires reboot)
   #STUBDOM=yes

I.e. by default you get a xenstore dom0 daemon and not a xenstore stubdom.  See 
the "independent-xend-and-xenstored" patch.

> 
> Is that sufficient or are there other options that should be in there?
> 
> I've attached the patches for the changes I made. I've managed to get 
> everything to compile and boot, however when I try to fire up xend, it 
> dies. I tried to start xenconsoled by hand. It seems to run OK (no error 
> messages or anything printed out), but it doesn't actually run.
> 
> Is there something I'm missing? A boot option I need to pass to Xen or 
> anything? I used the patches you provided for Linux as well.
> 

It sounds like you may not have rsync'd the whole dist/install directory across 
after rebuilding xen-unstable with the patches.  In addition to 
/etc/sysconfig/xenstore there is a new file called /etc/init.d/xenstore.  The 
problem you are seeing sounds like what would happen if this file was not present.

BTW, I've added a bit of code to /etc/init.d/xend  which runs 
"/etc/init.d/xenstored start" if it hasn't already been started.  This is there 
just in case users don't chkconfig this new script.

Regards,

Alex

> 
> Thanks,
> Patrick
> 
> 
> George S. Coker, II wrote:
>>
>> On 4/3/09 4:53 AM, "Alex Zeffertt" <alex.zeffertt@eu.citrix.com> wrote:
>>
>>> George S. Coker, II wrote:
>>>> On 4/2/09 12:22 PM, "Patrick Colp" <pjcolp@cs.ubc.ca> wrote:
>>>>
>>>>> Alex Zeffertt wrote:
>>>>>> Hello ocaml minios stubdomain experts (that's narrowed down the list
>>>>>> somewhat!)
>>>>>>
>>>>>> I've been playing with the caml version of the "hello world" example
>>>>>> stubdomain that can be found in xen-unstable.hg/stubdom/caml/.
>>>>>>
>>>>>> If I make the following trivial modification to stubdom/caml/hello.ml
>>>>>> the stub domain page faults.  According to addr2line the page fault is
>>>>>> in ungetc.c:0.
>>>>>>
>>>>>> --- a/stubdom/caml/hello.ml    Mon Mar 30 11:42:16 2009 +0100
>>>>>> +++ b/stubdom/caml/hello.ml    Thu Apr 02 15:15:45 2009 +0100
>>>>>> @@ -1,4 +1,6 @@
>>>>>> +let yr = 2009
>>>>>> +
>>>>>>  let main arg =
>>>>>> -  Printf.printf "Hello, world!\n%!."
>>>>>> +  Printf.printf "Hello, world %d!\n%!." yr
>>>>>>
>>>>>>  let _ = Callback.register "main" main
>>>>>>
>>>>>>
>>>>>> Without the above change the stub domain runs as expected, i.e. it does
>>>>>> not page fault.
>>>>>>
>>>>>> I suspect the problem is that the caml-stubdom target in
>>>>>> stubdom/caml/Makefile compiles stubdom/caml/hello.ml and links it with
>>>>>> $(CAMLLIB)/libasmrun.a.  But this is a library compiled for the
>>>>>> development machine platform (linux-i386-glibc) not for the stubdomain
>>>>>> platform (minios-i386-newlib).
>>>>>>
>>>> I don't think this is a linux-i386-glibc vs minios-i386-newlib issue but
>>>> rather the FORTIFY compiler options that introduce the
>>>> __fprintf_chk/__sprintf_chk funcs.  There is still something about the
>>>> behavior of the FORTIFY options that I am still not accounting for.  As
>>>> Patrick points out, special ports of ocaml should not be (and have not been)
>>>> necessary.
>>>>  
>>> Hi George, thanks for replying.
>>>
>>> Is this an option that was used when the ubuntu package managers built ocaml,
>>> but was not used by Debian.  Or have I misunderstood.
>>>
>>> I'm using your "_chk and _fail canaries" patch (actually I've had to extend it
>>> as I got even more undefined syms when I tried to compile
>>> xen-ocaml-tools/xenstored.)  Are you saying that there is a problem with this
>>> patch?
>>>
>> I think my patch is correct, but as you have found out my patch is also
>> incomplete.  I was not able to test with the ocaml xenstored when I created
>> the patch.
>>
>> The issues that this patch and your other patch address are introduced by
>> the FORTIFY and -Wstack-protector options that are used to compile the
>> system ocaml libraries.  Debian is the last hold out to implement these
>> options (and I *think* the most recent versions of Debian have started to
>> build system tools with these protections).  So I attempted to sketch out a
>> patch that would point the way for allowing mini-os to be linked with and
>> leverage these system libraries without pulling in special builds of system
>> tools or distro development dependencies.
>>
>> Thanks for your patch.  I'm going to have a further look into this issue
>> today.
>>
>>> Regards,
>>>
>>> Alex

Re: caml stubdom crashes

[Alex Zeffertt]

Patrick Colp wrote:
> Alex Zeffertt wrote:
>> I suspect the problem is that the caml-stubdom target in 
>> stubdom/caml/Makefile compiles stubdom/caml/hello.ml and links it with 
>> $(CAMLLIB)/libasmrun.a.  But this is a library compiled for the 
>> development machine platform (linux-i386-glibc) not for the stubdomain 
>> platform (minios-i386-newlib).
>>
>> Maybe the original hello.ml only worked through luck, and the fact that 
>> it used so very little of the ocaml language.
> 
> What environment did you use to compile the stubdom? I tried using Ubuntu 
> with George Coker's patch and got the same result as you (page faulting). 
> Interestingly, I could use a %s and a string and that seems to work OK, but 
> not %d with an int.
> 
> When I instead used Debian to compile the stubdom (which requires no 
> patch), then I could compile and run your code just fine (no page faults). 
> Maybe this is the problem you're having?
> 


That's interesting, thanks!  I am using Ubuntu intrepid with ocaml version 
3.10.2-3ubuntu1.

I don't really like the idea of requiring a Debian build environment as a 
solution.  It suggests a dependency on something we really don't understand.
Wouldn't it be better to rebuild ocaml under stubdom/ like we do for newlib and 
lwip, and the be sure we'll get the same results whatever the build machine?

> 
>> In order to run a non trivial ocaml application in a stubdomain (e.g. 
>> ocaml xenstored) do I need to port ocaml to minios-i386-newlib?
> 
> No, it should be possible as is. In fact, I've gotten my OCaml XenStore to 
> run in a caml-stubdom (compiled in a Debian domain).
> 
> I'll soon be releasing a patch against the recently released disaggregated 
> C xenstored stuff that uses my OCaml XenStore in a caml-stubdom instead.
> 
> 

Ah, it looks like we've been duplicating the work.  I've been working on getting
  http://xenbits.xensource.com/ext/xen-ocaml-tools.hg integrated into 
xen-unstable.hg.  The idea is that by default "make dist" builds the in-tree 
xenstored (as both a dom0 daemon and as a stubdom), but by uncommenting a line 
in Config.mk it will download xen-ocaml-tools.hg and build that instead (as both 
a dom0 daemon and as a stubdom).  The choice of whether to run it as a dom0 
daemon or as a stubdom is made post-install.

This system allows you to override the url used to get the "remote" xenstored. 
The build system does something similar for qemu already.

I'll send you my patches offline.

> Patrick
> 

Regards,

Alex