From: Richard W.M. Jones Date: Fri, 24 Jul 2009 13:36:50 +0000 (+0100) Subject: Reformat the TODO file. X-Git-Tag: 1.0.65~23 X-Git-Url: http://git.annexia.org/?a=commitdiff_plain;h=d296feb05fbbd331a4ae3ed3e18bb822acdc13c8;p=libguestfs.git Reformat the TODO file. --- diff --git a/TODO b/TODO index 16d6880..3241b36 100644 --- a/TODO +++ b/TODO @@ -1,18 +1,47 @@ -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. -We badly need to actually implement the FTP server mentioned in the -documentation. + - RWMJ -Or: Implement a FUSE-based filesystem. See the FUSE mountlo -project which does something similar, albeit only to single -filesystems: +Python bindings +--------------- + +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 and simple strings in other languages that can handle 8 bit clean strings. @@ -20,41 +49,36 @@ languages that can handle 8 bit clean strings. Limit on transfers would still be 2MB for these types. - then implement write-file properly ----------------------------------------------------------------------- +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: +Complete bind tests +------------------- - - Make a libvirt XML config +Complete the bind tests - must test the return values and error cases. - - Test over available OSes +virt-inspector - make libvirt XML +--------------------------------- - - Add 'reged' / NT registry support. +It should be possible to generate libvirt XML from virt-inspector +data, at least partially. This would be just another output type so: ----------------------------------------------------------------------- + virt-inspector --libvirt guest.img -Use virtio_blk by default. It's faster and more natural. -Unfortunately it seems like this will rename all devices - see next -item. - -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,13 +134,13 @@ PPC problems: no serial console in ppc or ppc64 because no one can tell us what console=ttyXX option to use ----------------------------------------------------------------------- +Supermin appliance to febootstrap +--------------------------------- -Supermin appliance should be moved into febootstrap. +Supermin appliance functionality should be moved into febootstrap. ----------------------------------------------------------------------- - -Extra commands / functionality: +Ideas for extra commands +------------------------ General glibc / core programs: chgrp @@ -151,11 +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? ----------------------------------------------------------------------- +Query guest architecture +------------------------ Need a way to query a binary or library file for its architecture. Using objdump or readelf? @@ -170,14 +198,16 @@ 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: @@ -198,3 +228,19 @@ and replace them with 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.