>
> I only see problems where there are problems; we're not talking about
> hypothetical computers, we're talking about actual computers where we c=
an
> actually run code. I know that my kernels and none of my binaries are
> compiled with SSE. I also know that most distributed binaries certainly
> never use such code.

Well but what is with others? Having the possibility to use Intel's C Com=
piler=20
enables one to use SSE without changing a bit of code, the speed improvem=
ent=20
is very high (on my box it was factor 2 compared to gcc 2.95.3 with povra=
y).=20
So there is a point - just more logic has to be implemented in the kernel=
,=20
for just a bunch of people - do we want to be an operating system designe=
d=20
only for a friction of computer users?

>
> > No, it isn't supported. "Works for you" and "supported" are
> > different. "Supported" doesn't mean "will boot and run". "Supported"
> > means that the bulk of us working on NetBSD will care enough to help
> > if it doesn't work or stops working. "Supported" also means "we
> > recommend/encourage this usage".
>
> Fine. So it's known to work, but not supported as in "Officially Approv=
ed
> By The Entirety Of NetBSD". I don't see the point of making a big deal
> about it. As I said before, it's not like we're making guarantees here =
or
> anything.
>
> > We don't encourage this bad idea. We say outright it is a bad idea. I=
t
> > isn't supported. If it "happens to work for you", well fine, but we
> > aren't going to go out of our way to make sure it will work, or to
> > make sure it continues to work.
>
> Please illustrate how, aside from speculation, it's a bad idea.  Will y=
ou
> also tell the people running SPARCs that what they're doing is bad? Thi=
s
> attitude is not a good one. Code should be correct no matter what.
>
> An example where assumptions would be bad: what if a CPU in a dual
> processor system started overheating, and was automatically throttled
> down? Would we want our kernel to panic because one CPU is now a differ=
ent
> speed than the other? I prefer correct code.

I don't think this is a good example, because the CPUs are assumed to run=
 on=20
full speed under normal circumstances. If one cpu get's down, the best=20
solution would only be to shut down this box to exchange broken hardware =
or=20
to set up better cooling. If the box built up correctly this should only=20
happen with broken fans, which most mp boards signal with loud beeping, s=
o=20
why not changing fan before the cpu overheats (most intel cpus in my=20
experience run for some time, before overheating if a heatsink is attache=
d).=20
And I don't think the kernel will panic, as far as I understand these=20
calibrations loops, they are for scheduling and stuff, when an exact numb=
er=20
of seconds or so has to be hit, so some process just doesn't get it's tim=
e or=20
is woke up too late, the system will run, but slow, doesn't it?

>
> > If, for example, you said "hey, the change you just made broke my
> > differing-CPU MP configuration", I doubt anyone would care enough to
> > spend time debugging it for you, which is very different from what
> > would happen if you noted that a supported configuration was
> > broken. If you then provided a patch that made it work for you again
> > and it caused no harm to anyone else, it might be accepted -- but it
> > is unlikely anyone else would bother to create such a patch.
> >
> > That's what "not supported" means.
> >
> > So, to be clear, consensus seems to be "different CPUs running in MP
> > is not supported". Not "will never happen to run". "Not supported".
>
> When you make the distinction that way, fine; again, I care little abou=
t
> semantics. So it's not "supported", but it certainly does run, and ther=
e
> are no technical reasons it shouldn't.
>
> I will do my best to test these machines with NetBSD as much as I can, =
and
> I will even look at the CPU spinup code to see if I can correct the mos=
tly
> aesthetic speed reporting bug. And if something should "break" so that
> these systems no longer work, I will do my best to figure out what caus=
ed
> the break and suggest alternative, or possibly "more correct", ways of
> doing that thing.
>
> Thanks,
> John Klos
> Sixgirls Computing Labs

--=20
Greetings
Matthias Kretschmer