linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: "Viacheslav A.Dubeyko" <viacheslav.dubeyko@bytedance.com>
Cc: "Damien Le Moal" <damien.lemoal@opensource.wdc.com>,
	"Javier González" <javier.gonz@samsung.com>,
	"Viacheslav Dubeyko" <slava@dubeyko.com>,
	"Luis Chamberlain" <mcgrof@kernel.org>,
	"Linux FS Devel" <linux-fsdevel@vger.kernel.org>,
	linux-block@vger.kernel.org,
	"Matias Bjørling" <Matias.Bjorling@wdc.com>,
	"Bart Van Assche" <bvanassche@acm.org>,
	"Adam Manzanares" <a.manzanares@samsung.com>,
	"Hans Holmberg" <hans.holmberg@wdc.com>,
	lsf-pc@lists.linux-foundation.org
Subject: Re: [External] [LSF/MM/BPF BoF] Session for Zoned Storage 2023
Date: Mon, 9 Jan 2023 18:09:46 -0700	[thread overview]
Message-ID: <e4a972f4-50fd-4c0e-1b44-dc702fd9c445@kernel.dk> (raw)
In-Reply-To: <E2BA234A-D3D3-440B-BBDB-230B772B2D01@bytedance.com>

On 1/9/23 4:20?PM, Viacheslav A.Dubeyko wrote:
> 
> 
>> On Jan 9, 2023, at 3:00 PM, Jens Axboe <axboe@kernel.dk> wrote:
>>
>>>> My point here that we could summarize:
>>>> (1) what features already implemented and supported,
>>>> (2) what features are under implementation and what is progress,
>>>> (3) what features need to be implemented yet.
>>>>
>>>> Have we implemented everything already? :)
>>>
>>> Standards are full of features that are not useful in a general purpose
>>> system. So we likely never will implement everything. We never did for
>>> SCSI and ATA and never will either.
>> Indeed, and that's a very important point. Some people read specs and
>> find things that aren't in the Linux driver (any spec, not a specific
>> one), and think they need to be added. No. We only add them if they make
>> sense, both in terms of use cases, but also as long as they can get
>> implemented cleanly. Parts of basically any spec is garbage and don't
>> necessarily fit within the given subsystem either.
>>
>> The above would make me worried about patches coming from anyone with
>> that mindset.
>>
> 
> OK. We already have discussion about garbage in spec. :)
> So, what would we like finally implement and what never makes sense to do?
> Should we identify really important stuff for implementation?

Well if you did have that discussion, then it seemed you got nothing
from it. Because asking that kind of question is EXACTLY what I'm saying
is the opposite of what should be done. If there's a demand for a
feature, then it can be looked at and ultimately implemented if it makes
sense. You're still talking about proactively finding features and
implementing them "just in case they are needed", which is very much the
opposite and wrong approach, and how any kind of software ends up being
bloated, slow, and buggy/useless.

-- 
Jens Axboe


  parent reply	other threads:[~2023-01-10  1:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-06 19:17 [LSF/MM/BPF BoF] Session for Zoned Storage 2023 Viacheslav Dubeyko
2023-01-06 19:18 ` Luis Chamberlain
2023-01-06 19:30   ` Viacheslav Dubeyko
2023-01-07  1:56     ` [External] " Viacheslav A.Dubeyko
     [not found]       ` <20230109153315.waqfokse4srv6xlz@mpHalley-2.localdomain>
2023-01-09 17:05         ` Bart Van Assche
2023-01-09 19:11         ` Viacheslav A.Dubeyko
2023-01-09 22:53           ` Damien Le Moal
2023-01-09 23:00             ` Jens Axboe
2023-01-09 23:20               ` Viacheslav A.Dubeyko
2023-01-09 23:32                 ` Damien Le Moal
2023-01-10  1:09                 ` Jens Axboe [this message]
2023-01-10  1:39                   ` Viacheslav A.Dubeyko
2023-01-10  1:50                     ` Jens Axboe
2023-01-28 11:34       ` Ming Lei
     [not found]         ` <BN8PR04MB64170AF4B399B6A3E26BAAC6F1D39@BN8PR04MB6417.namprd04.prod.outlook.com>
2023-01-30 11:24           ` Andreas Hindborg
2023-01-06 22:18 ` Viacheslav A.Dubeyko

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=e4a972f4-50fd-4c0e-1b44-dc702fd9c445@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=Matias.Bjorling@wdc.com \
    --cc=a.manzanares@samsung.com \
    --cc=bvanassche@acm.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=hans.holmberg@wdc.com \
    --cc=javier.gonz@samsung.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=mcgrof@kernel.org \
    --cc=slava@dubeyko.com \
    --cc=viacheslav.dubeyko@bytedance.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;
as well as URLs for NNTP newsgroup(s).