[lkml]   [2006]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Xen-devel] Re: [PATCH] sysfs attributes for xen
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,



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-01-30 18:01    [W:0.054 / U:0.928 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site