Date: Tue, 28 Jan 2003 12:08:30 -0800 From: Juli Mallett <jmallett@FreeBSD.org> To: Takahashi Yoshihiro <nyan@jp.FreeBSD.org> Cc: obrien@FreeBSD.ORG, current@FreeBSD.ORG, peter@FreeBSD.ORG, ru@FreeBSD.ORG Subject: Re: Patch to teach config(8) about "platforms". Message-ID: <20030128120830.A81856@FreeBSD.org> In-Reply-To: <20030128.233856.71130419.nyan@jp.FreeBSD.org>; from nyan@jp.FreeBSD.org on Tue, Jan 28, 2003 at 11:38:56PM %2B0900 References: <20030125153116.A25743@FreeBSD.org> <20030128.233856.71130419.nyan@jp.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* De: Takahashi Yoshihiro <nyan@jp.FreeBSD.org> [ Data: 2003-01-28 ]
[ Subjecte: Re: Patch to teach config(8) about "platforms". ]
> In article <20030125153116.A25743@FreeBSD.org>
> Juli Mallett <jmallett@FreeBSD.ORG> writes:
>
> > For example "platform sgimips" implies
> > "options SGIMIPS". Below are patches to makefile glue and config(8)
> > itself.
>
> I think that using '#ifdef <machine>' (like #ifdef PC98) is not a good
> idea. If it requires, the file should be splited into sys/<machine>.
> I'll split some files in sys/i386 into sys/pc98.
>
>
> > For clarity, this is used in cases where the platform may define its
> > own values that a header needs, and as such, you might see something
> > in <machine/endian.h> like:
> > #include <platform/endian.h>
>
> How about next way?
>
> - Install sys/${MACHINE}/include into /usr/include/${MACHINE}
> - Symlink /usr/include/machine -> /usr/include/${MACHINE}
> - If ${MACHINE} != ${MACHINE_ARCH},
> install sys/${MACHINE_ARCH}/include into /usr/include/${MACHINE_ARCH}
>
> For example, sys/pc98/include/endian.h is '#include <i386/endian.h>'
> only.
This approach is a really bad one architecturally, in my opinion. It means
there is a lot of duplication of what may all be VERY similar, and it means
that if we had say 5 platforms supported by the MIPS port (certainly this is
not a high number at all) that means there would be 5 directories under
src/sys... And none of them would be "mips" since we wouldn't be supporting
any hardware called "mips", that's just the general architecture.
Or maybe we'd have "mips" and it would just be the first machine we ported
to, and so that would be even more confusing for people trying to do a clean
port to *just* support their architecture. They would have to know the other
hardware very well also, not just the MIPS stuff, so they would know what to
remove, what was something FreeBSD needed on MIPS, etc.
I just really would like things to be clean, and abstracted, and not waste
anyone's time. Why should we have to duplicate so much code?
Thanx,
juli.
--
Juli Mallett <jmallett@FreeBSD.org>
AIM: BSDFlata -- IRC: juli on EFnet
OpenDarwin, Mono, FreeBSD Developer
ircd-hybrid Developer, EFnet addict
FreeBSD on MIPS-Anything on FreeBSD
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?20030128120830.A81856>