* De: Marcel Moolenaar <[EMAIL PROTECTED]> [ Data: 2003-01-28 ]
[ Subjecte: Re: Patch to teach config(8) about "platforms". ]
> > 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.
>
> It's different :-)
>
> What I'm trying to get at is how sgimips is the same as algor and
> likewise how it is different, independent as to how this would
> be handled in our source tree.
> For example: if they both use the same processor and instruction
> set and have the same runtime specification, you can say that they
> are both MIPS. The endianness is just a slight variation of the
> general theme. Thus (in this case), ARCH=mips and MACH=algor or
> MACH=sgimips...
That's what I'm saying, yes.
> So, given that we have MACHINE_ARCH and MACHINE already to our
> disposal, I don't get the feeling that we are in need to add
> something else because the problem space appears 2D, not 3D.
>
> Right?
That's what I'm trying to do, in a clean way. See my "short version"
message, if you like.
--
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
