, Matt Thomas <matt@3am-software.com>
From: Chris Gilbert <chris@paradox.demon.co.uk>
List: tech-kern
Date: 07/13/2001 00:16:11
On Thursday 12 July 2001 7:12 pm, Noriyuki Soda wrote:
> >>>>> On Thu, 12 Jul 2001 10:35:44 -0700,
>
> Matt Thomas <matt@3am-software.com> said:
> >> If everything worked fine, it was ok.
> >> But the change breaks "make build" on even arm port.
> >
> > Not every. arm32 still works. Only the new ports are
> > currently broke,
> >
> >> So, it should be backed out, at least until the problem is solved.
> >> Shouldn't it?
> >
> > No.
>
> This is where we disagree.
> I think it may be ok to break ports for few days. (It is not really
> ok, preciously. But all we are human, so we cannot be perferct.)
I'm sorry, but ports can get broken for long periods and we don't go ooh it
broke lets revert the change. A few months back the riscpc kernel wouldn't
work because it lacked kvm space, did we back out the core kernel changes
that did that, no, we fixed the riscpc kernel.
> But new arm ports are broken for one month already, and the consensus
> to fix the problem is still not made.
Yep it's been a month or more, but I've not seen any complaints about it. As
for why it's not been sorted out yet, I believe it's just that no-one has had
the time to actually look into the issue till now.
> This is why I think the change should be backed out until the issue
> is fixed.
I disagree, I don't want to spend half my life reverting changes that have
been made, to only put them back in at a later date.
> Note that you can revive the change as soon as the problem is really
> fixed. I also think that the way to solve the problem should be
> reviewed on architecture independent mailing list, btw. Because
> not only arm people, but also all we want the shared userland.
I would have prefered more time to assess the scope of the build problems so
that we could say right, arm make build doesn't work because of x y and z.
Anyway my currently list of problems is:
gnu/lib/libstc++/config - needs makefile tweaking to install _G_config.h in
/usr/include/arm (I'm not to sure if that's the best place as currently arm26
is built with 2.95.x and arm32 with the intree egcs, so they may differ?)
need dummy (empty) machine/pmap.h to keep dependancies happy
(uvm/uvm_extern.h seems to include it, and then it feels like half the world
includes that ;)
we're missing a few bits from machine/param.h, currently I'm finding those
that are missing and adding them (so far they're the same on arm32 and arm26)
biggest pain with machine/param.h is that everything seems to have a
dependancy on it!
libkvm needs a few real kernel header files, not the dummy ones, eg pcb.h
vmparam.h pmap.h However I expect libkvm to be more closely tied to the
kernel than anything else and may require some sysctl's to make it shared
across arm26 and arm32.
I aim to get a full list together over this weekend so that a proper
assessment of the issues can be made.
Cheers,
Chris
PS please note that next week I've no time to deal with this as I'm out
every night doing a bit of acting :)