Re: [RFC] [PATCH] sysfs support for Xen attributes

["Mike D. Day" <ncmike@us.ibm.com>]

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/