On 24 June 2015 at 23:38, David Holland <dholland-t...@netbsd.org> wrote: > On Wed, Jun 24, 2015 at 04:01:24PM -0700, Matt Thomas wrote: > > > > I agree that evb* is confusing and increasingly meaningless and > > > would like to see us transition away from it. > > > > I contend that moving to sys/arch/<cpu> is incorrect which there > > are multiple MACHINE values for that CPU. sys/tem/mips (haha!) or > > sys/platform/mips (yuk) or sys/arch/<cpu>sys or something better.
It's all too confusing. I'd like to be able to do: ./build.sh rpi but instead I use: ./build.sh -... evbarm and likely build far more than I need. > [...] > > That said, given the ability to have multiple userland builds for a > given "port", which is more or less necessary now with all the arm > variants, there's no real reason to have more than one "port" per cpu > type. One of the traditional criteria was whether you needed a > different kernel; but nowadays having different configs (as evbarm > does) is good enough. Similarly, even if you need a different > bootloader we should be able to sort that out without having a whole > separate "port". This probably illustrates why 'cpu' has become so overloaded. When building userland, "cpu" identifies: - a system-call convention for the architecture - user instruction set architecture (to borrow an IBM term) + calling convention (application binary interface) - and? How do I build a 32-bit LE soft-float Arm9 userland? Or more more seriously, how can I build just a arm7hf targeted compiler and user land? For the kernel "cpu" means a lot more: - first, the kernel can adopt its own ISA/ABI (64-bit kernel, 32-bit userland) - chip-family specific code for dealing with VM and context switches - other stuff I can't think of (IBM called this the operating environment architecture). Perhaps, rather than trying to re-organize the source tree, the first step is to look at build.sh. For instance: - clarify/simplify the terminology (MACHINE_ARCH / -e seems to be the ISA/ABI) perhaps "./build.sh -e arm7hf tools sets" builds my arm7hf userland, it isn't clear - allow finer grained "machines" or platforms so I can have "./build.sh -m rpi" do the right thing Only once the model seems to be working, start looking at the source code. Andrew > So in the long run I'd say it should just go by cpu type. But as > mashing together e.g. everything in sys/arch/arm and everything in > sys/arch/evbarm would add a lot of entropy, I think we need a stronger > model for the substructure of these directories than we currently > have. > > (Also, I think MD stuff should be distributed around the tree more; we > should e.g. keep MD virtual memory stuff in sys/uvm/arch. And we > should keep MD system call stuff in sys/syscall/arch or something like > that, although this first requires splitting sys/syscall out of > sys/kern. Splitting things up this way requires some attention to > MD-level interfaces between subsystems; but having gone through that > with a research kernel I'd say it's beneficial.) > > all this is moot when we can't cvs rename though... > > -- > David A. Holland > dholl...@netbsd.org