Re: Guidelines for choosing MACHINE MACHINE_ARCH?
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/cpusys 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
Re: Guidelines for choosing MACHINE MACHINE_ARCH?
On Mon, Jun 29, 2015 at 03:05:07PM -0400, Andrew Cagney wrote: - allow finer grained machines or platforms so I can have ./build.sh -m rpi do the right thing It allows aliases, so this would probaly a one line change (though you'd still get more build than only the RPI kernel). Allowing the aliases to additionally override KERNEL_SETS/BUILD_KERNELS is probably also easy, and may be worth for the evb* architectures (whatever they'll be called in the future). Martin
re: Guidelines for choosing MACHINE MACHINE_ARCH?
David Holland writes: On Fri, May 01, 2015 at 07:48:37PM +0200, Joerg Sonnenberger wrote: On Fri, May 01, 2015 at 01:58:34PM -0300, Leandro Santi wrote: A quick look at build.sh shows that one of the first things that needs to be done is to map the MACHINE name to the CPU architecture name, i.e. MACHINE_ARCH. I noticed that some ports set MACHINE=MACHINE_ARCH, but some others don't. Which leads me to the following: what are the guidelines for choosing these names? If reasonably possible, use MACHINE=MACHINE_ARCH=whatever config.guess uses for the platform. A lot of the different MACHINE values are due to historical reasons annd wouldn't happen again. I think keeping evb* for boards makes sense, though. i dunno. i don't see what it adds. in particular, evb means evaluation board, and there are heaps of things in evb* that are *not* evaluation boards, but stuff that might have once been once. i wish we'd just collapse as much as possible back to plain old MACHINE=MACHINE_ARCH=whatever. i just don't see any value or validity in evb. is ERLITE an evaluation board? what about the RPI or CUBIE* systems? they come pretty complete AFAICT, designed as end-user systems, not what we used to consider as being evalation boards. .mrg.
Re: Guidelines for choosing MACHINE MACHINE_ARCH?
On Jun 24, 2015, at 10:27 AM, Jeff Rizzo r...@tastylime.net wrote: On 6/24/15 7:13 AM, matthew green wrote: David Holland writes: I think keeping evb* for boards makes sense, though. i dunno. i don't see what it adds. in particular, evb means evaluation board, and there are heaps of things in evb* that are *not* evaluation boards, but stuff that might have once been once. i wish we'd just collapse as much as possible back to plain old MACHINE=MACHINE_ARCH=whatever. i just don't see any value or validity in evb. is ERLITE an evaluation board? what about the RPI or CUBIE* systems? they come pretty complete AFAICT, designed as end-user systems, not what we used to consider as being evalation boards. 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/cpusys or something better.
re: Guidelines for choosing MACHINE MACHINE_ARCH?
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/cpusys or something better. for older traditional ports (like m68k ones) they different MACHINEs are less of a big deal to me. they're actually descriptive and tell you something useful. evbarm? that gives me no idea beyond not being some actual particular arm platform (like shark, or cats.) it's not useful in any way beyond arm is. the alternative would be to have an insane number of MACHINEs for every platform, but i think we've already learnt that isn't the best idea (ie, while i'm less worried about m68k, i wouldn't object to them all becoming MACHINE=m68k either.) the actual source location itself is less important to me, as that isn't something the end-users really care about. i'm really only talking about the defined MACHINE string. .mrg.
Re: Guidelines for choosing MACHINE MACHINE_ARCH?
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/cpusys 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
Re: Guidelines for choosing MACHINE MACHINE_ARCH?
On 6/24/15 7:13 AM, matthew green wrote: David Holland writes: I think keeping evb* for boards makes sense, though. i dunno. i don't see what it adds. in particular, evb means evaluation board, and there are heaps of things in evb* that are *not* evaluation boards, but stuff that might have once been once. i wish we'd just collapse as much as possible back to plain old MACHINE=MACHINE_ARCH=whatever. i just don't see any value or validity in evb. is ERLITE an evaluation board? what about the RPI or CUBIE* systems? they come pretty complete AFAICT, designed as end-user systems, not what we used to consider as being evalation boards. I agree that evb* is confusing and increasingly meaningless and would like to see us transition away from it. +j
Re: Guidelines for choosing MACHINE MACHINE_ARCH?
On Fri, May 01, 2015 at 07:48:37PM +0200, Joerg Sonnenberger wrote: On Fri, May 01, 2015 at 01:58:34PM -0300, Leandro Santi wrote: A quick look at build.sh shows that one of the first things that needs to be done is to map the MACHINE name to the CPU architecture name, i.e. MACHINE_ARCH. I noticed that some ports set MACHINE=MACHINE_ARCH, but some others don't. Which leads me to the following: what are the guidelines for choosing these names? If reasonably possible, use MACHINE=MACHINE_ARCH=whatever config.guess uses for the platform. A lot of the different MACHINE values are due to historical reasons annd wouldn't happen again. I think keeping evb* for boards makes sense, though. -- David A. Holland dholl...@netbsd.org
Re: Guidelines for choosing MACHINE MACHINE_ARCH?
On Fri, May 01, 2015 at 01:58:34PM -0300, Leandro Santi wrote: A quick look at build.sh shows that one of the first things that needs to be done is to map the MACHINE name to the CPU architecture name, i.e. MACHINE_ARCH. I noticed that some ports set MACHINE=MACHINE_ARCH, but some others don't. Which leads me to the following: what are the guidelines for choosing these names? If reasonably possible, use MACHINE=MACHINE_ARCH=whatever config.guess uses for the platform. A lot of the different MACHINE values are due to historical reasons annd wouldn't happen again. Joerg
Re: Guidelines for choosing MACHINE MACHINE_ARCH?
On May 1, 2015, at 10:53 AM, David Holland dholland-t...@netbsd.org wrote: On Fri, May 01, 2015 at 07:48:37PM +0200, Joerg Sonnenberger wrote: On Fri, May 01, 2015 at 01:58:34PM -0300, Leandro Santi wrote: A quick look at build.sh shows that one of the first things that needs to be done is to map the MACHINE name to the CPU architecture name, i.e. MACHINE_ARCH. I noticed that some ports set MACHINE=MACHINE_ARCH, but some others don't. Which leads me to the following: what are the guidelines for choosing these names? If reasonably possible, use MACHINE=MACHINE_ARCH=whatever config.guess uses for the platform. A lot of the different MACHINE values are due to historical reasons annd wouldn't happen again. I think keeping evb* for boards makes sense, though. I agree. MACHINE=evbavr32 and MACHINE_ARCH=avr32 make the most sense.
