[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <69eeacda-d59c-bec8-d115-4bf7c97d7690@oracle.com>
Date: Mon, 3 Jul 2023 12:09:12 -0500
From: Mike Christie <michael.christie@...cle.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-scsi <linux-scsi@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>
Subject: Re: [GIT PULL] first round of SCSI updates for the 6.4+ merge window
On 6/30/23 2:14 PM, Linus Torvalds wrote:
> On Thu, 29 Jun 2023 at 05:48, James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
>>
>> We have a couple of major core changes impacting other
>> systems: Command Duration Limits, which spills into block and ATA and
>> block level Persistent Reservation Operations, which touches block,
>> nvme, target and dm (both of which are added with merge commits
>> containing a cover letter explaining what's going on).
>
> Random side note - as an outsider that then sees a trivial conflict
> due to the split of the nmve side into a file called 'pr.c', I can
> only say that my reaction to that was "what a horrible filename".
>
> Maybe it makes sense to people that are very into nvme, but honestly,
> considering it's a new special thing, I kind of doubt it.
>
> We really don't lack the disk-space to use more descriptive names for
> files. "pr.c" really is pretty horrid.
cc'ing the nvme list because it's their file.
PR stands for persistent reservation. It's from the SCSI days so the
term and abbreviation is common to SCSI people and nvme developers that
used to work on that. I can see how a new storage person would not be
familiar with it.
Maybe name it persistent_reservation.c, or if people think that's too
long does persistent_resv.c make sense since we use the "resv"
abbreviation for reservation in nvme and the block layer.
Powered by blists - more mailing lists