This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH] sysfs attributes for xen

To: Dave Hansen <haveblue@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] sysfs attributes for xen
From: "Mike D. Day" <ncmike@xxxxxxxxxx>
Date: Mon, 30 Jan 2006 11:58:12 -0500
Cc: Greg KH <greg@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, lkml <linux-kernel@xxxxxxxxxxxxxxx>
Delivery-date: Mon, 30 Jan 2006 17:09:05 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1138637931.19801.101.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <43DAD4DB.4090708@xxxxxxxxxx> <1138637931.19801.101.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (Macintosh/20051201)
Dave Hansen wrote:

What are the actual types of the values that come back from the

        HYPERVISOR_xen_version(XENVER_version, NULL)
call?  If they are really 8-bit or 16-bit values, it might be nice to
call that out and use some of the kernel types like u8 or u16.  In fact,
it might even be worth it to have a function wrap that up.

return is int, but the ranges are small enough for a u8, so a wrap might be good. ret == 0 is ESUCCESS _unless_ you are calling HYPERVISOR_xen_version, in which case ret == version.
Silly idea: you _could_ have separate files for the major and minor.
Are they something that a userspace program might commonly have to parse
out?  Is the patch trying to save a potential hcall by outputting them
both at once?

no, this hypercall is not in any performance path and it also returns major ver and minor ver embedded into the returned int. Good suggestion and no problem calling repeatedly (within reason).
Where does that 1024 come from?  Is it a guarantee from Xen that it will
never fill more than 1k?  I know it is a long shot, but what if the page
size is less than 1k?  Would this function have strange results?

Per the xen headers, this particular hcall option returns a typedef char[1024] thingy_t (which is simply a char [1024] in the patch). Yes, if the page size is < 1024 there is a problem. So a check against PAGE_SIZE may be prudent.

I'm rewriting based on Greg's and your feedback,

thanks again,


Xen-devel mailing list