On 05/31/2017 11:46 AM, Christoph Hellwig wrote:
> On Tue, May 30, 2017 at 11:45:25AM +0200, Johannes Thumshirn wrote:
>> Mostly consistency. The current nvme host code has the EUI sprinkled all
>> around. Sure I can drop it, but then what's the point in evaluating it
>> on the host side? Other
On 05/31/2017 11:46 AM, Christoph Hellwig wrote:
> On Tue, May 30, 2017 at 11:45:25AM +0200, Johannes Thumshirn wrote:
>> Mostly consistency. The current nvme host code has the EUI sprinkled all
>> around. Sure I can drop it, but then what's the point in evaluating it
>> on the host side? Other
On Tue, May 30, 2017 at 11:45:25AM +0200, Johannes Thumshirn wrote:
> Mostly consistency. The current nvme host code has the EUI sprinkled all
> around. Sure I can drop it, but then what's the point in evaluating it
> on the host side? Other targets may send it, so we need in on the host
> and do
On Tue, May 30, 2017 at 11:45:25AM +0200, Johannes Thumshirn wrote:
> Mostly consistency. The current nvme host code has the EUI sprinkled all
> around. Sure I can drop it, but then what's the point in evaluating it
> on the host side? Other targets may send it, so we need in on the host
> and do
On 05/30/2017 11:25 AM, Christoph Hellwig wrote:
> On Tue, May 30, 2017 at 10:08:18AM +0200, Johannes Thumshirn wrote:
>> Add the EUI-64 field from the NVMe Namespace Identification Descriptor
>> to the nvmet_ns structure and allow it's population via configfs.
>
> Is there any good use case for
On 05/30/2017 11:25 AM, Christoph Hellwig wrote:
> On Tue, May 30, 2017 at 10:08:18AM +0200, Johannes Thumshirn wrote:
>> Add the EUI-64 field from the NVMe Namespace Identification Descriptor
>> to the nvmet_ns structure and allow it's population via configfs.
>
> Is there any good use case for
On Tue, May 30, 2017 at 10:08:18AM +0200, Johannes Thumshirn wrote:
> Add the EUI-64 field from the NVMe Namespace Identification Descriptor
> to the nvmet_ns structure and allow it's population via configfs.
Is there any good use case for bothering with this identifier that's
too short to
On Tue, May 30, 2017 at 10:08:18AM +0200, Johannes Thumshirn wrote:
> Add the EUI-64 field from the NVMe Namespace Identification Descriptor
> to the nvmet_ns structure and allow it's population via configfs.
Is there any good use case for bothering with this identifier that's
too short to
On 05/30/2017 10:08 AM, Johannes Thumshirn wrote:
> Add the EUI-64 field from the NVMe Namespace Identification Descriptor
> to the nvmet_ns structure and allow it's population via configfs.
>
> Signed-off-by: Johannes Thumshirn
> ---
> drivers/nvme/target/configfs.c | 48
>
On 05/30/2017 10:08 AM, Johannes Thumshirn wrote:
> Add the EUI-64 field from the NVMe Namespace Identification Descriptor
> to the nvmet_ns structure and allow it's population via configfs.
>
> Signed-off-by: Johannes Thumshirn
> ---
> drivers/nvme/target/configfs.c | 48
>
Add the EUI-64 field from the NVMe Namespace Identification Descriptor
to the nvmet_ns structure and allow it's population via configfs.
Signed-off-by: Johannes Thumshirn
---
drivers/nvme/target/configfs.c | 48 ++
Add the EUI-64 field from the NVMe Namespace Identification Descriptor
to the nvmet_ns structure and allow it's population via configfs.
Signed-off-by: Johannes Thumshirn
---
drivers/nvme/target/configfs.c | 48 ++
drivers/nvme/target/nvmet.h| 1 +
2
12 matches
Mail list logo