On Tue, Nov 3, 2009 at 11:51 AM, Dave Scott <Dave.Scott@xxxxxxxxxxxxx> wrote:
>
> Hi,
>
> Mark Johnson wrote:
>> This is great that Citrix is open sourcing this code... Thanks for that!
>>
>> Some questions...
>> o Are there any high level READMEs for what is in what directories
>> for the two repos?
>
> The best we've got at the moment is some generated module/function-level docs:
>
> http://www.xen.org/files/XenCloud/ocamldoc/
>
> Here's a quick inline summary:
>
> xen-dist-ocaml.hg: a bunch of Makefiles (in the style of BSD ports I think)
> for downloading and building external tools and libs. At some point we should
> probably switch to using RPMS.
>
> xen-api-libs.hg: utility libraries, some xen-specific some more general: eg
> camldm: interface to device-mapper
> cdrom: wrappers around CDROM-specific ioctls
> eventchn: xen event channel stubs
> fake: used as part of a hypercall simulator (for testing)
> log: logging library (with syslog bindings)
> mmap: interface to mmap
> rpc-light: a simple RPC framework capable of using XMLRPC and JSON
> sha1: stubs for generating sha1sums
> stdext: helper functions to augment standard libraries
> uuid: generates uuids
> xb: stuff for talking xenbus
> xs: stuff for talking to xenstore
> xc: hypercalls
>
> xen-api.hg: most of the stuff is here
> java: contains the example Java VM console viewer
> javascript: contains the example Javascript UI
> ocaml/auth: stuff for PAM, AD
> ocaml/client_records: utility stuff for the CLI
> ocaml/console: console forwarding
> ocaml/database: manages the VM, host metadata
> ocaml/idl/datamodel.ml: defines the API
> ocaml/xenops: low-level domain, qemu management
> ocaml/xapi/xapi_*: high-level API entrypoints
> ocaml/xapi/vmops: higher-level domain, qemu management
> ocaml/xenstored: ocaml xenstore
Thanks, that's exactly what I was looking for.
>
>> o What has not been open sourced? i.e. after a brief look, I didn't
>> see the VHD code... But I could have missed it...
>
> My understanding is that the VHD code was OSSed a while back. Although we're
> still
> on blktap1, we're intending to explicitly switch to the new blktap2 stuff as
> soon as practical.
Oh, that's right... Thanks.
Other than the GUI, what will remained closed source in the
XenServer product? i.e. are there any extensions to the cli,
xapi? Any additional libs not present in xen-api-libs.hg?
Any extensions to blktap?
I assume things like the p2v and v2v tools will remain
closed source...
I'm just trying to get a feel for what functionality is being opened up.
And what functionality, if any, Citrix doesn't want to open up at
this time.
>> o Now that there are two tool stacks, are there any short term
>> and long term thoughts, plans, roadmaps, etc...
>>
>> o I noticed there are a fair amount of Xen and qemu patches.. I
>> see that some are toolset specific and some are not.. Are there any
>> plans to start rolling these into unstable and a a few of them into 3.4?
>> (I realize this takes a lot of work and time).
>
> I'm compiling a xapi toolstack architecture document which contains some of
> our thoughts on how the toolstack could evolve. It's partially complete
> (perhaps such things are always partially complete) but I'll check it into
> the xen-api.hg repo anyway. We also have a draft of a toolstack roadmap which
> I'll try to get on the wiki.
>
> We're keen to reduce the size of the patch queues. I believe bugfixes are all
> upstream but there's still stuff like the occasional backport... or an
> interface change that was never upstreamed. For example I think there's a
> change to the block device shutdown protocol which makes toolstack error
> handling easier. Hopefully we can start discussing those changes and either
> drop them or upstream them :)
Great, thanks Dave!
MRJ
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
|
Home