search for: nvmet_subsys

...e); } static void nvmet_clear_ctrl(struct nvmet_ctrl *ctrl) diff --git a/drivers/nvme/target/nvmet.h b/drivers/nvme/target/nvmet.h index 9335584..eac008b 100644 --- a/drivers/nvme/target/nvmet.h +++ b/drivers/nvme/target/nvmet.h @@ -59,6 +59,9 @@ struct nvmet_ctrl { struct kref ref; #define NVMET_SUBSYS_NAME_LEN 256 char subsys_name[NVMET_SUBSYS_NAME_LEN]; + + void *opaque; + void (*start)(void *); }; struct nvmet_subsys { -- 1.9.1

On Thu, Nov 19, 2015 at 04:21:03PM -0800, Ming Lin wrote: > #define NVMET_SUBSYS_NAME_LEN 256 > char subsys_name[NVMET_SUBSYS_NAME_LEN]; > + > + void *opaque; > + void (*start)(void *); > }; Why can't vhost use container_of to get at the containing structure similar to what the loop driver does? In addition I think we'll eventually need an ops...

Hi, This is the first attempt to add a new qemu nvme backend using in-kernel nvme target. Most code are ported from qemu-nvme and also borrow code from Hannes Reinecke's rts-megasas. It's similar as vhost-scsi, but doesn't use virtio. The advantage is guest can run unmodified NVMe driver. So guest can be any OS that has a NVMe driver. The goal is to get as good performance as

Hi, This is the first attempt to add a new qemu nvme backend using in-kernel nvme target. Most code are ported from qemu-nvme and also borrow code from Hannes Reinecke's rts-megasas. It's similar as vhost-scsi, but doesn't use virtio. The advantage is guest can run unmodified NVMe driver. So guest can be any OS that has a NVMe driver. The goal is to get as good performance as