diff for duplicates of <1503951680.4860.3.camel@linux.intel.com> diff --git a/a/1.txt b/N1/1.txt index 095e664..5971dcb 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,11 +1,11 @@ -On Mon, 2017-08-28 at 09:51 +0300, Sagi Grimberg wrote: +On Mon, 2017-08-28@09:51 +0300, Sagi Grimberg wrote: > > On 23/08/17 20:58, Christoph Hellwig wrote: > > Introduce a new struct nvme_ns_head [1] that holds information about > > an actual namespace, unlike struct nvme_ns, which only holds the -> > per-controller namespace information. For private namespaces there +> > per-controller namespace information.??For private namespaces there > > is a 1:1 relation of the two, but for shared namespaces this lets us -> > discover all the paths to it. For now only the identifiers are moved +> > discover all the paths to it.??For now only the identifiers are moved > > to the new structure, but most of the information in struct nvme_ns > > should eventually move over. > > @@ -19,9 +19,9 @@ On Mon, 2017-08-28 at 09:51 +0300, Sagi Grimberg wrote: > > > > [1] comments welcome if you have a better name for it, the current one > > is -> > horrible. One idea would be to rename the current struct nvme_ns -> > to struct nvme_ns_link or similar and use the nvme_ns name for the -> > new structure. But that would involve a lot of churn. +> > ?????horrible.??One idea would be to rename the current struct nvme_ns +> > ?????to struct nvme_ns_link or similar and use the nvme_ns name for the +> > ?????new structure.??But that would involve a lot of churn. > > maybe nvme_ns_primary? @@ -36,11 +36,11 @@ Or nvme_ns_entity? Or nvme_ns_container? > > +/* -> > + * Anchor structure for namespaces. There is one for each namespace +> > + * Anchor structure for namespaces.??There is one for each namespace > > in a > > + * NVMe subsystem that any of our controllers can see, and the > > namespace -> > + * structure for each controller is chained of it. For private +> > + * structure for each controller is chained of it.??For private > > namespaces > > + * there is a 1:1 relation to our namespace structures, that is ->list > > + * only ever has a single entry for private namespaces. @@ -57,7 +57,7 @@ I think that sounds good too. > -> > + struct srcu_struct srcu; +> > + struct srcu_struct??????srcu; > > + unsigned ns_id; > > + u8 eui64[8]; > > + u8 nguid[16]; @@ -66,26 +66,26 @@ I think that sounds good too. > > + struct kref ref; > > +}; > > + -> > struct nvme_ns { -> > struct list_head list; -> > -> > struct nvme_ctrl *ctrl; -> > struct request_queue *queue; -> > struct gendisk *disk; +> > ? struct nvme_ns { +> > ?? struct list_head list; +> > ?? +> > ?? struct nvme_ctrl *ctrl; +> > ?? struct request_queue *queue; +> > ?? struct gendisk *disk; > > + struct list_head siblings; -> > struct nvm_dev *ndev; -> > struct kref kref; +> > ?? struct nvm_dev *ndev; +> > ?? struct kref kref; > > + struct nvme_ns_head *head; -> > int instance; -> > +> > ?? int instance; +> > ?? > > - u8 eui[8]; > > - u8 nguid[16]; > > - uuid_t uuid; > > - > > - unsigned ns_id; -> > int lba_shift; -> > u16 ms; -> > u16 sgs; +> > ?? int lba_shift; +> > ?? u16 ms; +> > ?? u16 sgs; > > > > diff --git a/a/content_digest b/N1/content_digest index 24c5b88..2a45111 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,25 +1,19 @@ "ref\020170823175815.3646-1-hch@lst.de\0" "ref\020170823175815.3646-8-hch@lst.de\0" "ref\0bee7c6c3-bf6b-8f7e-ad8f-fd5e238a94ef@grimberg.me\0" - "From\0J Freyensee <james_p_freyensee@linux.intel.com>\0" - "Subject\0Re: [PATCH 07/10] nvme: track shared namespaces\0" + "From\0james_p_freyensee@linux.intel.com (J Freyensee)\0" + "Subject\0[PATCH 07/10] nvme: track shared namespaces\0" "Date\0Mon, 28 Aug 2017 13:21:20 -0700\0" - "To\0Sagi Grimberg <sagi@grimberg.me>" - Christoph Hellwig <hch@lst.de> - " Jens Axboe <axboe@kernel.dk>\0" - "Cc\0Keith Busch <keith.busch@intel.com>" - linux-block@vger.kernel.org - " linux-nvme@lists.infradead.org\0" "\00:1\0" "b\0" - "On Mon, 2017-08-28 at 09:51 +0300, Sagi Grimberg wrote:\n" + "On Mon, 2017-08-28@09:51 +0300, Sagi Grimberg wrote:\n" "> \n" "> On 23/08/17 20:58, Christoph Hellwig wrote:\n" "> > Introduce a new struct nvme_ns_head [1] that holds information about\n" "> > an actual namespace, unlike struct nvme_ns, which only holds the\n" - "> > per-controller namespace information.\302\240\302\240For private namespaces there\n" + "> > per-controller namespace information.??For private namespaces there\n" "> > is a 1:1 relation of the two, but for shared namespaces this lets us\n" - "> > discover all the paths to it.\302\240\302\240For now only the identifiers are moved\n" + "> > discover all the paths to it.??For now only the identifiers are moved\n" "> > to the new structure, but most of the information in struct nvme_ns\n" "> > should eventually move over.\n" "> > \n" @@ -33,9 +27,9 @@ "> > \n" "> > [1] comments welcome if you have a better name for it, the current one\n" "> > is\n" - "> > \302\240\302\240\302\240\302\240\302\240horrible.\302\240\302\240One idea would be to rename the current struct nvme_ns\n" - "> > \302\240\302\240\302\240\302\240\302\240to struct nvme_ns_link or similar and use the nvme_ns name for the\n" - "> > \302\240\302\240\302\240\302\240\302\240new structure.\302\240\302\240But that would involve a lot of churn.\n" + "> > ?????horrible.??One idea would be to rename the current struct nvme_ns\n" + "> > ?????to struct nvme_ns_link or similar and use the nvme_ns name for the\n" + "> > ?????new structure.??But that would involve a lot of churn.\n" "> \n" "> maybe nvme_ns_primary?\n" "\n" @@ -50,11 +44,11 @@ "Or nvme_ns_container?\n" "\n" "> > +/*\n" - "> > + * Anchor structure for namespaces.\302\240\302\240There is one for each namespace\n" + "> > + * Anchor structure for namespaces.??There is one for each namespace\n" "> > in a\n" "> > + * NVMe subsystem that any of our controllers can see, and the\n" "> > namespace\n" - "> > + * structure for each controller is chained of it.\302\240\302\240For private\n" + "> > + * structure for each controller is chained of it.??For private\n" "> > namespaces\n" "> > + * there is a 1:1 relation to our namespace structures, that is ->list\n" "> > + * only ever has a single entry for private namespaces.\n" @@ -71,7 +65,7 @@ "\n" "\n" "> \n" - "> > +\tstruct srcu_struct\302\240\302\240\302\240\302\240\302\240\302\240srcu;\n" + "> > +\tstruct srcu_struct??????srcu;\n" "> > +\tunsigned\t\tns_id;\n" "> > +\tu8\t\t\teui64[8];\n" "> > +\tu8\t\t\tnguid[16];\n" @@ -80,28 +74,28 @@ "> > +\tstruct kref\t\tref;\n" "> > +};\n" "> > +\n" - "> > \302\240 struct nvme_ns {\n" - "> > \302\240\302\240\tstruct list_head list;\n" - "> > \302\240\302\240\n" - "> > \302\240\302\240\tstruct nvme_ctrl *ctrl;\n" - "> > \302\240\302\240\tstruct request_queue *queue;\n" - "> > \302\240\302\240\tstruct gendisk *disk;\n" + "> > ? struct nvme_ns {\n" + "> > ??\tstruct list_head list;\n" + "> > ??\n" + "> > ??\tstruct nvme_ctrl *ctrl;\n" + "> > ??\tstruct request_queue *queue;\n" + "> > ??\tstruct gendisk *disk;\n" "> > +\tstruct list_head siblings;\n" - "> > \302\240\302\240\tstruct nvm_dev *ndev;\n" - "> > \302\240\302\240\tstruct kref kref;\n" + "> > ??\tstruct nvm_dev *ndev;\n" + "> > ??\tstruct kref kref;\n" "> > +\tstruct nvme_ns_head *head;\n" - "> > \302\240\302\240\tint instance;\n" - "> > \302\240\302\240\n" + "> > ??\tint instance;\n" + "> > ??\n" "> > -\tu8 eui[8];\n" "> > -\tu8 nguid[16];\n" "> > -\tuuid_t uuid;\n" "> > -\n" "> > -\tunsigned ns_id;\n" - "> > \302\240\302\240\tint lba_shift;\n" - "> > \302\240\302\240\tu16 ms;\n" - "> > \302\240\302\240\tu16 sgs;\n" + "> > ??\tint lba_shift;\n" + "> > ??\tu16 ms;\n" + "> > ??\tu16 sgs;\n" "> > \n" "> \n" > -ca60bccecb41ea95140f82027313b81fd14fb5099b582590c2eb58bf256017a7 +34cb65a44b6f2ce52281570d7aecd98978d3ab9f8ae876cbb3e11a5741b38b5f
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.