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

[Dave Hansen <haveblue@us.ibm.com>]

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