> +static void xen_blk_trim(struct xen_blkif *blkif, struct blkif_request *req)
Just call it discard: s/trim/discard/ through all the patches.
Also make sure you do that for the functions. And for the 'tr' - change it to
'discard' maybe?
.. snip..
> +int xen_blkbk_trim(struct xenbus_transaction xbt, struct backend_info *be)
Call it discard.
.. snip ..
> + err = xenbus_printf(xbt, dev->nodename, "feature-trim",
>From one hand it would be really nice to call this 'feature-discard'
but the Citrix frontends (and perhaps the SuSE ones too?) expect
it as 'feature-trim'. Maybe we should just call it 'feature-discard'
here and add a backwards compatible patch that will call it
'feature-trim'?
Sadly, the 'feature-trim' has been enumareted in the blkif.h so it
kind of is written in stone.
Keir, what is your feeling on this?
Can we change the name to 'feature-discard'?
> + "%d", state);
> + if (err)
> + xenbus_dev_fatal(dev, err, "writing feature-trim");
> +kfree:
> + kfree(type);
> +out:
> + return err;
> +}
> +
> /*
> * Entry point to this code when a new device is created. Allocate the basic
> * structures, and watch the store waiting for the hotplug scripts to tell us
> @@ -650,6 +708,10 @@ again:
> if (err)
> goto abort;
>
> + err = xen_blkbk_trim(xbt, be);
> + if (err)
> + goto abort;
> +
No need really. We don't need to abort b/c we can't establish discard
support.
> err = xenbus_printf(xbt, dev->nodename, "sectors", "%llu",
> (unsigned long long)vbd_sz(&be->blkif->vbd));
> if (err) {
> --
> 1.7.6
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home