All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Matt Mackall <mpm@selenic.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@osdl.org>
Subject: Re: random.c changes for sparse irq_desc are crap
Date: Fri, 2 Jan 2009 16:59:22 +0100	[thread overview]
Message-ID: <20090102155922.GD1180@elte.hu> (raw)
In-Reply-To: <1230802316.3204.4.camel@calx>


* Matt Mackall <mpm@selenic.com> wrote:

> On Wed, 2008-12-31 at 16:14 -0800, Yinghai Lu wrote:
> > On Wed, Dec 31, 2008 at 3:40 PM, Matt Mackall <mpm@selenic.com> wrote:
> > > On Wed, 2008-12-31 at 15:07 -0800, Yinghai Lu wrote:
> > >> Matt Mackall wrote:
> > >> > I just noticed you merged a change that pointlessly converts two
> > >> > random.c functions into ugly random.h inlines without going through the
> > >> > maintainer.
> > >> >
> > >> > I also don't like the look of the newly-introduced sparse variants of
> > >> > these functions. Failure to find an irq descriptor in
> > >> > get_timer_rand_state is a BUG_ON should-never-happen sort of condition,
> > >> > not something to silently ignore. Letting the code try to dereference
> > >> > NULL is preferred here: we'll actually be able to find and fix the
> > >> > broken driver that's throwing around meaningless irq vectors.
> > >> >
> > >> > Throwing away the timer_state pointer in the set_timer_rand_state
> > >> > function is similarly bogus in addition to being a memory leak.
> > >> >
> > >> > Please fix this up.
> > >> >
> > >>
> > >> want something like this?
> > >
> > > Not quite.
> > >
> > > First, please turn these back into normal functions in random.c.
> > > Inlining functions is generally discouraged these days unless you have a
> > > good reason and numbers to back it up.
> > 
> > Ingo wanted to hide that #ifdef to .h
> 
> Ahh. I think that makes sense in some situations, but I'd prefer not to 
> do that here. Some headers are actually meant to be more readable than 
> the corresponding .c file. Also, we still end up with an ifdef in the .c 
> file so we're not actually winning.

Yinghai - i think Matt is right and there are a number of things we could 
do to improve cleanliness here. (Matt, sorry about this - we'll quickly 
fix it.)

The most important thing to observe is that the irq_desc->timer_rand_state 
cleanup you did should be made unconditional, and should not depend on 
SPARSE_IRQ. That will eliminate most of the #ifdefs, and it makes the 
random.c and random.h impact rather straightforward.

Another cleanliness detail is that these types of checks:

#ifndef CONFIG_SPARSE_IRQ
        if (irq >= nr_irqs)
                return;
#endif

can go away completely. They were needed from the sparseirq data model 
that had a dynamic array size - but that is not so anymore, so we can 
remove these complications.

Agreed?

	Ingo

  reply	other threads:[~2009-01-02 15:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-31 18:29 random.c changes for sparse irq_desc are crap Matt Mackall
2008-12-31 23:07 ` Yinghai Lu
2008-12-31 23:40   ` Matt Mackall
2009-01-01  0:14     ` Yinghai Lu
2009-01-01  9:31       ` Matt Mackall
2009-01-02 15:59         ` Ingo Molnar [this message]
2009-01-03  8:06           ` [PATCH] sparseirq: move set/get_timer_rand_state back to .c Yinghai Lu

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=20090102155922.GD1180@elte.hu \
    --to=mingo@elte.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=torvalds@osdl.org \
    --cc=yinghai@kernel.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 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.