Lib.pm: Use 'file' as replacement for 'zfile'.
[libguestfs.git] / TODO
diff --git a/TODO b/TODO
index 8e3a184..291d220 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,60 +1,84 @@
-Ideas for the Python bindings:
-https://www.redhat.com/archives/fedora-virt/2009-April/msg00114.html
+TODO list for libguestfs
+======================================================================
+
+This list contains random ideas and musings on features we could add
+to libguestfs in future.
 
-----------------------------------------------------------------------
+   - RWMJ
 
-We badly need to actually implement the FTP server mentioned in the
-documentation.
+Python bindings
+---------------
 
-Or: Implement a FUSE-based filesystem.  See the FUSE mountlo
-project which does something similar, albeit only to single
-filesystems:
+Ideas for the Python bindings:
+https://www.redhat.com/archives/fedora-virt/2009-April/msg00114.html
 
+FTP server or FUSE?
+-------------------
+
+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
 
-----------------------------------------------------------------------
+BufferIn
+--------
+
+BufferIn should turn into <char *, int> and simple strings in other
+languages that can handle 8 bit clean strings.
 
-BufferIn and BufferOut should turn into <char *, int> and simple
-strings in other languages that can handle 8 bit clean strings.
 Limit on transfers would still be 2MB for these types.
  - then implement write-file properly
- - and implement read-file
 
-----------------------------------------------------------------------
+febootstrap / debootstrap inside appliance
+------------------------------------------
 
-Implement febootstrap command.
+This was originally proposed as a way to install new operating systems
+in the appliance.  However no one has come up with a workable
+solution.
 
-----------------------------------------------------------------------
+Haskell bindings
+----------------
 
 Complete the Haskell bindings (see discussion on haskell-cafe).
 
-----------------------------------------------------------------------
-
-Complete the bindings tests - must test the return values and
-error cases.
-
-----------------------------------------------------------------------
-
-For virt-inspector:
-
- - Make a libvirt XML config
+Complete bind tests
+-------------------
 
- - Test over available OSes
+Complete the bind tests - must test the return values and error cases.
 
- - Add 'reged' / NT registry support.
+virt-inspector - make libvirt XML
+---------------------------------
 
-----------------------------------------------------------------------
+It should be possible to generate libvirt XML from virt-inspector
+data, at least partially.  This would be just another output type so:
 
-Use virtio_blk by default.  It's faster and more natural.
-Unfortunately it seems like this will rename all devices - see next
-item.
+ virt-inspector --libvirt guest.img
 
-Note: virtio_blk *IS* supported by all our minimum platforms,
-ie. CentOS 5.3, Fedora 11, Debian.
-
-----------------------------------------------------------------------
+Note that recent versions of libvirt/virt-install allow guests to be
+imported, so this is not so useful any more.
 
 "Standalone/local mode"
+-----------------------
 
 Instead of running guestfsd (the daemon) inside qemu, there should be
 an option to just run guestfsd directly.
@@ -93,9 +117,11 @@ 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
+------------
 
-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
 
@@ -108,25 +134,22 @@ PPC problems:
   no serial console in ppc or ppc64 because no one can tell us what
   console=ttyXX option to use
 
-----------------------------------------------------------------------
-
-Supermin appliance should be moved into febootstrap.
+Supermin appliance to febootstrap
+---------------------------------
 
-----------------------------------------------------------------------
+Supermin appliance functionality should be moved into febootstrap.
 
-Extra commands / functionality:
+Ideas for extra commands
+------------------------
 
   General glibc / core programs:
     chgrp
     grep (do it locally using pipe?)
     dd (?)
     ln / ln -s
-    mknod
     readlink
     utime / utimes / futimes / futimens / l..
-    mkfifo
     more mk*temp calls
-    readdir / readdir-and-stat
     some sort of alloc/fallocate/posix_fallocate call to create empty space
     realpath
     trunc[ate??]
@@ -154,15 +177,13 @@ Extra commands / functionality:
     pivot_root
     fts(3) / ftw(3)
 
-----------------------------------------------------------------------
+Swap space
+----------
 
 Allow swap space from the guest to be used.  Is it a good idea?
 
-----------------------------------------------------------------------
-
-Allow memsize to be configured (ie. guestfs_set_memsize etc)
-
-----------------------------------------------------------------------
+Query guest architecture
+------------------------
 
 Need a way to query a binary or library file for its architecture.
 Using objdump or readelf?
@@ -177,9 +198,80 @@ similar to virt-inspector.
 Probably we should go all the way and have virt-inspector able to
 determine kernel and userspace architectures of guests.
 
-----------------------------------------------------------------------
+Other initrd-* commands
+-----------------------
 
-Other initrd-* commands, such as:
+Such as:
 
 initrd-extract
 initrd-replace
+
+Simple editing of configuration files
+-------------------------------------
+
+Some easy non-Augeas methods to edit configuration files.
+I'm thinking:
+
+  replace /etc/file key value
+
+which would look in /etc/file for any instances of
+
+  key=...
+  key ...
+  key:...
+
+and replace them with
+
+  key=value
+  key value
+  key:value
+
+That would solve about 50% of reconfiguration needs, and for the
+rest you'd use Augeas, 'download'+'upload' or 'edit'.
+
+RWMJ: I had a go at implementing this, but it's quite error-prone to
+do this sort of editing inside the C-based daemon code.  It's far
+better to do it with Augeas, or else to use an external language like
+Perl.
+
+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", "/"); ....'
+
+You can see we're well beyond a single line just getting to the point
+of adding drives and mounting.
+
+First suggestion:
+
+ $h = create ($filename, \"/dev/sda1\" => \"/\");
+
+ $h = create ([$file1, $file2], \"/dev/sda1\" => \"/\");
+
+To mount read-only, add C<ro =E<gt> 1> like this:
+
+ $h = create ($filename, \"/dev/sda1\" => \"/\", ro => 1);
+
+which is equivalent to the following sequence of calls:
+
+ $h = Sys::Guestfs->new ();
+ $h->set_autosync (1);
+ $h->add_drive_ro ($filename);
+ $h->launch ();
+ $h->wait_ready ();
+ $h->mount_ro (\"/dev/sda1\", \"/\");
+
+Command-line form would be:
+
+ perl -MSys::Guestfs=:all -e '$_=create("guest.img", "/dev/sda1" => "/"); $_->cat ("/etc/fstab");'
+
+That's not brief enough for one-liners, so we could have an extra
+autogenerated module which creates a Sys::Guestfs handle singleton
+(the handle is an implicit global variable as in guestfish), eg:
+
+ perl -MSys::Guestfs::One -e 'inspect("guest.img"); cat ("/etc/fstab");'
+
+How would editing files work?