Re: Incoming to hostme.bitkeeper.com:/ua/repos/p/ppc/linuxppc_2_4

Re: Incoming to hostme.bitkeeper.com:/ua/repos/p/ppc/linuxppc_2_4

[Tom Rini]

On Thu, Nov 28, 2002 at 06:48:10PM -0800, ppc@bkbits.net wrote:

> ChangeSet@1.722, 2002-11-28 19:44:54-07:00, trini@kernel.crashing.org
>   Merge kernel.crashing.org:/home/trini/work/kernel/pristine/linux_2_4
>   into kernel.crashing.org:/home/trini/work/kernel/pristine/linuxppc_2_4
>   TAG: v2.4.20_linuxppc_2_4
>
>   Makefile@1.178, 02-11-28 19:44:13-07:00, trini@kernel.crashing.org
>     Auto merged
>
> ChangeSet@1.2.2.167, 2002-11-28 19:43:57-07:00, trini@kernel.crashing.org
>   patch-2.4.20-rc4-final
>   TAG: v2.4.20
>
>   Makefile@1.19.1.157, 02-11-28 08:55:34-07:00, trini@kernel.crashing.org
>     Import patch patch-2.4.20-rc4-final

And with the start of this, all final releases in the linuxppc_2_4 and
linuxppc_2_4_devel trees will have a tag for the merge of that release
into that tree.  Which means that in a linuxppc_2_4_devel tree, bk
export -tplain -rv2.4.20_linuxppc_2_4_devel will get the
linuxppc_2_4_devel tree, as of 2.4.20.

Tags might be added to previous revisions if time permits, or someone
produces a nifty script to find out what revisions corrispond to what :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Incoming to hostme.bitkeeper.com:/ua/repos/p/ppc/linuxppc_2_4

[Tom Rini]

On Thu, Aug 16, 2001 at 10:23:18AM -0700, ppc@bitkeeper.com wrote:

> ChangeSet@1.272, 2001-08-16 10:22:52-07:00, trini@opus.bloom.county
>   More minor changes to let !CONFIG_6xx compile again, arg!  Who
>   knew the _{set,get}_L2CR bits were so heavily embedded? :)

Okay.  What I'm about to do in 2_4_devel, is try and rip these out a bit
more cleanly.  Right now, outside of platform-specific files, kernel/sysctl.c
can make use of L2CR stuffs.  Since we now have a change pending to Linus,
I want to make this file only care about proc_dol2crvec on CONFIG_6xx,
and likewise only compile in ppc_htab.c on CONFIG_6xx as well.  Right
now proc_dol2crvec -EFAULT's on CPUs which don't have the feature, so
this shouldn't be an issue any more (iirc, some other stats had been
thrown in now and again by other cpu-types).  Do this will also let us
remove the !8xx && !4xx test in ppc_htab_read.  Does this sound good to
everyone?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Incoming to hostme.bitkeeper.com:/ua/repos/p/ppc/linuxppc_2_4

[Paul Mackerras]

Tom Rini writes:

> > ChangeSet@1.272, 2001-08-16 10:22:52-07:00, trini@opus.bloom.county
> >   More minor changes to let !CONFIG_6xx compile again, arg!  Who
> >   knew the _{set,get}_L2CR bits were so heavily embedded? :)
>
> Okay.  What I'm about to do in 2_4_devel, is try and rip these out a bit
> more cleanly.  Right now, outside of platform-specific files, kernel/sysctl.c

Hmmm.  I think this is a situation where you need to realize that
you're digging yourself into a hole, stop, sit back and think about it
a bit more.

You're wanting to remove code that isn't used on particular
platforms.  That's fine.  But then you get tripped up in all the
places where that code could be called.  You are solving that by
adding #ifdefs everywhere, which is the wrong answer.

The right answer is instead to make it look like the code is there
even when it isn't.  One reasonable approach would be to put something
like this in asm-ppc/system.h:

