Re: [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support

2020-09-16 Thread Stephen Rothwell
Hi all, On Wed, 16 Sep 2020 15:02:33 +0200 pet...@infradead.org wrote: > > On Wed, Sep 16, 2020 at 09:00:59AM -0400, Qian Cai wrote: > > > > > > - Original Message - > > > On Wed, Sep 16, 2020 at 08:52:07AM -0400, Qian Cai wrote: > > > > On Tue, 2020-09-15 at 16:30 +0200, pet...@infr

Re: [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support

2020-09-16 Thread Qian Cai
- Original Message - > On Wed, Sep 16, 2020 at 08:52:07AM -0400, Qian Cai wrote: > > On Tue, 2020-09-15 at 16:30 +0200, pet...@infradead.org wrote: > > > On Tue, Sep 15, 2020 at 08:48:17PM +0800, Boqun Feng wrote: > > > > I think this happened because seqcount_##lockname##_init() is defi

Re: [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support

2020-09-16 Thread Qian Cai
On Tue, 2020-09-15 at 16:30 +0200, pet...@infradead.org wrote: > On Tue, Sep 15, 2020 at 08:48:17PM +0800, Boqun Feng wrote: > > I think this happened because seqcount_##lockname##_init() is defined at > > function rather than macro, so when the seqcount_init() gets expand in > > Bah! I hate all t

Re: [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support

2020-09-16 Thread peterz
On Wed, Sep 16, 2020 at 08:52:07AM -0400, Qian Cai wrote: > On Tue, 2020-09-15 at 16:30 +0200, pet...@infradead.org wrote: > > On Tue, Sep 15, 2020 at 08:48:17PM +0800, Boqun Feng wrote: > > > I think this happened because seqcount_##lockname##_init() is defined at > > > function rather than macro,

Re: [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support

2020-09-16 Thread peterz
On Wed, Sep 16, 2020 at 09:00:59AM -0400, Qian Cai wrote: > > > - Original Message - > > On Wed, Sep 16, 2020 at 08:52:07AM -0400, Qian Cai wrote: > > > On Tue, 2020-09-15 at 16:30 +0200, pet...@infradead.org wrote: > > > > On Tue, Sep 15, 2020 at 08:48:17PM +0800, Boqun Feng wrote: > > >

Re: [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support

2020-09-15 Thread peterz
On Tue, Sep 15, 2020 at 08:48:17PM +0800, Boqun Feng wrote: > I think this happened because seqcount_##lockname##_init() is defined at > function rather than macro, so when the seqcount_init() gets expand in Bah! I hate all this :/ I suspect the below, while more verbose than I'd like is the best

Re: [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support

2020-09-15 Thread Boqun Feng
On Tue, Sep 15, 2020 at 08:48:17PM +0800, Boqun Feng wrote: > On Mon, Sep 14, 2020 at 08:20:53PM -0400, Qian Cai wrote: > > On Fri, 2020-09-04 at 17:32 +0200, Ahmed S. Darwish wrote: > > > Hi, > > > > > > Changelog-v2 > > > > > > > > > - Standardize on seqcount_LOCKNAME_t as the ca

Re: [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support

2020-09-15 Thread Boqun Feng
On Mon, Sep 14, 2020 at 08:20:53PM -0400, Qian Cai wrote: > On Fri, 2020-09-04 at 17:32 +0200, Ahmed S. Darwish wrote: > > Hi, > > > > Changelog-v2 > > > > > > - Standardize on seqcount_LOCKNAME_t as the canonical reference for > > sequence counters with associated locks, inste

Re: [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support

2020-09-14 Thread Qian Cai
On Fri, 2020-09-04 at 17:32 +0200, Ahmed S. Darwish wrote: > Hi, > > Changelog-v2 > > > - Standardize on seqcount_LOCKNAME_t as the canonical reference for > sequence counters with associated locks, instead of v1 > seqcount_LOCKTYPE_t. > > - Use unique prefix "seqprop_*"

[PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support

2020-09-04 Thread Ahmed S. Darwish
Hi, Changelog-v2 - Standardize on seqcount_LOCKNAME_t as the canonical reference for sequence counters with associated locks, instead of v1 seqcount_LOCKTYPE_t. - Use unique prefix "seqprop_*" for all seqcount_t/seqcount_LOCKNAME_t property accessors. - Touch-up t