Date: Thu, 30 Jan 2003 13:31:38 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: jmallett@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Patch to teach config(8) about "platforms". Message-ID: <20030130213138.GA44153@dhcp01.pn.xcllnt.net> In-Reply-To: <20030130.100957.06950735.imp@bsdimp.com> References: <20030128235528.GA844@athlon.pn.xcllnt.net> <20030128160936.A4252@FreeBSD.org> <20030129004006.GA945@athlon.pn.xcllnt.net> <20030130.100957.06950735.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 30, 2003 at 10:09:57AM -0700, M. Warner Losh wrote: > In message: <20030129004006.GA945@athlon.pn.xcllnt.net> > Marcel Moolenaar <marcel@xcllnt.net> writes: > : general theme. Thus (in this case), ARCH=mips and MACH=algor or > : MACH=sgimips... > > Actually, NetBSD uses MACHINE_ARCH=mipsel for little endian machines > and MACHINE_ARCH=mips for big endian machines. However, it has a > common set of mips include files/code, etc in src/sys/arch/mips > Forcing MACHINE_ARCH to be mips in both proved too problematic. Yes. I mentioned this to Juli and specifically asked if she was not going to do that. I can't recall an explicit answer. I think it was implied in the discussion at that time that it was not an option. From your other reply: > Keep in mind that for mips you have two different architectures: > mipsel and mips(eb). I keep harping on this because you cannot run > mipsel binaries on mipseb kernels (please ignore that some mips cpu > can, in theory do this, since no free OS has climbed that mountain). > You'll need different binaries (packages) for mips and mipsel. Good point. The toolchain configuration is related to this. We now select on MACHINE_ARCH, which would not capture the endianness if it was encoded in MACHINE. Granted, we could include MACHINE in the selection of the BFD and code generator files, but the patch did not include that. I still don't reject MIPS as the architecture and have the variants as sub-concepts, but we do need to discuss in that case how it's going to work. The packaging automaticly adds to the dimension of the problem. If variants have the same endianness and share a common runtime, you would like to be able to share packages between the variants. But if the endianness differs or the runtime is different, this cannot happen. If in both cases we talk about platform then I think our abstraction is inadequate. Given that NetBSD is known to be able to run on your toaster (it would on mine if I had one :-), it would be a mistake to reject their mechanism without fully understanding what it is we're rejecting. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030130213138.GA44153>