New APIs: base64-in and base64-out for uploading/downloading base64 content.
[libguestfs.git] / TODO
diff --git a/TODO b/TODO
index bfcc477..56b429a 100644 (file)
--- a/TODO
+++ b/TODO
@@ -6,39 +6,16 @@ to libguestfs in future.
 
    - RWMJ
 
-Python bindings
----------------
-
-Ideas for the Python bindings:
-https://www.redhat.com/archives/fedora-virt/2009-April/msg00114.html
+FUSE API
+--------
 
-FTP server or FUSE?
--------------------
+The API needs more test coverage, particularly lesser-used system
+calls.
 
-Originally we had intended to implement an NFS server inside the
-appliance, which would allow the guest filesystems to be mounted on
-the host, and large changes to be made.  We eventually rejected the
-idea of using NFS, partly because it requires root to mount
-filesystems in the host, and partly because of problems handling UID
-mappings between host and guest filesystem.
-
-Then we look at implementing an FTP server instead.  FTP clients are
-widely available for many languages, don't require root, and don't
-have any UID mapping problems.  However there is the problem of
-getting the TCP connection into the guest, and that FTP requires a
-secondary data connection either in or out of the guest (the NFS
-situation is even more dire).
-
-Thirdly we looked at implementing a FUSE-based filesystem.  This is
-plausible - it could be implemented just by adding the additional FUSE
-operations to the standard guestfs(3) API, and then implementing a
-simple FUSE daemon.  (The FUSE website has some very helpful
-documentation and examples).  I [RWMJ] am not particularly convinced
-that a FUSE-based filesystem would really be useful to anyone, but am
-prepared to accept patches if someone does all the work.
-
-See also the mountlo project:
-http://sourceforge.net/project/showfiles.php?group_id=121684&package_id=150116
+The big unresolved issue is UID/GID mapping between guest filesystem
+IDs and the host.  It's not easy to automate this because you need
+extra details about the guest itself in order to get to its
+UID->username map (eg. /etc/passwd from the guest).
 
 BufferIn
 --------
@@ -117,23 +94,6 @@ This is mainly useful from live CDs, ie. virt-p2v.
 Should we bother having the daemon at all and just link the guestfsd
 code directly into libguestfs?
 
-PPC problems
-------------
-
-[This section should be filed as bugs, but no one seems to care for
-PPC hosts and the hardware is rapidly becoming obsolete]
-
-  ppc (32 bit) works with qemu from git, however there is no serial console
-
-  ppc64 requires extra parameters:
-    -M mac99 -cpu ppc64
-  however it still fails:
-    invalid/unsupported opcode: 01 - 01 - 1a (06301e83) 00000000018c2738 1
-    invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 0000000000009230
-
-  no serial console in ppc or ppc64 because no one can tell us what
-  console=ttyXX option to use
-
 Supermin appliance to febootstrap
 ---------------------------------
 
@@ -144,10 +104,7 @@ Ideas for extra commands
 
   General glibc / core programs:
     chgrp
-    dd (?)
-    utime / utimes / futimes / futimens / l..
     more mk*temp calls
-    trunc[ate??]
 
   ext2 properties:
     chattr
@@ -214,7 +171,7 @@ Quick Perl scripts
 Currently we can't do Perl "one-liners".  ie. The current syntax for
 any short Perl one-liner would be:
 
-  perl -MSys::Guestfs -e '$g = Sys::Guestfs->new(); $g->add_drive ("foo"); $g->launch; $g->wait_ready; $g->mount ("/dev/sda1", "/"); ....'
+  perl -MSys::Guestfs -e '$g = Sys::Guestfs->new(); $g->add_drive ("foo"); $g->launch; $g->mount ("/dev/sda1", "/"); ....'
 
 You can see we're well beyond a single line just getting to the point
 of adding drives and mounting.
@@ -235,7 +192,6 @@ which is equivalent to the following sequence of calls:
  $h->set_autosync (1);
  $h->add_drive_ro ($filename);
  $h->launch ();
- $h->wait_ready ();
  $h->mount_ro (\"/dev/sda1\", \"/\");
 
 Command-line form would be:
@@ -265,3 +221,53 @@ quickly, eg:
   load ext2
 
 Maybe it's better to create these on the fly?
+
+virt-rescue pty
+---------------
+
+See:
+http://search.cpan.org/~rgiersig/IO-Tty-1.08/Pty.pm
+http://www.perlmonks.org/index.pl?node_id=582185
+
+Note that pty requires cooperation inside the C code too (there are
+two sides to a pty, and one has to be handled after the fork).
+
+Windows-based daemon/appliance
+------------------------------
+
+See discussion on list:
+https://www.redhat.com/archives/libguestfs/2009-November/msg00165.html
+
+qemu locking
+------------
+
+Add -drive file=...,lock=exclusive and -drive file=...,lock=shared
+
+Change libguestfs and libvirt to do the right thing, so that multiple
+instances of qemu cannot stomp on each other.
+
+virt-disk-explore
+-----------------
+
+For multi-level disk images such as live CDs:
+http://rwmj.wordpress.com/2009/07/15/unpack-the-russian-doll-of-a-f11-live-cd/
+
+It's possible with libguestfs to recursively look for anything that
+might be a filesystem, mount-{,loop} it and look in those, revealing
+anything in a disk image.
+
+However this won't work easily for VM disk images in the disk image.
+One would have to download those to the host and launch another
+libguestfs instance.
+
+List, mount filesystems by UUID and label
+-----------------------------------------
+
+[See related:
+http://www.redhat.com/archives/libguestfs/2009-August/msg00031.html]
+
+List filesystems by UUID or label.
+
+Mount filesystems by UUID or label.  (I'm not really sure if we can do
+this at the moment but we ought to be able to do it, and perhaps make
+it easier by having a direct command).