* De: Marcel Moolenaar <[EMAIL PROTECTED]> [ Data: 2003-01-28 ]
[ Subjecte: Re: Patch to teach config(8) about "platforms". ]
> On Tue, Jan 28, 2003 at 03:17:49PM -0800, Juli Mallett wrote:
> > * De: Marcel Moolenaar <[EMAIL PROTECTED]> [ Data: 2003-01-28 ]
> > [ Subjecte: Re: Patch to teach config(8) about "platforms". ]
> > > > 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?
> > >
> > > I'm not sure platform is the answer. We already have the distinction
> > > between MACHINE_ARCH and MACHINE and it looks to me that MACHINE can
> > > do what you try to achieve with platform. Why add a "platform"
> > > keyword to config(8) if we already have the "machine" keyword?
> >
> > Because that requires us to do what pc98 does, which is to have the
> > meta-port be the master port, and include up into the arch-port, and
> > that means that either you have every header in the arch-port be
> > wrapped by the meta-port, as <machine> is the meta-port, or you just
> > copy everything and make local changes.
>
> I'm sorry, you use implications I don't see to come to a conclusion
> I don't get:
>
> Start with the beginning: We have MACHINE_ARCH and MACHINE. Can you
> represent the problem you're seeing with MIPS with two entities,
> namely MACHINE_ARCH and MACHINE?
> If yes, how exactly do these entities need to be defined in that case
> and how do they relate to each other.
> If no, explain why you need more entities to capture the problem.
Sure, say we support sgimips and algor MACHINE's on the mips MACHINE_ARCH.
That's SGI workstations, which are big-endian and have ARCBIOS stuff,
and Algorithmics development boards, which support little-endian and
big-endian configurations. Obviously we have "machine mips", right? But
that determines what <machine> is a link to, and files.<machine> that is
read. So that means that we need to have <machine/*.h> stubbed in both
<algor/> and <sgimips/>. Each of those defines the things they need to
be defined, and then includes <mips/\&.h>. Even if we know that we never
need to have any changes, or otherwise have the abstraction the wrong way
around. It also means that you have to pull in the mips options and files
list for both of those ports, and so on. So you end up having "machine
$(MACHINE)" and having to explicitly inherit bit by bit everything that
you may need into the meta-port (algor or sgimips -- $(MACHINE)), in an
explicit manner.
My way, <machine> is "mips" and the headers which provide tunables include
<platform/\&.h>. Optional hardware for a given platform is pulled in via
files.mips optional directives. Everything is less convoluted, IMHO.
> No implementation details please.
I did my best, but I still have to show that there are two explicit
meta-ports. My previous email had no "implementation details", just
general structure, and you rejected it, so I hope this is better.
--
Juli Mallett <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
