local-allocator-interface.c

gistfile1.c

/* some opaque handle */
struct allocator;

/* Allocate and return an allocator. Non-blocking. Won't communicate
   on the rings */
struct allocator *alloc();

/* Read the config file; Examine the block device (to discover sector
   size); Suspend and resume the ring to synchronise and discover the
   free block list. Blocking. When this returns it is possible to
   allocate. Spawns a background thread which reads free blocks from
   the ring and adds them to the free block list. */
void connect(struct allocator *a);

/* Represents physical extents allocated from the free pool */
struct blocks;

/* Allocates nr_extents physical extents from the local host's free
   pool. This will block until it can return at least one extent. If
   the full request cannot be satisfied it will return short. */
struct blocks allocate(struct allocator *a, int nr_extents);

/* Represents a potentially-uncommitted write to the tolvm ring */
typedef uint64_t tolvm_push;

/* Write the idempotent LV block assignment to the ToLVM ring. The operation
   is not exposed until the allocator_tolvm_advance function is called.
   Blocks until enough free space is available. */
tolvm_push tolvm_push(struct allocator *a, struct lvextend *op);

/* Extends a device mapper target with blocks we've allocated */
void extend_device_mapper(struct lvextend *op, const char *target);

/* Expose the LV block assignment to xenvmd by advancing the producer
   pointer. Non-blocking. */
void tolvm_advance(struct allocator *a, tolvm_push push);

/* Notes on journalling:
 *
 * When an lvextend request comes in, the client needs to call
 * allocate() to get some extents, and then compute the needed
 * changes to both the LV metadata and the device mapper -- this
 * is represented in the 'struct lvextend' above. This needs to be
 * journalled locally so that it survives a local process crash
 * before any of the side-effects are performed.
 * Once the operation has been committed to the journal, it can
 * be executed by:
 * 1. tolvm_push
 * 2. extend_device_mapper
 * 3. tolvm_advance
 * (I don't think the order matters there)
 */

what's the lvextend struct? Will that be opaque too?

Looking at the interface it looks like lvextend struct should not be opaque but should be well defined since the user of the interface will need to fill it in, no?

Do we also need a free function to free the structure allocated by "alloc" ?
It is like a init without uninit.