* Re: When to #ifdef on CPUs?
2002-09-13 1:58 When to #ifdef on CPUs? Matthew Dharm
@ 2002-09-13 7:22 ` Maciej W. Rozycki
2002-09-13 9:08 ` Kevin D. Kissell
2002-09-13 10:51 ` Kevin D. Kissell
2 siblings, 0 replies; 5+ messages in thread
From: Maciej W. Rozycki @ 2002-09-13 7:22 UTC (permalink / raw)
To: Matthew Dharm; +Cc: Linux-MIPS
On Thu, 12 Sep 2002, Matthew Dharm wrote:
> So, what's the rule here? When do I used #ifdef and when do I just
> let the PRID stuff work it's magic?
>
> I mean, heck... it might be nice to put a check to see if the detected
> CPU matches what the kernel was compiled for...
Well, we might be able to build generic kernels one day. So you need to
judge whether some bits of code are needed/useful if run on your processor
in a generic configuration (use PRId then) or are specific to a
configuration dedicated to your processor (use a config option then).
There are places in the existing code that violate the rule but the
reasons are mostly historical and they will hopefully get cleaned up
sooner or later (I have a few of them on my to-do list, too). Thus please
don't be much too influenced by old code.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: When to #ifdef on CPUs?
2002-09-13 1:58 When to #ifdef on CPUs? Matthew Dharm
2002-09-13 7:22 ` Maciej W. Rozycki
@ 2002-09-13 9:08 ` Kevin D. Kissell
2002-09-13 10:34 ` Maciej W. Rozycki
2002-09-13 10:51 ` Kevin D. Kissell
2 siblings, 1 reply; 5+ messages in thread
From: Kevin D. Kissell @ 2002-09-13 9:08 UTC (permalink / raw)
To: Matthew Dharm, Linux-MIPS
From: "Matthew Dharm" <mdharm@momenco.com>
> I'm basically done with my task of porting linux to our SR71000-based
> board. I'm getting ready to start feeding patches to Ralf, and
> something occured to me....
>
> Sometimes, in some places, we use CONFIG_ options to select the
> apropriate CPU. Other places, we probe for the CPU based on the PRID
> register.
>
> In some places, the reason for the choice is clear -- it's just much
> easier to select the cache library based on a CONFIG_ option in a
> Makefile than trying to do run-time assignment of many function
> pointers.
>
> However, is some places, the choice is not clear. In cpu-probe.c, for
> example, several of the CPU identification routines are wrapped in
> #ifdef's -- odd, since the wrong 'case' of the switch statements
> should never get executed, even if compiled in....
There is a big discontinuity between the R3000 privileged resource
model and that of the R4000 and later CPUs. So it would not surprise
me if the MIPS/Linux kernel retained some R3000/non-R3000
conditional code for a while longer. Much of rest of what you're
seeing, particularly in cpu-probe.c, is just slop - expedient hacks
that somehow became permanent.
But the ambivalence between run-time and build-time binding
to CPUs probably also reflects the two poles of use of
MIPS/Linux. The folks who use it on old SGI and DEC
workstations have platforms like the SGI Indy where the
same relatively RAM-rich platform configuration can support
a number of different CPUs . That tends to lead to run-time
binding of the CPU-specific routines and parameters.
The folks who use it for embedded apps tend to have
system and peripheral setups that are anyway pretty
application-specific, and since memory isn't entirely free,
there's no advantage, and some slight disadvantage,
in including code to support other CPUs in the OS image.
And there are, alas, cases where the designers screwed up
and failed to provide a correctly unique PrID register value,
such as is apparently the case with the NEC Vr4111 and
VR4181. I'd be willing to bet that there is *some* way to
distinguish those two parts at run-time if one really wanted
to, though.
> So, what's the rule here? When do I used #ifdef and when do I just
> let the PRID stuff work it's magic?
I don't know that there's a rule as such, but I would strongly
recommend using the PrID and Config registers to generate a
kernel CPU ID and a set of mips_cpu.options bits, and that
information abstracted into the mips_cpu structure should be
used in preference to comparing against CPU ID's. It may
require a little more thought up-front, but it leaves the rest
of the code a lot easier to maintain. You should have seen
what the kernel looked like before we introduced the
mips_cpu structure!
> I mean, heck... it might be nice to put a check to see if the detected
> CPU matches what the kernel was compiled for...
If it doesn't, that's a bug.
Kevin K.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: When to #ifdef on CPUs?
2002-09-13 9:08 ` Kevin D. Kissell
@ 2002-09-13 10:34 ` Maciej W. Rozycki
0 siblings, 0 replies; 5+ messages in thread
From: Maciej W. Rozycki @ 2002-09-13 10:34 UTC (permalink / raw)
To: Kevin D. Kissell; +Cc: Matthew Dharm, Linux-MIPS
On Fri, 13 Sep 2002, Kevin D. Kissell wrote:
> There is a big discontinuity between the R3000 privileged resource
> model and that of the R4000 and later CPUs. So it would not surprise
> me if the MIPS/Linux kernel retained some R3000/non-R3000
> conditional code for a while longer. Much of rest of what you're
Well, code paths may be selected via indirect calls and variable
references. That may be tedious and require much care when implementing,
but it is doable.
> seeing, particularly in cpu-probe.c, is just slop - expedient hacks
> that somehow became permanent.
A few fixes here is pending on my short-term to-do list. I'd like to get
rid of #ifdefs here as they are unnecessary.
> But the ambivalence between run-time and build-time binding
> to CPUs probably also reflects the two poles of use of
> MIPS/Linux. The folks who use it on old SGI and DEC
> workstations have platforms like the SGI Indy where the
> same relatively RAM-rich platform configuration can support
> a number of different CPUs . That tends to lead to run-time
> binding of the CPU-specific routines and parameters.
> The folks who use it for embedded apps tend to have
> system and peripheral setups that are anyway pretty
> application-specific, and since memory isn't entirely free,
> there's no advantage, and some slight disadvantage,
> in including code to support other CPUs in the OS image.
I have the Alpha approach in mind. The idea is to select between a
generic and a system-specific kernel. With the former there is a vector
of available configurations one of which is selected early in the boot
process. Items from the vector element chosen are accessed indirectly.
With the latter only a single element of the vector is build and its
contents are accessed directly with the help of some preprocessor magic.
> And there are, alas, cases where the designers screwed up
> and failed to provide a correctly unique PrID register value,
> such as is apparently the case with the NEC Vr4111 and
> VR4181. I'd be willing to bet that there is *some* way to
> distinguish those two parts at run-time if one really wanted
> to, though.
Well, if the chips differ, which is the case as I infer from what you
wrote, then the difference between them may be used to determine which one
of them a system is being executed on.
> > I mean, heck... it might be nice to put a check to see if the detected
> > CPU matches what the kernel was compiled for...
>
> If it doesn't, that's a bug.
No, it's a user fault. And it's nice to the user to print an appropriate
message and panic() explicitly instead of crashing in an interesting way.
This is currently being done for the R3k vs R4k in the DECstation-specific
code, but it might be beneficial to expand it move it somewhere to the
generic code.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: When to #ifdef on CPUs?
2002-09-13 1:58 When to #ifdef on CPUs? Matthew Dharm
2002-09-13 7:22 ` Maciej W. Rozycki
2002-09-13 9:08 ` Kevin D. Kissell
@ 2002-09-13 10:51 ` Kevin D. Kissell
2 siblings, 0 replies; 5+ messages in thread
From: Kevin D. Kissell @ 2002-09-13 10:51 UTC (permalink / raw)
To: Matthew Dharm, Linux-MIPS
From: "Matthew Dharm" <mdharm@momenco.com>
> I'm basically done with my task of porting linux to our SR71000-based
> board. I'm getting ready to start feeding patches to Ralf, and
> something occured to me....
>
> Sometimes, in some places, we use CONFIG_ options to select the
> apropriate CPU. Other places, we probe for the CPU based on the PRID
> register.
>
> In some places, the reason for the choice is clear -- it's just much
> easier to select the cache library based on a CONFIG_ option in a
> Makefile than trying to do run-time assignment of many function
> pointers.
>
> However, is some places, the choice is not clear. In cpu-probe.c, for
> example, several of the CPU identification routines are wrapped in
> #ifdef's -- odd, since the wrong 'case' of the switch statements
> should never get executed, even if compiled in....
There is a big discontinuity between the R3000 privileged resource
model and that of the R4000 and later CPUs. So it would not surprise
me if the MIPS/Linux kernel retained some R3000/non-R3000
conditional code for a while longer. Much of rest of what you're
seeing, particularly in cpu-probe.c, is just slop - expedient hacks
that somehow became permanent.
But the ambivalence between run-time and build-time binding
to CPUs probably also reflects the two poles of use of
MIPS/Linux. The folks who use it on old SGI and DEC
workstations have platforms like the SGI Indy where the
same relatively RAM-rich platform configuration can support
a number of different CPUs . That tends to lead to run-time
binding of the CPU-specific routines and parameters.
The folks who use it for embedded apps tend to have
system and peripheral setups that are anyway pretty
application-specific, and since memory isn't entirely free,
there's no advantage, and some slight disadvantage,
in including code to support other CPUs in the OS image.
So we have an environment where boot-time CPU
binding works OK across the set of CPUs used in
Indys, and not necessarily for others.
And there are, alas, cases where the designers failed
to provide a correctly unique PrID register value, such
as is apparently the case with the NEC Vr4111 and VR4181.
I'd be willing to bet that there is *some* way to distinguish
those two parts at run-time if one really wanted to, though.
> So, what's the rule here? When do I used #ifdef and when do I just
> let the PRID stuff work it's magic?
I don't know that there's a rule as such, but I would strongly
recommend using the PrID and Config registers to generate a
kernel CPU ID and a set of mips_cpu.options bits, and that
information abstracted into the mips_cpu structure should be
used in preference to comparing against CPU ID's. It may
require a little more thought up-front, but it leaves the rest
of the code a lot easier to maintain. You should have seen
what the kernel looked like before we introduced the
mips_cpu structure!
Fortunately, the standardization of the privileged resource
architecture in the MIPS32 and MIPS64 specs means that
the problem shouldn't get much worse - newer parts should
just work with a MIPS32 kernel.
> I mean, heck... it might be nice to put a check to see if the detected
> CPU matches what the kernel was compiled for...
If it doesn't, that's a bug.
Kevin K.
^ permalink raw reply [flat|nested] 5+ messages in thread