[Xen-devel] Re: <missing subject>

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

        >>> On 18.08.11 at 11:35, Li Dongyang <lidongyang@xxxxxxxxxx> wrote:
> JBeulich@xxxxxxxxxx 
> Subject: [PATCH V2 1/3] xen-blkfront: add BLKIF_OP_TRIM and backend type 
> flags
> Date: Thu, 18 Aug 2011 17:34:29 +0800
> Message-Id: <1313660071-25230-2-git-send-email-lidongyang@xxxxxxxxxx>
> X-Mailer: git-send-email 1.7.6
> In-Reply-To: <1313660071-25230-1-git-send-email-lidongyang@xxxxxxxxxx>
> References: <1313660071-25230-1-git-send-email-lidongyang@xxxxxxxxxx>
> 
> This adds the BLKIF_OP_TRIM for blkfront and blkback, also 2 flags telling
> us the type of the backend, used in blkback to determine what to do when we
> see a trim request.
> Part of the patch is just taken from Owen Smith, Thanks
> 
> Signed-off-by: Owen Smith <owen.smith@xxxxxxxxxx>
> Signed-off-by: Li Dongyang <lidongyang@xxxxxxxxxx>
> ---
>  include/xen/interface/io/blkif.h |   21 +++++++++++++++++++++
>  1 files changed, 21 insertions(+), 0 deletions(-)
> 
> diff --git a/include/xen/interface/io/blkif.h 
> b/include/xen/interface/io/blkif.h
> index 3d5d6db..b92cf23 100644
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -57,6 +57,19 @@ typedef uint64_t blkif_sector_t;
>   * "feature-flush-cache" node!
>   */
>  #define BLKIF_OP_FLUSH_DISKCACHE   3
> +
> +/*
> + * Recognised only if "feature-trim" is present in backend xenbus info.
> + * The "feature-trim" node contains a boolean indicating whether barrier
> + * requests are likely to succeed or fail. Either way, a trim request
> + * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
> + * the underlying block-device hardware. The boolean simply indicates 
> whether
> + * or not it is worthwhile for the frontend to attempt trim requests.
> + * If a backend does not recognise BLKIF_OP_TRIM, it should *not*
> + * create the "feature-trim" node!
> + */
> +#define BLKIF_OP_TRIM            5
> +
>  /*
>   * Maximum scatter/gather segments per request.
>   * This is carefully chosen so that sizeof(struct blkif_ring) <= PAGE_SIZE.
> @@ -74,6 +87,11 @@ struct blkif_request_rw {
>       } seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  };
>  
> +struct blkif_request_trim {
> +     blkif_sector_t sector_number;
> +     uint64_t nr_sectors;
> +};
> +
>  struct blkif_request {
>       uint8_t        operation;    /* BLKIF_OP_???                         */
>       uint8_t        nr_segments;  /* number of segments                   */
> @@ -81,6 +99,7 @@ struct blkif_request {
>       uint64_t       id;           /* private guest value, echoed in resp  */
>       union {
>               struct blkif_request_rw rw;
> +             struct blkif_request_trim trim;
>       } u;
>  };
>  
> @@ -109,6 +128,8 @@ DEFINE_RING_TYPES(blkif, struct blkif_request, struct 
> blkif_response);
>  #define VDISK_CDROM        0x1
>  #define VDISK_REMOVABLE    0x2
>  #define VDISK_READONLY     0x4
> +#define VDISK_FILE_BACKEND 0x8
> +#define VDISK_PHY_BACKEND  0x10

As noted before - you use these only internally to your backend
change, which is no reason to make these part of the interface
(which you'd have to propose against the xen-unstable tree first
anyway).

Jan

>  
>  /* Xen-defined major numbers for virtual disks, they look strangely
>   * familiar */





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel