lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