From: Sam Ravnborg <sam@ravnborg.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: David Miller <davem@davemloft.net>,
kosaki.motohiro@jp.fujitsu.com, yinghai@kernel.org,
linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
tglx@linutronix.de
Subject: Re: irqnr fallout in gpiolib on sparc32
Date: Wed, 07 Jan 2009 13:34:36 +0000 [thread overview]
Message-ID: <20090107133436.GB2289@uranus.ravnborg.org> (raw)
In-Reply-To: <20090107130213.GB3529@elte.hu>
On Wed, Jan 07, 2009 at 02:02:13PM +0100, Ingo Molnar wrote:
>
> * David Miller <davem@davemloft.net> wrote:
>
> > From: Ingo Molnar <mingo@elte.hu>
> > Date: Tue, 6 Jan 2009 13:57:04 +0100
> >
> > > Sparc32 on the other hand had a clean IRQ layer long before x86 found its
> > > desire for a clean genirq layer - so genirq is a nuisance for Sparc32 at
> > > best and it deserves none of the not nice actions. What i am hoping for is
> > > that perhaps the Sparc unification changed that equation.
> >
> > Not really, the unificiation didn't change much in this area. [...]
>
> Yeah, i mean - "changed the equation" psychologically, the same way it did
> it on x86.
>
> There's now two files close to each other in the namespace:
>
> earth4:~/tip> ls -l arch/sparc/kernel/irq*.c
> -rw-rw-r-- 1 mingo mingo 16122 2009-01-07 13:50 arch/sparc/kernel/irq_32.c
> -rw-rw-r-- 1 mingo mingo 26556 2009-01-07 12:34 arch/sparc/kernel/irq_64.c
>
> Each of them crying out loud to be unified. Every time you open irq_64.c
> you'll think "why that ugly _64.c postfix, shouldnt this be irq.c
> instead?" ;-)
>
> That kind of gentle pressure to unify comes straight from the fact that
> there's _32.c and _64.c postfixes around and the postfixes mess up command
> completion when those files are opened, so we notice the non-unified-ness
> again and again.
I most remind you how you eat an elephant ;-)
You eat it bite by bite.
And you start with the easy bits first to harden your stommach.
Try to do a:
git shortlog --since=2-months arch/sparc/
I for one is very happy with what we have achieved so far.
irq_* unification will come when we reach that part.
Sam
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: David Miller <davem@davemloft.net>,
kosaki.motohiro@jp.fujitsu.com, yinghai@kernel.org,
linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
tglx@linutronix.de
Subject: Re: irqnr fallout in gpiolib on sparc32
Date: Wed, 7 Jan 2009 14:34:36 +0100 [thread overview]
Message-ID: <20090107133436.GB2289@uranus.ravnborg.org> (raw)
In-Reply-To: <20090107130213.GB3529@elte.hu>
On Wed, Jan 07, 2009 at 02:02:13PM +0100, Ingo Molnar wrote:
>
> * David Miller <davem@davemloft.net> wrote:
>
> > From: Ingo Molnar <mingo@elte.hu>
> > Date: Tue, 6 Jan 2009 13:57:04 +0100
> >
> > > Sparc32 on the other hand had a clean IRQ layer long before x86 found its
> > > desire for a clean genirq layer - so genirq is a nuisance for Sparc32 at
> > > best and it deserves none of the not nice actions. What i am hoping for is
> > > that perhaps the Sparc unification changed that equation.
> >
> > Not really, the unificiation didn't change much in this area. [...]
>
> Yeah, i mean - "changed the equation" psychologically, the same way it did
> it on x86.
>
> There's now two files close to each other in the namespace:
>
> earth4:~/tip> ls -l arch/sparc/kernel/irq*.c
> -rw-rw-r-- 1 mingo mingo 16122 2009-01-07 13:50 arch/sparc/kernel/irq_32.c
> -rw-rw-r-- 1 mingo mingo 26556 2009-01-07 12:34 arch/sparc/kernel/irq_64.c
>
> Each of them crying out loud to be unified. Every time you open irq_64.c
> you'll think "why that ugly _64.c postfix, shouldnt this be irq.c
> instead?" ;-)
>
> That kind of gentle pressure to unify comes straight from the fact that
> there's _32.c and _64.c postfixes around and the postfixes mess up command
> completion when those files are opened, so we notice the non-unified-ness
> again and again.
I most remind you how you eat an elephant ;-)
You eat it bite by bite.
And you start with the easy bits first to harden your stommach.
Try to do a:
git shortlog --since=2-months arch/sparc/
I for one is very happy with what we have achieved so far.
irq_* unification will come when we reach that part.
Sam
next prev parent reply other threads:[~2009-01-07 13:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-05 13:29 irqnr fallout in gpiolib on sparc32 Sam Ravnborg
2009-01-05 13:29 ` Sam Ravnborg
2009-01-05 13:38 ` Ingo Molnar
2009-01-05 13:38 ` Ingo Molnar
2009-01-05 13:48 ` Sam Ravnborg
2009-01-05 13:48 ` Sam Ravnborg
2009-01-05 13:55 ` Ingo Molnar
2009-01-05 13:55 ` Ingo Molnar
2009-01-05 20:37 ` David Miller
2009-01-05 20:37 ` David Miller
2009-01-06 12:57 ` Ingo Molnar
2009-01-06 12:57 ` Ingo Molnar
2009-01-06 16:29 ` David Miller
2009-01-06 16:29 ` David Miller
2009-01-07 13:02 ` Ingo Molnar
2009-01-07 13:02 ` Ingo Molnar
2009-01-07 13:34 ` Sam Ravnborg [this message]
2009-01-07 13:34 ` Sam Ravnborg
2009-01-07 21:08 ` David Miller
2009-01-07 21:08 ` David Miller
2009-01-06 23:43 ` KOSAKI Motohiro
2009-01-06 23:43 ` KOSAKI Motohiro
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=20090107133436.GB2289@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=davem@davemloft.net \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--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.