What's the upstream disposition with nvme-stas?

[smith, erik]

Thank you Keith.  

With regards to "stas can break things that don't subscribe to their way of configuration"  We heard this feedback clearly last year and Martin updated nvme-stas to make sure it doesn't remove connections that it didn't establish in the first place. 

Regards, Erik  


Internal Use - Confidential

-----Original Message-----
From: Keith Busch <kbusch at kernel.org> 
Sent: Friday, June 23, 2023 11:48 AM
To: John Meneghini <jmeneghi at redhat.com>
Cc: linux-nvme at lists.infradead.org; Christoph Hellwig <hch at lst.de>; Sagi Grimberg <sagi at grimberg.me>; smith, erik <Erik.Smith at dell.com>; Rose, Charles <Charles_Rose at Dell.com>; Belanger, Martin <Martin_Belanger at Dell.com>; Hannes Reinecke <hare at suse.de>; Martin Wilck <mwilck at suse.com>; Daniel Wagner <dwagner at suse.de>
Subject: Re: What's the upstream disposition with nvme-stas?


[EXTERNAL EMAIL] 

On Thu, Jun 22, 2023 at 01:41:30PM -0400, John Meneghini wrote:
> At LSFMM this year I spoke with privately with Keith Bush and others 
> about the status of nvme-stas. When Keith and I spoke he told me that 
> Dell had talked with him privately about nvme-stas and asked if the 
> nvme-stas functionality can be merged into nvme-cli or otherwise accepted upstream.
> Keith said that he told Dell, after looking at the nvme-stas 
> implementation (again), the answer was no.

It's not that I told anyone "no" on merging -stas with -cli, or that I was asked to do so. That was a mutual conclusion. The two projects are sufficiently unaligned for such a destiny. nvme-cli is a stateless, one-shot command based utility, just like it wanted to be. Not that it couldn't support the features; it'd just be done in a different way, but there isn't interest (that I know of) in developing a fully flushed out solution there.

While I personally don't like the tooling fragmentation or that -stas can break things that don't subscribe to their way of configuration, that's *their* problem to sort out with their users. I don't have such hardware, so I haven't got a horse in that race.

> general purpose Linux utility used for discovering and managing nvme 
> and nvme-of devices. This is the nvme-cli utility. This is what's 
> "supported upstream" and I'd like to end any debate about whether or 
> not the upstream community supports nvme-stas. Nvme-stas is supported 
> by the upstream community to the extent that it uses the kernel and 
> libnvme APIs to access nvme devices; just as any other third party 
> user space application that exploits these kernel and user space APIs 
> is supported. Other than this, nvme-stas is not "supported upstream".

I'm not sure we're all aligned on what "supported upstream" means.

The linux kernel has to support the interfaces it exposes to user space no matter who's using them.

The tooling using these interfaces are independently developed, often loosely organized. There's not really an individual authority that makes decisions on what counts as "supported upstream". These things often happen organically as developers and users converge on solutions to common problems.

Dell is free to call their repo the supported upstream "nvme-stas"
utility if they want since they are apparently actively maintaining it.
That doesn't mean any 3rd party entities or greater linux-nvme community are also backing the effort, though.

An OEM/IHV also can't really force distros to support their products either. Usually those support decisions are based on some merits of mutual benefits, and it's perfectly normal to conclude either way.