From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH RFC 2/9] ts-unixbench-prep: prep the environment for running unixbench Date: Wed, 16 Jul 2014 17:57:13 +0200 Message-ID: <1405526233.5333.101.camel@Solace> References: <20140626124540.20110.24159.stgit@Solace> <20140626130229.20110.53073.stgit@Solace> <1405523380.1087.14.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2584658390327227999==" Return-path: In-Reply-To: <1405523380.1087.14.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Ian.Jackson@citrix.com, Stefano Stabellini , Wei Liu , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============2584658390327227999== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3omVFb97RCwqMZt135NY" --=-3omVFb97RCwqMZt135NY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mer, 2014-07-16 at 16:09 +0100, Ian Campbell wrote: > On Thu, 2014-06-26 at 15:02 +0200, Dario Faggioli wrote: > > by installing some dependencies, >=20 > this isn't currently possible due to the (possibly futuristic) potential > to share build hosts. ts-xen-build-prep is special in this regard > (AIUI). I don't see you installing anything which would be so > intolerable to install on every machine. >=20 > I have an old patch "apt: lock osstest's usages of apt-get against each > other" which is supposed to help with this, but I need to revisit and > fix some comments from Ian I think. >=20 Mm... I'd be fine with installing everything on every test host. However, as we grow the number of supported benchmark, dependencies will also grow. E.g., if we want to run SpecJBB, we'll need JVM stuff. If we want to run even a subset of Phoronix test suite, we'll need a lot of stuff, I think... Is this still acceptable? > > shipping the archive, untaring > > and building the sources. >=20 > ts-unixbench-build would be the more conventional name I think. >=20 Indeed. Fact is, there are benchmarks that require building (e.g., this one), and benchmark that does not (e.g., kernbench). I thought it would be good to have all the prepping script to have a similar name (if not to include all the prep work in just one ts-bench-prep that takes the benchmark name as a parameter! Look at the very last patch of the series). That's the reason for the 'prep' instead than 'build'. What do you think? > > This accepts two parametrs, in the form 'host=3Dsomehost someguest', > > as most of the ts-guest-xxx scripts. If only the first one is > > provided, it must be 'host=3Dsomehost', and the script will prep > > the host. > >=20 > > XXX: I see it useful that this works for the host too, as > > at some point we may want to run benchmarks on dom0 > > or even bare metal. >=20 > Absolutely. I realise now that the comments about apt install above is > only really relevant to the host case. >=20 Which would make the 'path' for running benches on host and guest a bit different, but that's certainly fine. If we're installing *everything* on hosts, I've got no problem making this prepping scripts available for guests only. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-3omVFb97RCwqMZt135NY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlPGoNkACgkQk4XaBE3IOsSkEgCdF8wM96a26PDCpD+s636lqAxj p5gAoIYA2bV/86fht6BBxRVvXhi/jR6x =0IK8 -----END PGP SIGNATURE----- --=-3omVFb97RCwqMZt135NY-- --===============2584658390327227999== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2584658390327227999==--