All of lore.kernel.org
 help / color / mirror / Atom feed
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?

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.