On Sun, Feb 22, 2004 at 09:07:23AM -0600, D J Hawkey Jr wrote:
> On Feb 23, at 01:05 AM, Tony Frank wrote:
> > On Sat, Feb 21, 2004 at 11:23:28AM -0600, D J Hawkey Jr wrote:
> > > On Feb 21, at 05:56 PM, Gabriel Ambuehl wrote:
> > > >
> > > > DJHJ> Second, two machines are of the same architecture, but they have
> > > > different
> > > > DJHJ> CPUs: One is an Intel PIII, but the other is a PII. Will the world built
> > > > DJHJ> on a PIII be correct for a PII? Similarly, will the kernel for the PII
> > > > DJHJ> built on a PIII be correct for the PII, given the different variables and
> > > > DJHJ> settings in the two kernel configuration files?
> > > >
> > > > Just make sure you build for 686. If that doesn't work, make it 586 (I
> > > > think the PI qualifies as 686 but I'm not entirely sure). I think the
> > > > extensions such as
> > > > SSE etc are detected dynamically and shouldn't cause any problem.
> > > > In all my years of messing with builds, I never run into this problem,
> > > > so I guess it's pretty safe.
> > > Yes, both [my] machines define I686_CPU.
> > >
> > > "Dynamically", as in "at runtime"? I think you're right, but I don't
> > > know for certain, either. This is exactly what I'm wondering about;
> > > the PII has only MMX, for instance, while the PIII has SSE and MMX2.
> > >
> > > I assume the world's codebase is CPU-agnostic within an architecture,
> > > but I really don't want to assume this; I'd rather know this.
> > I have PII, Celeron, PIII and P4 in my environment.
> > All these use "I686_CPU" in my kernel configs (I got rid of the other I_CPU
> > types.
> In a desktop's kernel config:
> machine i386
> cpu I686_CPU
> ident SHEOL
> In my laptop's kernel config:
> machine i386
> cpu I686_CPU
> ident CHARON
> Getting difficult, isn't it? ;-,
> Boot messages on that desktop from kernel built on that desktop:
> CPU: Pentium III/Pentium III Xeon/Celeron (764.35-MHz 686-class CPU)
> Origin = "GenuineIntel" Id = 0x686 Stepping = 6
> Boot messages on that laptop from kernel built on that laptop:
> CPU: Pentium II/Pentium II Xeon/Celeron (233.87-MHz 686-class CPU)
> Origin = "GenuineIntel" Id = 0x652 Stepping = 2
> > In /etc/make.conf I include "CPUTYPE=p2" as the lowest common denominator if
> > including a CPUTYPE flag.
> > The resulting world & kernel run fine on all the systems.
> > The higher flags p3 and p4 still just use -march=pentiumpro, however for SSE you
> > will need p3 or p4 as MACHINE_CPU does not include SSE for p2 level.
> > Check out /usr/share/mk/bsd.cpu.mk for specifics.
> If I read things right, the first chunk in bsd.cpu.mk results in
> "CPUTYPE = i686"; the conditional-on-CPU_TYPE-defined assignment
> sees "cpu I686_CPU" in the kernel configs, right?.
I'm not sure the kernel config is used for this - beyond my current depth. :)
> The second
> chunk in bsd.cpu.mk also results in "CPUTYPE = i686" (fallthrough).
> The third chunk results in "_CPUCFLAGS = -march=pentiumpro", as
> you state. Finally, the last chunk in bsd.cpu.mk results in
> "MACHINE_CPU = i686 i586 i486 i386".
> If I specify "CPUTYPE=p2" in make.conf, and I'm still reading
> things right, the final result in bsd.cpu.mk would be the same
> _CPUCFLAGS, and "MACHINE_CPU = i686 mmx i586 i486 i386".
> But based on the boot messages, it would seem that the features of
> the chips are detected correctly without specifying a CPUTYPE in
> make.conf. So... As things are right now (no CPUTYPE in make.conf),
> it would appear that "CPU feature" code is built into the kernels
> on the respective machines, and that code correctly detects the
> features available. Therefore, I don't see where adding CPUTYPE
> in make.conf would get me anything I'm not already getting?
CPU feature detection is done elsewhere, the make.conf entry I think will just
set the flag so if code elsewhere is written to check for those flags it
will use the appropriate bits.
> That is, why make things more specific than they have to be?
> I don't see where adding "CPUTYPE=p2" on a PIII build machine
> would change anything for PII and/or PIII target machines. What
> have I missed?
I believe there are one or two areas of code (openssl?) that do make
use of these flags and enable some optimised routines.
Perhaps you can try comparing output of 'openssl speed' after compiling
with different options?
(eg for CPUTYPE empty, i686 and p2)
Someone more familiar with the kernel internals might be able to offer more insight
> > > > DJHJ> /etc/defaults/make.conf doesn't mention KERNCONF; /usr/src/Makefile.inc1
> > > > DJHJ> does. Since /usr/share/mk/sys.mk sucks in /etc/make.conf, that should
> > > > DJHJ> propogate KERNCONF to /usr/src/Makefile, right?
> > To your original question, yes.
> > Just add a KERNCONF= line to /etc/make.conf.
> > First entry should be the local machine kernel (to install) and
> > any subsequent entries will also be built during 'make buildkernel'
> > eg: KERNCONF= MARVIN RAIDER RAIDERI GENERIC
> > make buildkernel builds all four.
> > make installkernel installs MARVIN.
> Cool. So, the -CURRENT (or is that -STABLE?) Handbook does apply
> to 4.5-REL, at least where this stuff is concerned.
I will not comment for your 4.5 specifically but it has worked for me for last
few years. Could probably lookup the makefile revision history to
see when it changed but I'm not really that interested. :)
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"