* David Brownell <[email protected]> wrote:
> > Why do you want to use raw_spinlock_t?
>
> Already answered elsewhere in this thread ... I'll highlight the point
> that such bitops shouldn't be preemption points.
raw_spinlock_t is a spinlock-internal implementation detail in the
upstream kernel. You should _not_ be using it. The PREEMPT_RT
raw_spinlock_t markings will move upstream in the future together with
that feature, not piecemail wise with other patches. In other words:
raw_spinlock_t in PREEMPT_RT != raw_spinlock_t in the upstream kernel.
(and dont be worried, any necessary raw_spinlock_t annotations _will_
move upstream together with PREEMPT_RT, once that feature is being
merged, so your code is not missing out on anything.)
The only code that should use raw_spinlock_t in the upstream kernel is
the spinlock code and occasionally some debugging code. (If you still
see any other strong reasons for it then please state it in simple,
standalone terms without depending on context - your reasons were not
clear to me so far so either me or you are confused about something and
this is probably just a matter of communication.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
