On 10/31/07, David Howells <[EMAIL PROTECTED]> wrote: > > Does this mean cpu-am33v3, cpu-am33v4, etc. will be created > > when a new core comes up? > > Yes. Note that the headers in a later one can 'inherit' from those of an > earlier one simply by #including that earlier one, much like archs do with > asm-generic headers.
GCC is willing to include the earlier one. But people aren't, are they? If cpu-am33v3/cpu-regs.h #includes cpu-am33v2/cpu-regs.h, people have to 1) open cpu-am33v3/cpu-regs.h, saying #include <asm/cpu-am33v2/cpu-regs.h> (and sigh). 2) open cpu-am33v2/cpu-regs.h. This decreases development efficiency. If there is no difference and they are all #including only headers, there is nothing but development efficiency decrease. It is not too late to split into directories only after some large difference to the earlier one comes on. And at that time asm/cpu-regs.h should #include cpu/cpu-regs.h and people would #include asm/cpu-regs.h for the general purpose so that they aren't confused which is cpu-specific and which is proc-specific. > > Isn't it possible to split codes by features, instead of target cores? > > Perhaps, but I personally am not in a position to judge what features are > common to what CPUs. I'll have to let someone from MEI answer that one. I'll > discuss it with them. Ok. I'll wait. > > Stranger names here. > > How so? The file is under cpu/, but the names are mn103e010_* which is proc-specific. -- Suzuki Takashi Japan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
