0
  $   1ˆl–Ãa¾”ªClÊq@‚àAq·TÅ£Õ„a|?ÔÁÒ ;W    1/* SPDX-License-Identifier: LGPL-2.0+ WITH Linux-syscall-note */
/*
 * Copyright (C) 2006-2009 Red Hat, Inc.
 *
 * This file is released under the LGPL.
 */

#ifndef __DM_LOG_USERSPACE_H__
#define __DM_LOG_USERSPACE_H__

#include <linux/types.h>
#include <linux/dm-ioctl.h> /* For DM_UUID_LEN */

/*
 * The device-mapper userspace log module consists of a kernel component and
 * a user-space component.  The kernel component implements the API defined
 * in dm-dirty-log.h.  Its purpose is simply to pass the parameters and
 * return values of those API functions between kernel and user-space.
 *
 * Below are defined the 'request_types' - DM_ULOG_CTR, DM_ULOG_DTR, etc.
 * These request types represent the different functions in the device-mapper
 * dirty log API.  Each of these is described in more detail below.
 *
 * The user-space program must listen for requests from the kernel (representing
 * the various API functions) and process them.
 *
 * User-space begins by setting up the communication link (error checking
 * removed for clarity):
 *	fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR);
 *	addr.nl_family = AF_NETLINK;
 *	addr.nl_groups = CN_IDX_DM;
 *	addr.nl_pid = 0;
 *	r = bind(fd, (struct sockaddr *) &addr, sizeof(addr));
 *	opt = addr.nl_groups;
 *	setsockopt(fd, SOL_NETLINK, NETLINK_ADD_MEMBERSHIP, &opt, sizeof(opt));
 *
 * User-space will then wait to receive requests form the kernel, which it
 * will process as described below.  The requests are received in the form,
 * ((struct dm_ulog_request) + (additional data)).  Depending on the request
 * type, there may or may not be 'additional data'.  In the descriptions below,
 * you will see 'Payload-to-userspace' and 'Payload-to-kernel'.  The
 * 'Payload-to-userspace' is what the kernel sends in 'additional data' as
 * necessary parameters to complete the request.  The 'Payload-to-kernel' is
 * the 'additional data' returned to the kernel that contains the necessary
 * results of the request.  The 'data_size' field in the dm_ulog_request
 * structure denotes the availability and amount of payload data.
 */

/*
 * DM_ULOG_CTR corresponds to (found in dm-dirty-log.h):
 * int (*ctr)(struct dm_dirty_log *log, struct dm_target *ti,
 *	      unsigned argc, char **argv);
 *
 * Payload-to-userspace:
 *	A single string containing all the argv arguments separated by ' 's
 * Payload-to-kernel:
 *	A NUL-terminated string that is the name of the device that is used
 *	as the backing store for the log data.  'dm_get_device' will be called
 *	on this device.  ('dm_put_device' will be called on this device
 *	automatically after calling DM_ULOG_DTR.)  If there is no device needed
 *	for log data, 'data_size' in the dm_ulog_request struct should be 0.
 *
 * The UUID contained in the dm_ulog_request structure is the reference that
 * will be used by all request types to a specific log.  The constructor must
 * record this association with the instance created.
 *
 * When the request has been processed, user-space must return the
 * dm_ulog_request to the kernel - setting the 'error' field, filling the
 * data field with the log device if necessary, and setting 'data_size'
 * appropriately.
 */
#define DM_ULOG_CTR                    1

/*
 * DM_ULOG_DTR corresponds to (found in dm-dirty-log.h):
 * void (*dtr)(struct dm_dirty_log *log);
 *
 * Payload-to-userspace:
 *	A single string containing all the argv arguments separated by ' 's
 * Payload-to-kernel:
 *	None.  ('data_size' in the dm_ulog_request struct should be 0.)
 *
 * The UUID contained in the dm_ulog_request structure is all that is
 * necessary to identify the log instance being destroyed.  There is no
 * payload data.
 *
 * When the request has been processed, user-space must return the
 * dm_ulog_request to the kernel - setting the 'error' field and clearing
 * 'data_size' appropriately.
 */
#define DM_ULOG_DTR                    2

/*
 * DM_ULOG_PRESUSPEND corresponds to (found in dm-dirty-log.h):
 * int (*presuspend)(struct dm_dirty_log *log);
 *
 * Payload-to