Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Damien Le Moal <dlemoal@kernel.org>,
	Christoph Hellwig <hch@infradead.org>
Cc: Wang Yugui <wangyugui@e16-tech.com>, linux-nvme@lists.infradead.org
Subject: Re: [PATCH RFC v2] nvme: basic RMEDIA support for host
Date: Mon, 12 Aug 2024 16:28:26 +0200	[thread overview]
Message-ID: <e3626d04-cde3-40dd-bd54-b642d18d73ef@suse.de> (raw)
In-Reply-To: <1b8f549d-4d24-48af-baea-952076d37834@kernel.org>

On 7/26/24 00:59, Damien Le Moal wrote:
> On 7/25/24 23:10, Christoph Hellwig wrote:
>> On Thu, Jul 25, 2024 at 09:43:45AM +0900, Damien Le Moal wrote:
>>> Why not do that now in another patch, at least for the loop target ?
>>> Given that they are not that many NVMe-HDD out there, that would be
>>> nice to have to test this.
>>
>> The code would be in the bdev backend, so it applies to all transport
>> equally.  And yes, I'd love to see a patch for that to, but I don't
>> want to gate a simple flag check on it.
> 
> OK. Will look into it then. I have the setup to test this anyway.
> 
> That said, while setting only the rotational media bit should be fairly easy, I
> am worried about spec compliance as setting that flag to 1 mandates support for
> endurance groups as well. Do we care about this ? I am tempted to say no but not
> following the specs is generally a dangerous path we do not want to follow...
> 
I'd got for the usual minimal-viable implementation way like adding 
static logpages for the endurance group information (with just a single 
endurance group '1') and for endurance group event aggregate (with no 
events :-).

Shouldn't blow up the code _that_ much.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich



  reply	other threads:[~2024-08-12 14:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-23 23:24 [PATCH RFC] basic RMEDIA support for nvme host Wang Yugui
2024-07-24 12:30 ` [PATCH RFC v2] nvme: basic RMEDIA support for host Wang Yugui
2024-07-25  0:43   ` Damien Le Moal
2024-07-25  1:56     ` Wang Yugui
2024-07-25 14:10     ` Christoph Hellwig
2024-07-25 22:59       ` Damien Le Moal
2024-08-12 14:28         ` Hannes Reinecke [this message]
2024-07-25 14:09   ` Christoph Hellwig
2024-08-06  0:48 ` [PATCH RFC v3] " Wang Yugui
2024-08-06  0:49   ` [PATCH RFC] nvmet: basic RMEDIA support for target Wang Yugui
2024-08-06  8:11     ` Sagi Grimberg
2024-08-06  9:08       ` Wang Yugui
2024-08-06  9:42     ` [PATCH RFC v2] " Wang Yugui
2024-08-06 12:40     ` [PATCH RFC v3] " Wang Yugui
2024-08-07 12:14       ` Sagi Grimberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e3626d04-cde3-40dd-bd54-b642d18d73ef@suse.de \
    --to=hare@suse.de \
    --cc=dlemoal@kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=wangyugui@e16-tech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox