-----Original Message-----
From: Toru Nishimura <nisimura@itc.aist-nara.ac.jp>
To: port-mips@netbsd.org <port-mips@netbsd.org>;
nisimura@itc.aist-nara.ac.jp <nisimura@itc.aist-nara.ac.jp>
Date: Tuesday, January 18, 2000 9:46 AM
Subject: Re: CPU specific idle routine


>> I think that locore_jumpvec is not so bad...
>>
>> Anyway, that issue, throwing locore_jumpvec away is beyond my
>> control. Could I put the new member into locore_jumpvec for now ?
>
>"It's the way of kitchen sink," I believe.  You need global design sense
>beyond solving in-the-place issues.
>
>Take a look at sparc or arm32 about processor encapsulations.
>Primitives depending designs and parameters could be treated in a
>similar way.  Wiredown handlers are of subject.  Taking locore
>routines into parts should be considered carefully as it'd be easily
>result in tangled codes.


I've been looking arm32/arm32/*.S code pieces. Some locore routines
have ther own file. I think that's good. But I can't find any hooking
mechanism which allows dynamic configuration depending on CPU.

I think that dividing locore and dynamic configuration are separate
issues, however, they are closely related with. If we divide locore.S
into some files appropriately, we still need logically-unified hook
table like locore_jumpvec which contains all locore functions.
We must not divide the table. If we have two or more tables, it is
very difficut to select table. An idea of processor v.s. board design
is not suitable to embedded system like PDA, bacause they are nealy
one-chip computers.

So, I think the locore_jumpvec is good.

Takemura