Subject: Re: /usr/include/machine
To: None <chris@paradox.demon.co.uk>
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
List: tech-kern
Date: 07/16/2001 22:41:13
In article <01071519054800.12609@pinky.paradox.demon.co.uk>
chris@paradox.demon.co.uk writes:

> > Currently, any {mipsel,mipseb,m68k,powerpc,sh3el} binary run on
> > any {mipsel,mipseb,m68k,powerpc,sh3el} archtecture.
> > So that is not a reason to introduce "a new technique."

> I think you're missing the fact that arm26 and arm32 are not quite the same, 
> but so close that we can make it work, but there is some work to be done.
 :
> All of which were correct for what was being done, which was to remove 
> redundant headers from the kernel.  why have lots copies of the same file and 
> have to keep them all in sync, when we can just as easily have 1 copy that's 
> shared.

You say two things:
 - sharing all binary between arm26 and arm32
 - removing redundant header files
I agree with both of them, but I don't think these should be done
at the same time because these are actually independent matters.
As you know, current m68k libkvm supports three different pmap
with single binary.

> Yes it has broken userland, but it will get fixed.

How, when and who will do? Why has it been broken more than a month?
I have no objection against your goals but have doubts about
its procedure, as Soda-san wrote. If changes are well-designed and
the only problem is code implementation, it would be worth
to commit them first for everyone to test them, but in this case
all changes should be cosmetic and they can easily be tested
before committing. (just typing `make build')

> If you have a 
> desperate need to compile userland change the machine symlink to point at 
> arm32, and it should all work.

I don't think providing "workaround" is enough. We should have
a detailed plan. At least, the "workaround" should be default.

> > I think any chaneg of framework like this should be done
> > among the all archtecture.
> 
> Why?  I believe it should be tried out to see if it works.  That's what is 
> currently being done on cats, dnard and netwinder.

Ok, I agree userland programs should not refer kernel headers.
But then the first thing we have to do is to remove reference
of machine-dependnet kernel constants from userland programs,
like what was done for ps(1) by matt.
(maybe we also have to remove the reference in LKMs.)

"Removing redundant headers" could happen after that.
It is a quite machine-independent issue and there are many
things to do it. For example, currently Makefile.arm create
${COMPILE_DIR}/include/{machine,${MACHINE_ARCH}} symlinks
but config(8) also creates ${COMPILE_DIR}/machine symlinks.
We should not have such inconsistency.
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp