linux-kernel - Re: [PATCH 1/5] doc/memory-barriers: fix missed renaming: s/lock/acquire

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]

Message-ID: <alpine.DEB.2.10.1603101739310.16296@hxeon>
Date:	Thu, 10 Mar 2016 17:50:49 +0900 (KST)
From:	SeongJae Park <sj38.park@...il.com>
To:	David Howells <dhowells@...hat.com>
cc:	SeongJae Park <sj38.park@...il.com>, paulmck@...ux.vnet.ibm.com,
	corbet@....net, minchan@...nel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] doc/memory-barriers: fix missed renaming:
 s/lock/acquire



On Thu, 10 Mar 2016, David Howells wrote:

> SeongJae Park <sj38.park@...il.com> wrote:
>
>> -     - Locking functions.
>> +     - Acquiring functions.
>
> Actually, this should be 'locking' functions.  If you look at the text:
>
> 	ACQUIRING FUNCTIONS
> 	-------------------
>
> 	The Linux kernel has a number of locking constructs:
>
> 	 (*) spin locks
> 	 (*) R/W spin locks
> 	 (*) mutexes
> 	 (*) semaphores
> 	 (*) R/W semaphores
>
> It's specifically talking about locking functions that the kernel provides -
> or are we calling the spin acquires and R/W spin acquires now?  "Locking" is
> the key that people referring to the document are going to use.

AFAIU, the next line of the quoted text says the section is talking about
variants on "ACQUIRE" operations and "RELEASE" operations for each locking
constructs.  I thought the original change which changed the name of
section has made full consensus and I am just want to make the section
names in `Contents` section and its real section name.  I will listen to
other's opinions more.


Thanks,
SeongJae Park

>
> David
>