From: William Lee Irwin III <wli@holomorphy.com>
To: Hanna Linder <hannal@us.ibm.com>
Cc: lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [Lse-tech] [RFT] port of Lockmeter on i386 2.5.64 Patch
Date: Sun, 9 Mar 2003 19:00:59 -0800 [thread overview]
Message-ID: <20030310030059.GJ465@holomorphy.com> (raw)
In-Reply-To: <149620000.1047264510@w-hlinder>
On Sun, Mar 09, 2003 at 06:48:30PM -0800, Hanna Linder wrote:
> +/*
> + * Currently, the mips64 and sparc64 kernels talk to a 32-bit lockstat, so we
> + * need to force compatibility in the inter-communication data structure.
> + */
> +
> +#if defined(CONFIG_MIPS32_COMPAT)
> +#define TIME_T uint32_t
> +#elif defined(CONFIG_SPARC32_COMPAT)
> +#define TIME_T uint64_t
> +#else
> +#define TIME_T time_t
> +#endif
Hmm, is there a way to inherit this from arch code?
On Sun, Mar 09, 2003 at 06:48:30PM -0800, Hanna Linder wrote:
> +#if defined(__KERNEL__) || (!defined(CONFIG_MIPS32_COMPAT) && !defined(CONFIG_SPARC32_COMPAT)) || (_MIPS_SZLONG==32)
> +#define POINTER void *
> +#else
> +#define POINTER int64_t
> +#endif
What on earth? Shouldn't this be done some other way?
I really think 32-bit compatibility should be mostly ignored; userspace
should just be rearranged to understand it's looking at a 64-bit kernel
even when running in a 32-bit userspace.
On Sun, Mar 09, 2003 at 06:48:30PM -0800, Hanna Linder wrote:
> +#ifdef USER_MODE_TESTING
> + rwlock_t entry_lock; /* lock for this read lock entry... */
> + /* avoid having more than one rdr at*/
> + /* needed for user space testing... */
> + /* not needed for kernel 'cause it */
> + /* is non-preemptive. ............. */
> +#endif
Hmm, USER_MODE_TESTING can probably just go.
On Sun, Mar 09, 2003 at 06:48:30PM -0800, Hanna Linder wrote:
> #define spin_unlock_irqrestore(lock, flags) \
> do { \
> - _raw_spin_unlock(lock); \
> + spin_unlock(lock); \
> local_irq_restore(flags); \
> preempt_enable(); \
> } while (0)
Erm, is this safe? there's a reason _raw_spin_unlock() is used here, for
the CONFIG_PREEMPT stuff basically. It'd look less disturbing if the old
names and semantics were preserved.
On Sun, Mar 09, 2003 at 06:48:30PM -0800, Hanna Linder wrote:
> +#ifdef DEBUG_LOCKMETER
> + printk("put_lockmeter_info(cpu=%d): LSTAT_ON\n",THIS_CPU_NUMBER);
> +#endif
DEBUG_LOCKMETER should probably go away for merging.
All in all I'm glad to have this back. It'd be a valuable addition to
CONFIG_PROFILING once things are lined up with Linux conventions.
Despite a little bit of crustiness inherited from before ppl were used
to Linux conventions it's still pretty smooth.
-- wli
next prev parent reply other threads:[~2003-03-10 2:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-10 2:48 [RFT] port of Lockmeter on i386 2.5.64 Patch Hanna Linder
2003-03-10 3:00 ` William Lee Irwin III [this message]
2003-03-10 5:33 ` Valdis.Kletnieks
2003-03-10 5:36 ` Robert Love
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=20030310030059.GJ465@holomorphy.com \
--to=wli@holomorphy.com \
--cc=hannal@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
/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