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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Greg KH wrote:

I think it comes down to simplification for non-driver code, which is admittedly not the mainstream use model for sysfs.

/sys/module/ is a pretty "mainstream use model for sysfs", right?

Yes, but xen is not a module. I believe /sys/xen/ is different than /sys/module/, and provide some further reasoning below.

The module version? Xen is not a module nor a driver, so that interface doesn't quite serve the purpose.

Then it doesn't need a separate version, as it is the same as the main
kernel version, right?  Just because your code is out-of-the-tree right

No. For example, I could run linux-2.6.x in a domain under xen 3.0.0. In this case the xen version is 3.0.0, the linux version is 2.6.x. I could run the very same kernel on xen 3.0.1, xen 3.1, and eventually xen 4.x.x. The xen version exists outside of the linux kernel version, but userspace will have good reasons to want to know the xen version (think management tools).

Huh?  You can't just throw a "MODULE_VERSION()", and a module_init()
somewhere into the xen code to get this to happen?  Then all of your
configurable paramaters show up automagically.

No, I can't. Xen does not have modules. Xen loads and runs linux. I am trying to make it simple for linux to represent xen attributes under /sys/xen. This is analogous to a kernel module representing the kernel. I know it is weird.

/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.


Like what?  Specifics please.

What privileges are granted to the kernel by xen - can the kernel control real devices or just virtual ones. How many other domains (virtual machines) are being hosted by xen? How much memory is available for ballooning (increasing the memory used by kernels through the remapping of pages inside the hypervisor). Can the domain be migrated to another physical host? What scheduler is Xen using (xen has plug-in schedulers)? All the actual information resides within the xen hypervisor, not the linux kernel.

So you want to divorce the relationship in sysfs between directories and
kobjects?

Not quite, just hide the relationship for users of sysfs that have no reason to know about it.

That's a valid proposal, but just don't do it as a xen
specific thing please, that's being selfish.

ok

But I think you will fail in this, as we want to keep a very strict
heirachy in sysfs, as userspace relies on this.  See the previous
proposal from Pat Mochel to try to do this (in the lkml archives) for
the problems when he tried to do so.

Hence why I created this as a xeno-linux patch. I can control where the sysfs files get created. For example, I check to make sure the path starts with "/sys/xen." I don't want to interfere with keeping a strict heirarchy.


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.

Ok, but again, that's no different than anything else in the kernel,
right?

I think that it is different. The sysfs attributes are being created by the kernel, not a driver or module. The attribute values themselves are located in the xen hypervisor, which is totally outside of the kernel and everything it controls.

not be applied due to a broken email client setup, tried to do all of
the work in your own subsection of an external kernel tree that seems to

I worked within the xen project hoping that the code might get applied there and later merged.

strongly avoid getting merged into mainline, ignored the existing kernel
interfaces,

No, I didn't ignore them. I may be mistaken, but I believe this is a different use model.

and didn't cc: the subsystem maintainer.

Sorry, will make certain to cc: the maintainer in the future.

Mike
--

Mike D. Day
STSM and Architect, Open Virtualization
IBM Linux Technology Center
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux