Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Decision from Community Call: firewall functions move into own driver

...

  • Argo is now in upstream Xen and correspondingly the Linux driver needs to be prepared for upstreaming to the Linux kernel
  • The driver should expose two separate interfaces: a vsock interface and a character device
    • The driver should be built as a common argo-core – along the lines of uXen's uxenv4vlib –  with both char and vsock drivers then leveraging argo-core
    • Using the existing socket-like interface on the character device does not depend on availability of a network stack
      • Potentially useful for minimal services VMs
      • Change requested: "The char driver behavior should be reduced back to that of a conventional Linux char driver"
    • Xen’s Argo interface will change to support message labeling
    • How should either the vsock or chardev interfaces support Argo-specific functionality?
      • ie. Is the chardev interface the correct interface between userspace and the kernel to provide support for Argo-specific, non-traditional character device, functionality?
        • eg. Configuring ring size
  • The proposal for an Argo name service will need consideration of how names interact with this driver.
  • The Argo firewall is currently not in upstream Xen, pending implementation of bi-directional connection tracking in OpenXT before upstreaming. The Linux driver is used to access and configure the firewall.
    • Should the The firewall functions should be moved out to into a separate Linux device driver?.


Summary: the driver will need to provide:

...