Re: [Libguestfs] APIs affected by btrfs subvolumes
On Tue, 2013-01-22 at 15:15 +0000, Richard W.M. Jones wrote:
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.
I'd make 1 change to this. Where a mountable isn't a bare device I'd put
the device type first as I originally proposed. The reason for this is
that a mountable doesn't necessarily reference a single block device, or
indeed any block device (think nfs and iscsi). Also, I'd differentiate
btrfs and a btrfs subvol. The former can be a bare device, the latter:
btrfsvol:<device>,<subvolume_name>
where <device> is any block device which is part of the filesystem.
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).
Hmm. I missed RHashtable in my search. I'd better check for others.
'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
RESOLVE_MOUNTABLE).
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.
With the minor tweak above, I like this.
It does change the semantics slightly, though. Previously, a program
could assume that something returned by list_filesystems or inspect_os
was a block device and use it as such, whereas now it can't. However, as
you point out that was already broken. This change would mean it would
be broken differently, though. How much do we care about this?
I'm happy to start hacking on this now,
Matt