From: Andrew Morton <akpm@linux-foundation.org>
To: Peter Oberparleiter <oberparleiter@googlemail.com>
Cc: Harvey Harrison <harvey.harrison@gmail.com>,
Peter Oberparleiter <peter.oberparleiter@de.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] consolidate all within() implementations
Date: Tue, 20 May 2008 02:45:35 -0700 [thread overview]
Message-ID: <20080520024535.6b4f487e.akpm@linux-foundation.org> (raw)
In-Reply-To: <48328700.4000907@googlemail.com>
On Tue, 20 May 2008 10:08:32 +0200 Peter Oberparleiter <oberparleiter@googlemail.com> wrote:
> Harvey Harrison wrote:
> > On Mon, 2008-05-19 at 10:45 +0200, Peter Oberparleiter wrote:
> >> From: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
> >>
> >> This patch consolidates a number of different implementations of the
> >> within() function which checks whether an address is within a specified
> >> address range.
> >
> > Would it be that hard to just make them static inlines taking unsigned
> > longs?
>
> I was hoping to get by without the spray of unsigned long casts that
> entails the enforcement of this specific parameter type, seeing that
> each implementation had it's own combination of longs and void *.
>
> On the other hand, an inline function would of course be the cleaner
> approach, so if the code owners agree, here goes take #2:
>
> --
>
> From: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
>
> This patch consolidates a number of different implementations of the
> within() function which checks whether an address is within a specified
> address range. Apart from parameter typing, existing implementations can
> be classified in two categories which differ in the way the range is
> specified:
>
> 1) by start and end address
> 2) by start and size
>
> Case 1) is covered by addr_within() while 2) is covered by
> addr_within_len().
>
> Signed-off-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
> ---
> arch/x86/mm/pageattr.c | 20 ++++++++------------
> include/linux/kernel.h | 24 ++++++++++++++++++++++++
> kernel/lockdep.c | 12 +++++-------
> kernel/module.c | 35 ++++++++++++++++++++---------------
> 4 files changed, 57 insertions(+), 34 deletions(-)
>
> Index: linux-2.6.26-rc3/include/linux/kernel.h
> ===================================================================
> --- linux-2.6.26-rc3.orig/include/linux/kernel.h
> +++ linux-2.6.26-rc3/include/linux/kernel.h
> @@ -434,6 +434,30 @@ static inline char *pack_hex_byte(char *
> __val > __max ? __max: __val; })
>
> /**
> + * addr_within - check whether address is in start-and-end address range
> + * @addr: address
> + * @start: start address (included in range)
> + * @end: end address (excluded from range)
> + */
> +static inline int addr_within(unsigned long addr, unsigned long start,
> + unsigned long end)
> +{
> + return (addr >= start) && (addr < end);
> +}
> +
> +/**
> + * addr_within_len - check whether address is in start-and-length address range
> + * @addr: address
> + * @start: start of range
> + * @len: number of bytes in range
> + */
> +static inline int addr_within_len(unsigned long addr, unsigned long start,
> + unsigned long len)
> +{
> + return (addr >= start) && (addr < (start + len));
> +}
The kernel's use of unsigned long to represent pointers sometimes makes
sense, but often gets us into a mess. It's OK in bootup code which
fiddles with memory map layout because there is no reason why such
code will ever dereference any of the addresses.
But I don't think we can assume this usage pattern when creating a
kernel-wide facility in kernel.h.
So yes, I do think that an address-comparison tool like this should
operate on void*'s. (They will need to be const void*'s).
> + if (addr_within_len((unsigned long) class->key,
> + (unsigned long) start, size))
> + else if (addr_within_len((unsigned long) class->name,
> + (unsigned long) start, size))
> + if (addr_within_len(addr, (unsigned long) mod->module_init,
> + if (addr_within_len(addr, (unsigned long) mod->module_init,
> + || addr_within_len(addr, (unsigned long) mod->module_core,
> + if (addr_within_len(addr, (unsigned long) mod->module_init,
> + addr_within_len(addr, (unsigned long) mod->module_core,
> + if (addr_within_len(addr, (unsigned long) mod->module_init,
> + addr_within_len(addr, (unsigned long) mod->module_core,
> + if (addr_within_len(addr, (unsigned long) mod->module_core,
> + if (addr_within_len(addr, (unsigned long) mod->module_init,
> + || addr_within_len(addr, (unsigned long) mod->module_core,
And you've had to add a great pile of casts anwyay?
next prev parent reply other threads:[~2008-05-20 9:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-19 8:45 [PATCH] consolidate all within() implementations Peter Oberparleiter
2008-05-19 20:50 ` Harvey Harrison
2008-05-20 8:08 ` Peter Oberparleiter
2008-05-20 9:45 ` Andrew Morton [this message]
2008-05-20 15:42 ` Peter Oberparleiter
2008-05-21 10:04 ` Peter Zijlstra
2008-05-21 10:33 ` Peter 1 Oberparleiter
2008-05-21 10:48 ` Peter Zijlstra
2008-05-21 13:50 ` Peter 1 Oberparleiter
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=20080520024535.6b4f487e.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=harvey.harrison@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oberparleiter@googlemail.com \
--cc=peter.oberparleiter@de.ibm.com \
/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