From: Shuah Khan <skhan@linuxfoundation.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: corbet@lwn.net, keescook@chromium.org,
gregkh@linuxfoundation.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, skhan@linuxfoundation.org
Subject: Re: [PATCH 01/13] seqnum_ops: Introduce Sequence Number Ops
Date: Wed, 11 Nov 2020 08:56:49 -0700 [thread overview]
Message-ID: <7207fad6-6ca4-529b-60a8-63db998d10d9@linuxfoundation.org> (raw)
In-Reply-To: <20201111082320.GR2611@hirez.programming.kicks-ass.net>
On 11/11/20 1:23 AM, Peter Zijlstra wrote:
> On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
>
>> + * The interface provides:
>> + * seqnum32 & seqnum64 functions:
>> + * initialization
>> + * set
>> + * read
>> + * increment and no return
>> + * decrement and no return
>
> NAK, this is batshit insane again.
Gosh that is a bit much. Definitely will never be part of my kernel
review/response vocabulary.
If you want a sequence number, the
> one and _ONLY_ primitive you want to expose is inc_return.
>
> No set, no read, no inc, and most certainly, not dec.
>
Agree with you on removing dec(). It isn't needed or up counting.
set() can go and use just init instead of set.
read and inc are needed for sure though. The reason being numbers
could be incremented in one place and read in other places. In some
cases inc_return is used.
Why would you say no to read and inc?
init, read, inc, and inc_return are necessary to be able to implement
up counters.
thanks,
-- Shuah
next prev parent reply other threads:[~2020-11-11 15:56 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 19:53 [PATCH 00/13] Introduce seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 01/13] seqnum_ops: Introduce Sequence Number Ops Shuah Khan
2020-11-10 20:41 ` Greg KH
2020-11-10 20:43 ` Greg KH
2020-11-11 0:18 ` Kees Cook
2020-11-11 19:23 ` Shuah Khan
2020-11-12 12:36 ` Matthew Wilcox
2020-11-12 16:17 ` Shuah Khan
2020-11-12 16:45 ` Greg KH
2020-11-12 16:59 ` Shuah Khan
2020-11-12 21:27 ` Shuah Khan
2020-11-17 12:27 ` Peter Zijlstra
2020-11-10 21:03 ` Matthew Wilcox
2020-11-10 22:58 ` Shuah Khan
2020-11-11 0:20 ` Kees Cook
2020-11-11 15:42 ` Shuah Khan
2020-11-11 8:23 ` Peter Zijlstra
2020-11-11 15:56 ` Shuah Khan [this message]
2020-11-11 16:04 ` Peter Zijlstra
2020-11-11 17:34 ` Shuah Khan
2020-11-11 17:50 ` Peter Zijlstra
2020-11-11 18:28 ` Shuah Khan
2020-11-11 20:15 ` Peter Zijlstra
2020-11-12 13:29 ` Greg KH
2020-11-10 19:53 ` [PATCH 02/13] selftests:lib:test_seqnum_ops: add new test for seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 03/13] drivers/acpi: convert seqno seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 04/13] drivers/acpi/apei: convert seqno to seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 05/13] drivers/base/test/test_async_driver_probe: convert to use seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 06/13] drivers/char/ipmi: convert stats " Shuah Khan
2020-11-10 19:53 ` [PATCH 07/13] drivers/edac: convert pci counters to seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 08/13] drivers/oprofile: convert stats to use seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 09/13] drivers/staging/rtl8723bs: " Shuah Khan
2020-11-10 19:53 ` [PATCH 10/13] usb: usbip/vhci: convert seqno to seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 11/13] drivers/staging/rtl8188eu: convert stats to use seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 12/13] drivers/staging/unisys/visorhba: " Shuah Khan
2020-11-10 20:42 ` Greg KH
2020-11-10 21:02 ` Shuah Khan
2020-11-10 19:53 ` [PATCH 13/13] security/integrity/ima: converts stats to seqnum_ops Shuah Khan
2020-11-10 20:44 ` [PATCH 00/13] Introduce seqnum_ops Alan Stern
2020-11-10 22:42 ` Shuah Khan
2020-11-11 4:33 ` Matthew Wilcox
2020-11-11 16:03 ` Shuah Khan
2020-11-11 16:41 ` Matthew Wilcox
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=7207fad6-6ca4-529b-60a8-63db998d10d9@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
/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
all inboxes | Powered by JetHome®