Messages in this thread | | | Date | Wed, 11 Jan 2006 19:23:53 -0500 | From | "Mike D. Day" <> | Subject | Re: [RFC] [PATCH] sysfs support for Xen attributes |
| |
Greg KH wrote:
> Why is xen special from the rest of the kernel in regards to adding > files to sysfs? What does your infrastructure add that is not currently > already present for everyone to use today?
I think it comes down to simplification for non-driver code, which is admittedly not the mainstream use model for sysfs.
> > Why is the xen version any different from any other module or driver > version in the kernel? (hint, use the interface that is availble for > this already...)
The module version? Xen is not a module nor a driver, so that interface doesn't quite serve the purpose. True, one could create a "Xen module" that talks to Xen the hypervisor, but then the version interface would provide the version of the xen module, not the version of the xen hypervisor. /sys/xen/version may not be the best example for this discussion. What is important is that this attribute is obtained from Xen using a hypercall. Sysfs works great to prove the xen version and other similar xen attributes to userspace.
> > You have access to the current tree as well as we do to be able to > answer this question :)
Right. Dumb question.
> You don't have to create a driver subsystem to be able to add stuff to > sysfs, what makes you think that?
Sorry, you are right. But you do need to have s struct dev or use kobjects. What I want is an interface to create sysfs files using a path as a parameter, rather than a struct kobject.
> did you look at debugfs?
yes
> configfs?
no. configfs may be a better choice. I would still want a higher-level kernel interface similar to what is in the patch, as explained below. But I think sysfs may be more appropriate because attributes show up automatically without a user-space action being taken.
> What is wrong with the current kobject/sysfs/driver model interface that > made you want to create this extra code?
Nothing is wrong, but I want a higher-level interface, to be able to create files and directories using a path, and to allow a code that is not associated with a device to create sysfs files by specifying a path. e.g., create(path, mode, ...).
Currently in xeno-linux there are several files under /proc/xen. These are created by different areas of the xeno-linux kernel. In xeno-linux today there is a single higher-level routine that each of these different areas uses to create its own file under /proc/xen. In other words, I think there should be a unifying element to the interface because the callers are not organized within a single module.
> Aren't you already going to have a xen virtual bus in sysfs and the > driver model? Why not just put your needed attributes there, where they > belong (on the devices themselves)?
the xenbus, which is now in xen 3.0, allows kernels running in xen domains to get access to virtual devices hosted in a driver domain/domain0. But the attributes I am creating in /sys/xen are xen attributes, not device attributes. The difference is important to consumers of the attributes. I could create a device just to export hypervisor attributes, but I think the what I've done is simpler.
>>+#define __sysfs_ref__ > > > Why?
A simple way to denote functions that get a reference to a reference counted object. e.g., int __sysfs_ref__ foo(void); gone.
> > >>+struct xen_sysfs_object; >>+ >>+struct xen_sysfs_attr { >>+ struct bin_attribute attr; >>+ ssize_t (*show)(void *, char *) ; >>+ ssize_t (*store)(void *, const char *, size_t) ; >>+ ssize_t (*read)(void *, char *, loff_t, size_t ); >>+ ssize_t (*write)(void *, char *, loff_t, size_t) ; >>+}; > > > Why a binary attribute? Do you want to have more than one single piece > of info in here? If so, no.
To facilitate creation of binary files. struct bin_attribute contains a struct attribute, so it is an alternative to using a union.
Mike (hoping he doesn't end up on linux kernel monkey log)
--
Mike D. Day STSM and Architect, Open Virtualization IBM Linux Technology Center ncmike@us.ibm.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |