From mboxrd@z Thu Jan 1 00:00:00 1970 From: aq Subject: Re: xen_version hypercall Date: Sat, 4 Jun 2005 23:48:49 +0900 Message-ID: <9cde8bff05060407484fd9f5dc@mail.gmail.com> References: <9cde8bff0506040718626cfbb5@mail.gmail.com> <200506041434.57195.mark.williamson@cl.cam.ac.uk> Reply-To: aq Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com, Mark Williamson List-Id: xen-devel@lists.xenproject.org On 6/4/05, Keir Fraser wrote: >=20 > On 4 Jun 2005, at 14:34, Mark Williamson wrote: >=20 > > > > The additional info would ideally allow the whole Xen version string > > to be > > pieced together, as displayed at boot e.g. > > > > "Xen version 3.0-devel (mwilli2@) (gcc version 3.4.2 20041017 (Red Hat > > 3.4.2-6.fc3)) Mon May 16 15:12:17 BST 2005" > > (like uname -a) > > > > Or a subset of that info. > > > > What do you think? >=20 > xen_version() takes a command parameter. We can extend the comamnd > enumeration (currently the command is always =3D=3D 0) to be abel to find > out other interesting stuff. >=20 yes, i think this solution is cleaner than extending dom0-ops. i will work on it to let it returns extraversion when id=3D1 first. any other information we need, beside extraversion? regards, aq