[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] APIs affected by btrfs subvolumes

Here's my suggestion.

We add a new type 'Mountable' to the generator.  This is the same as a
string, so it doesn't change the strict C ABI (nor the semantics --
see below).  Certain APIs that take a Device parameter would need to
change to take a Mountable instead.

Certain APIs that return RString/RStringList won't change their
generator types, but what can be in the string may change.

A Mountable string is normally just a device name, eg. "/dev/sda1".
But for special filesystems it may contain an extended string.  I
suggest "/dev/sda1:btrfs:<subvolume_name>" for btrfs.  Other weird
filesystems may need other extensions in future.

Inspection APIs take and return a Mountable (so Device "root" becomes
Mountable "root").

'list-filesystems' returns a list of Mountables (actually it still
returns an RStringList, but it's a list of Mountables).

'mount' and friends take a Mountable instead of a Device.

The generator will need to make a small change in the way it checks
the Mountable parameter at runtime (q.v. the way Device is checked
now, eg. the macro RESOLVE_DEVICE will need another macro

Obviously the ABI doesn't change, since it's all still strings.  But I
also claim that the semantics of the API don't change: Any existing
program that works now will continue to work unchanged.  Only programs
that would now fail (eg. they try to inspect btrfs guests) would be
affected by this change, and in fact those programs would not need to
be modified, they would just start to work correctly.


Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]