WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

On Mon, 2006-01-30 at 12:17 -0500, Mike D. Day wrote:
> Dave Hansen wrote:
> > In the final version, there will be available Xen headers, and the
> patch
> > won't need the open-coded 1024?
> 
> Good question, I need some advice. The Xen hcall headers get
> soft-linked into every paravirtualized OS tree: linux, bsd, solaris,
> etc. In linux right now the xen version.h shows up
> as /include/asm-xen/version.h.

But, you can #include it from any old Linux file and not care, right?

> This file uses typedefs for every important parameter. For example,
> typedef char [1024] xen_capabilities_info_t;. 
> 
> But as Greg says TYPEDEFS ARE EVIL. 

Yes, they are.  Buuuuuuut, you _can_ make the code around them a little
less evil.  If you _must_ use a typedef, you could do something like
this:

#define XEN_CAP_INFO_LEN_BYTES 1024
typedef char [XEN_CAP_INFO_LEN_BYTES] xen_capabilities_info_t;

That way, you can do your thing without using the typedef in the sysfs
code.  The very best way to do it is to skip the typedef altogether, and
just explicitly create char[] arrays with the length macro when you need
them.

If you did this, and dynamically allocated the buffer, your cap_show
function could look something like this:

+/* xen capabilities info */
+static ssize_t xen_cap_show(struct kobject *kobj,
+                               struct attribute *attr,
+                               char *sysfs_buf)
+{
+       ssize_t result = 0;
+       char *info_buf;
+
+       /* +1 is to make room for the \n in the snprintf */
+       info_buf = kmalloc(XEN_CAP_INFO_LEN_BYTES+1, GFP_KERNEL);
+       if(!info_buf)
+               return result;
+
+       if (HYPERVISOR_xen_version(XENVER_capabilities, &info_buf))
+               goto out;
+
+       result = snprintf(sysfs_buf, XEN_CAP_INFO_LEN_BYTES+1,
+                               "%s\n", info_buf);
+out:
+       kfree(info_buf);
+       return result;
+}

> Last resort would be to use the funky gcc #include_next to override
> the xen hcall headers with a linux-specific hcall headers. But I don't
> know if that would be cool with lkml either. 

I've never seen that done, so I'd try to steer clear.  

-- Dave


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel