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.
Setting up a scheme with two sets of names is hard. I say this from the point of view of having set up many research kernel trees and having tried several times to sort this out in an aesthetically pleasing way... there are a lot of things that don't fit tidily into such a model. One of the more vexing problems: what do you call the "platform" for x86? There are lots of things you *can* call it, ranging from "generic" to "peecee", but they're all either confusing or wanky. Also, there's the potential complication of platforms that are the same except for the CPU plugged into them; we already have a bit of this with hpcarm/hpcmips/hpcsh, but it could get quite a bit worse, e.g. an emulator that has switchable cpu modules but otherwise has all exactly the same stuff in it. I eventually concluded that the way it's done in netbsd (one set of names, with semantics varying as needed) was the best available choice. 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". 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