Re: xenfs aka /proc/xen

[Bastian Blank <waldi@debian.org>]

On Fri, May 28, 2010 at 06:40:02AM +0100, Keir Fraser wrote:
> On 27/05/2010 23:54, "Bastian Blank" <waldi@debian.org> wrote:
> > One of the entries (capabilities) provides information about the
> > proviledge level to the hypervisor and belongs more likely into
> > /sys/hypervisor. The four other are plain old devices and belongs into
> > /dev.

Okay. I thought about it and would settle for the following:
* $SYSFS/hypervisor/properties/guest_capabilites
  It includes the same value then $XENFS/capabilities. Or should that be
  changed as the meaning of "control_d" is not really clear (like
  "control-domain")?
* $DEV/xen/xenbus
  Merge into builtin xenbus support or own module xenbus-user
* $DEV/xen/privcmd
  - Module xen-control or so
  - *Needs to check for CAP_ADMIN*
* $DEV/xen/xenstored
  - Module xen-control or so
  - Merges xsd_kva and xsd_port
  - Supports:
    - mmap, only support pagesized maps
    - ioctl: get event channel port, get size (page size may be different)
  - Security constraints needs check. What can a user with access to
    this device do?
* Core kernel may trigger loading of xen-control module by some means
  (to be defined).

> If that stuff got moved somewhere 'better', it would be fine to update the
> tools to check both new and old locations.

I would start with adding the new stuff then check the tools to work
with both and just ignore for another merge try or remove xenfs later.

Bastian

-- 
Power is danger.
		-- The Centurion, "Balance of Terror", stardate 1709.2