#ifdef CONFIG_6xx
extern unsigned int _get_L2CR();
extern void _set_L2CR(unsigned int);
#else
#define _get_L2CR()	0
#define _set_L2CR(x)	do { } while (0)
#endif

and now you can call _get/set_L2CR quite safely anywhere without any
ifdefs.

> can make use of L2CR stuffs.  Since we now have a change pending to Linus,
> I want to make this file only care about proc_dol2crvec on CONFIG_6xx,
> and likewise only compile in ppc_htab.c on CONFIG_6xx as well.  Right

As for /proc/ppc_htab, that is useful (despite its name) on systems
that don't use a hash table - there it gives info about TLB misses
IIRC.  It is also useful on power3/4 as well as 6xx.

> now proc_dol2crvec -EFAULT's on CPUs which don't have the feature, so
> this shouldn't be an issue any more (iirc, some other stats had been
> thrown in now and again by other cpu-types).  Do this will also let us
> remove the !8xx && !4xx test in ppc_htab_read.  Does this sound good to
> everyone?

Nope. :)  It could have a better name, though.

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Incoming to hostme.bitkeeper.com:/ua/repos/p/ppc/linuxppc_2_4

[Tom Rini]

On Fri, Aug 17, 2001 at 03:46:05PM +1000, Paul Mackerras wrote:
> Tom Rini writes:
>
> > > ChangeSet@1.272, 2001-08-16 10:22:52-07:00, trini@opus.bloom.county
> > >   More minor changes to let !CONFIG_6xx compile again, arg!  Who
> > >   knew the _{set,get}_L2CR bits were so heavily embedded? :)
> >
> > Okay.  What I'm about to do in 2_4_devel, is try and rip these out a bit
> > more cleanly.  Right now, outside of platform-specific files, kernel/sysctl.c
>
> Hmmm.  I think this is a situation where you need to realize that
> you're digging yourself into a hole, stop, sit back and think about it
> a bit more.

Well, alright.

> You're wanting to remove code that isn't used on particular
> platforms.  That's fine.  But then you get tripped up in all the
> places where that code could be called.  You are solving that by
> adding #ifdefs everywhere, which is the wrong answer.

Well, I've been trying to remove 'em actually.  What I ended up pushing
added 1 more #ifdef/#endif and removed 2 older ones from ppc_htab.c

> > can make use of L2CR stuffs.  Since we now have a change pending to Linus,
> > I want to make this file only care about proc_dol2crvec on CONFIG_6xx,
> > and likewise only compile in ppc_htab.c on CONFIG_6xx as well.  Right
>
> As for /proc/ppc_htab, that is useful (despite its name) on systems
> that don't use a hash table - there it gives info about TLB misses
> IIRC.  It is also useful on power3/4 as well as 6xx.

Well, if I'm reading the htab code right, we -EFAULT on on !750/74xx.
I could be misinterpreting something, but I don't see it printing out
anything that isn't hashtable related.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Incoming to hostme.bitkeeper.com:/ua/repos/p/ppc/linuxppc_2_4

[Tom Rini]

On Fri, Aug 17, 2001 at 03:46:05PM +1000, Paul Mackerras wrote:
> Tom Rini writes:
>
> > > ChangeSet@1.272, 2001-08-16 10:22:52-07:00, trini@opus.bloom.county
> > >   More minor changes to let !CONFIG_6xx compile again, arg!  Who
> > >   knew the _{set,get}_L2CR bits were so heavily embedded? :)
> >
> > Okay.  What I'm about to do in 2_4_devel, is try and rip these out a bit
> > more cleanly.  Right now, outside of platform-specific files, kernel/sysctl.c
>
> Hmmm.  I think this is a situation where you need to realize that
> you're digging yourself into a hole, stop, sit back and think about it
> a bit more.

Well, this does let us kill the #ifs in arch/ppc/kernel/setup.c in both
trees, and will protect against the future to boot.  It also removes the
Power3/4 kludge.  Thanks, done. :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/