|
xen-devel
[Xen-devel] 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@xxxxxxxxxx
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home