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

[Libguestfs] Proposed new libguestfs file APIS

As part of a new virt-v2v feature, I've been thinking about how to write data to an arbitrary block device in the appliance. I need to be able to write arbitrary chunks of data to specific places on the device. This will need a new API, as guestfs_pread can't open a block device. While I'm at it, I'd like to create a new family of APIs which operate on a file handle:

int guestfs_open_device(g, path);
  Open a block device. Return a handle.

int guestfs_open_file(g, path);
  Open a file from the guest's filesystem. Return a handle.

int guestfs_close_handle(g, handle);
  Close a file handle.

ssize_t guestfs_hpread(g, handle, buf, size, offset);
ssize_t guestfs_hread(g, handle, buf, size);
ssize_t guestfs_hpwrite(g, handle, buf, size, offset);
ssize_t guestfs_hwrite(g, handle, buf, size);
Wrappers round pread(), read(), pwrite() and write() which operate on a handle.

ssize_t guestfs_hseek(g, handle, offset, whence);
  Wrapper round lseek().

int guestfs_htruncate(g, handle, length);
  Wrapper round ftruncate().

In terms of the API, the handle would be an opaque int. In practise it would be a file descriptor owned by guestfsd.

I believe these APIs could result in a performance improvement over opening a file repeated. However, I have no data to back this up at present.

Aside from any potential performance improvement I believe these APIs are a better interface for the developer when doing low level file operations in the guest.

Comments before I code this up?


Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

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