xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Oleksandr Andrushchenko <andr2000@gmail.com>
To: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Rich Persaud <persaur@gmail.com>
Cc: Roman Shaposhnik <rshaposhnik@linuxfoundation.org>
Subject: Re: [XenSummit 2017] Build tools follow up
Date: Mon, 31 Jul 2017 14:28:54 +0300	[thread overview]
Message-ID: <da88785c-5da9-0950-739a-c16bdd705f2f@gmail.com> (raw)
In-Reply-To: <5dc4cff5-f7b7-c320-c34a-26273141210f@epam.com>

ping

On 07/17/2017 03:47 PM, Oleksandr Andrushchenko wrote:
> Hi, all!
>
> This is a follow-up on Xen distribution build systems we saw at the
> summit and invitation for sharing thoughts and ways we build our 
> images and
> distros. I would like to specifically ask OpenXT project to reply with 
> the
> description of their build system so we have clear picture of what is 
> being
> developed and used around. And of course if there are other approaches 
> to do the
> same you are welcome to share those as well.
>
> On our side at EPAM we have developed a distribution which is called 
> xt-distro
> (xt stays for Xen troops [0]) with the following goals in mind:
> 1. Make it possible to easily build different images as a single 
> distribution
>    - Separate images for different domains should be combined into a
>      distribution, e.g. set of images/artifacts required to run them as a
>      system
>    - Xt-distro allows doing so as easy as running bitbake with the 
> predefined
>      target, e.g. “bitbake xt-image”
> 2. Easily deal with different BSPs for different platforms using a 
> unified way
>    with little or no EPAM specific code/scripts
>    - We use bitbake and stripped version of Poky/meta-openembedded, so 
> there are
>      little in-house extensions we added to deal with Yocto based BSPs 
> [1], [2]
>    - We use bitbake’s well defined scripting language [3], so no yet 
> another
>      language to learn
>    - We use Google repo tool to maintain sets of meta layers as 
> manifest files [4]
> 3. Ability to easily collect component revisions, so any build can be
>    reproduced if need be
>    - We save commit IDs of every component of the build including 
> versions of the
>      meta layers
> 4. Ability to easily customize and tune builds, e.g. URIs, 
> versions/commitIDs,
>    branches used
>    - This is purely done in bitbake’s recipe language
> 5. Make patching process easy
>    - With our extensions you can use bblayers.conf, local.conf, 
> patches which
>      are part of a meta layer which is usually a manual step
> 6. Code reuse is a must, e.g. the same set of software must be easily 
> built for
>    different platforms without copying build scripts of the existing 
> components
>    - With bitbake’s meta layers we define generic recipes, e.g. 
> suitable for all
>      platforms [5] (think of it as a library) and tuning meta layers [6]
>      (we use product concept here) which define specific 
> versions/revisions of the
>      components, apply specific patches and add/remove software
> 7. Cross compilation must be an easy task to do
>    - This is easily achieved with Yocto builds and usually not a 
> problem for other
>      build systems as well (with SDKs)
>    - Allows building for x86/ARM and other architectures as well
> 8. There must be a simple way to share build artifacts of different 
> domains between
>    each other, for example, DomU’s kernel should be a part of Dom0’s 
> rootfs, so
>    xl/libxl can access it
>    - This is achieved with bitbake’s recipes, so no EPAM extensions
> 9. Possibility to easily use different build systems for different 
> components of
>    the system.
>    - Bitbake allows you building makefile based projects, CMake etc. 
> out of the box,
>      so adding firmware, stubdoms made easy
> 10. Development support
>    - We use SDKs built by bitbake so during everyday development you 
> are packed with
>      all that is needed to re-create build environment (with both host 
> and target
>      environments, e.g. x86 host tools and ARM cross-compiler)
>    - Speed up builds for developers within organization, e.g. we reuse 
> downloads and
>      build cache between all of the developer’s machines on our network
> 11. Make the build system suitable for build automation
>     - We have created a python script which can easily be used with
>       Jenkins or even cron [7]
>
> For example, with xt-distro our development product delivers: Xen 
> image and
> policy file, Dom0 kernel and dtb images (Dom0 + DomU), Dom0 rootfs 
> image (with
> embedded kernels and configuration for DomU), DomU rootfs image. This
> effectively means, that the build system can provide you with the 
> complete set
> of images to run your product/distribution.
>
> We are looking forward for any kind of feedback and will be glad to 
> collaborate
> on the above.
>
> Thank you,
> Xen-troops at EPAM
>
> [0] https://github.com/xen-troops/xt-distro
> [1] https://git.yoctoproject.org/cgit/cgit.cgi/poky
> [2] http://cgit.openembedded.org/meta-openembedded
> [3] 
> http://www.yoctoproject.org/docs/2.3/bitbake-user-manual/bitbake-user-manual.html
> [4] https://gerrit.googlesource.com/git-repo
> [5] https://github.com/xen-troops/meta-xt-images
> [6] https://github.com/xen-troops/meta-xt-prod-devel
> [7] https://github.com/xen-troops/build-scripts
>


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

      reply	other threads:[~2017-07-31 11:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-17 12:47 [XenSummit 2017] Build tools follow up Oleksandr Andrushchenko
2017-07-31 11:28 ` Oleksandr Andrushchenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=da88785c-5da9-0950-739a-c16bdd705f2f@gmail.com \
    --to=andr2000@gmail.com \
    --cc=oleksandr_andrushchenko@epam.com \
    --cc=persaur@gmail.com \
    --cc=rshaposhnik@linuxfoundation.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).