Skip to content

OpenXT Task List

Jump to bottom Edit New page
dickon edited this page Oct 9, 2014 · 31 revisions

Task List - A Starting Point

This is a first cut of putting together a task list of things that need to get done or we would like to get done. Each top item may has a sub-list of smaller tasks listed. Many of these items were on other people's lists too (others involved in the OpenXT project). I am not including effort/time estimates or trying to prioritize these items at this time. I started it here on this wiki so it can be discussed, modified, added to, etc. Eventually we would want to get these items into Jira (and the details of how to do that may need discussion also). I did not use a table because they are not very friendly when using the Github wikis. Please feel free to edit...

List

Update TBOOT

Our current TBOOT if quite old. It needs a serious upgrade to the latest. This would be an ongoing task as new TBOOT versions are released. Update schedules would have to be carefully planned.

  • Update to the newest TBOOT.
  • Clean up the patch queue and upstream patches where possible.
  • Update TPM tools and remove custom ones (Phil knows about this).

Update Xen

We would like to track upstream as closely as possible and minimize our patch queue. This would be an ongoing task as new Xen versions are released. Update schedules would have to be carefully planned.

  • Update to Xen 4.5 (or newer).
  • Clean up the patch queue and upstream patches where possible.

Update Dom0 Kernel

Again, we would like to track upstream as closely as possible and minimize our patch queue. This would be an ongoing task as new Kernel versions are released or new hardware support is needed. Update schedules would have to be carefully planned.

  • Update to latest reasonable Linux 3.x.
  • Clean up the patch queue.

Update QEMU

Currently OpenXT is moving to 1.4. The next step would be to move even further upstream. This might not be as regular a move as with Xen or Linux.

  • Finish move to 1.4 (in progress).
  • TODO other items here?

Open Embedded Enhancements

TODO leaving mostly this for others to fill in.

  • Update OE to "dizzy"
  • Remove/eliminate redundant recipes that conflict/overlap with upstream
  • Upstream recipes that aren't openxt-specific package but might find a good home in another upstream layer.
  • Uprev bitbake & upstream/eliminate bitbake patches/classes where possible.
  • simplify do_build.sh, finding what solutions the OE community use to the work done in it and adopting or innovating in OE where possible.
  • look at moving back to the standard OE approach of referencing the openxt repositories by commit ID and secure content hash rather by branch. As well as making OpenXT less unusual this would make versioning simpler since you'd need to consider versions in many fewer repositories which makes consistent updates to OpenXT easier (get your work merged into central repositories and then later get the updates made to openxt's OE recipes to move standard builds over to it). We'd still need good workflows for developers to test their changes to OpenXT specific components.

PV USB

This is a blanket item to cover all the PV USB work. Some of the specifics...

  • Stabilize the new PV USB solution in OpenXT (in progresss)
  • Create a Linux front end driver (in progress)
  • Upstream the drivers into Linux and the XenServer Windows PV drivers.
  • USB 3

Dependencies: XenServer PV Windows Drivers

XenServer PV Windows Drivers

The current PV driver set is a very old version of the XenServer drivers. People on the XenServer and platform teams at Citrix did a huge amount of work to open source the latest XenServer drivers and it seems they are becoming the industry standard: https://github.com/xenserver

  • Integrate the XenServer PV Windows drivers into OpenXT (building/packaging/etc).
  • Make OpenXT additional drivers work with the XenServer drivers (esp. xenbus).
  • Modification to the SDK Windows bits to use the new XenServer drivers.

UEFI Support

There may come a time when we see vendors begin to not support CSMs in their UEFI firmware any longer. OpenXT needs to be prepared for that. This mainly means supporting UEFI booting through GRUB2 using multiboot2 structures. For OpenXT this means TBOOT, Xen and Dom0 must have these new multiboot2 capabilities. It also means supporting GPT partitioning.

  • Updated TBOOT with multiboot2/EFI support.
  • Updated Xen with multiboot2/EFI support.
  • Ensure Dom0 kernel support for multiboot2/EFI.
  • Installer changes for supporting GPT.
  • Platform changes for supporting GPT.

Dependencies: Update TBOOT, Update Xen

Toolsack Core Changes

This seems like a very broad item but here it is specifically addressing the core pieces like xenmgr->xenvm->libxc.

  • Documentation! Especially the Haskell and OCaml bits. This will help make some of the other decisions.
  • The future of the Ocaml code and moving to libxl (or something else).
  • Investigations into how well libxl scales.
  • The future of the Haskell code and what to do with xenmgr and friends.
  • Domain startup is tricky ... qemu-wrapper/dm-agent/svirt/.../qemu. We should do something about that (documentation at least).

Graphics Stack

TODO leaving this for others to fill in.

Input Server Changes

The input server definitely needs a major overhaul and may need a complete redoing (to be seen).

  • First need a specification or RFC document as a starting point.
  • Using libinput was brought up as a possibility.
  • Changes to support new graphics stack.
  • Superhid implementation.

Dependencies: PV USB, Graphics Stack

Interdomain Communications

We have V4V currently. Do we push forward with it and fix it or consider another approach like one of the grant models. Note that V4V will never be upstreamed into Xen so this is a rather largish nail in the coffin.

  • RFC and discussions on how to proceed.
  • Possibly fixing V4V. This would also mean porting the Windows driver to the XenServer xenbus.
  • Fixing V4V also entails addressing issues that came up during the open source effort as well as known bugs.
  • V4V should have a socket class too.
  • Possibly using a grant model like libvchan. This would require writing a lot of new stuff.

Dependencies: XenServer PV Windows Drivers

Standardize RPC Communications

OpenXT currently has multiple RPC mechanisms and no real standards for interfaces and proxies etc.

  • DBus/DMBus, keep both move to just one of them? (DMBus and DBus overlap most of the time...)
  • Some DBus messages should be DMBus unless we decide to drop DMBus.
  • Bouncers & proxies should have libraries with interface handling and be consistent.
  • Statically linked binaries in stubdoms contributes to this mess and is unnecessary.

Audio Improvements

Really kind of a general bucket for audio related tasks and issues.

  • We don't even have PV audio support. We should.
  • Audio microphone.

Sync XT Improvements

  • implement postgresql as an alternative (or replacement if we can do migration?) to the use of the Oracle RDBMS.
  • selinux policy for the server
  • selinux policy for the client syncvm
  • an open source web interface for SyncXT
Add a custom footer
Add a custom sidebar
Clone this wiki locally