public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Santosh Shukla <sshukla@mvista.com>
To: Josh Stone <jistone@redhat.com>
Cc: systemtap@sourceware.org, Corey Minyard <cminyard@mvista.com>
Subject: Re: [SYSTEMTAP/PATCH 0/4] RT aware systemtap patch set
Date: Mon, 15 Sep 2014 16:35:00 -0000	[thread overview]
Message-ID: <CAAyOgsb97yci-hoQ06jDiCvG1TuRiqP2Xo67k_inap19L-tXNQ@mail.gmail.com> (raw)
In-Reply-To: <54171259.6050009@redhat.com>

On Mon, Sep 15, 2014 at 9:52 PM, Josh Stone <jistone@redhat.com> wrote:
> Hi,
>
> On 09/15/2014 08:41 AM, Santosh Shukla wrote:
>> first wanted to get raw_locking specific to get into stap.
>
> One ugly aspect of this is that we try to maintain compatibility with
> older platforms too.  It looks like raw_spin_lock didn't come into the
> kernel until 2.6.33, which doesn't even cover RHEL6.  If possible we try
> to keep things running all the way back to RHEL4 (though see my earlier
> RFC about dropping that).

Right, I did saw your early RFC and noticed few important stuff
missing so to keep compatibility per se  .i..e.. some type of locking
function helper api which could ably switch between PREEMPT and
non-PREEMPT kernel.


In v2 version which I am working on [inspired by Corey suggestion] to
add below type of locking facility, pseudo code look like below

#ifdef CONFIG_PREEMPT_RT
static inline my_readlock(raw_spinlock_t *lock) { raw_spin_lock(&lock); }
static inline my_readunlock(raw_spinlock_t *lock) {
raw_spin_unlock(&lock); }
static inline my_writelock(raw_spinlock_t *lock) { raw_spin_lock(&lock); }
static inline my_writeunlock(raw_spinlock_t *lock) {
raw_spin_unlock(&lock); }
#else
static inline my_readlock(rwlock_t *lock) {read_lock(&lock); }
static inline my_readunlock(rwlock_t *lock) {read_unlock(&lock); }
static inline my_writelock(rwlock_t *lock) { write_lock(&lock); }
static inline my_writeunlock(rwlock_t *lock) {write_unlock(&lock); }
#endif

>
> That said, we can get away with new interfaces in some cases.  e.g. I
> believe stp_utrace.c and task_finder2.c can only be used on 3.x kernels.
>  But anything that's more generic, like addr-map.c, will need some kind
> of wrapper or compat #define added to let it work on older kernels too.
>  Maybe just #define raw_spin_lock spin_lock, etc.

Above one right? Its coming in v2 soon.

>
>
> Josh

  reply	other threads:[~2014-09-15 16:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-09  7:08 Santosh Shukla
2014-09-09  7:08 ` [SYSTEMTAP/PATCH 3/4] rt : stp_utrace.c : replace utrace->lock with raw_lock Santosh Shukla
2014-09-09  7:08 ` [SYSTEMTAP/PATCH 1/4] rt : replace __stp_tf_task_work_list_lock to raw_ Santosh Shukla
2014-09-09  7:08 ` [SYSTEMTAP/PATCH 2/4] rt : replace read write lock with rcu Santosh Shukla
2014-09-09  7:09 ` [SYSTEMTAP/PATCH 4/4] rt : replace utrace_struct lock to raw lock Santosh Shukla
2014-09-15 10:17 ` [SYSTEMTAP/PATCH 0/4] RT aware systemtap patch set Santosh Shukla
2014-09-15 14:13   ` David Smith
2014-09-15 15:41     ` Santosh Shukla
2014-09-15 16:22       ` Josh Stone
2014-09-15 16:35         ` Santosh Shukla [this message]
2014-09-15 16:45           ` Josh Stone
2014-09-15 16:48             ` Santosh Shukla
2014-09-15 16:51               ` Santosh Shukla

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=CAAyOgsb97yci-hoQ06jDiCvG1TuRiqP2Xo67k_inap19L-tXNQ@mail.gmail.com \
    --to=sshukla@mvista.com \
    --cc=cminyard@mvista.com \
    --cc=jistone@redhat.com \
    --cc=systemtap@sourceware.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).