On Wed, 2003-01-29 at 16:18, Marcel Moolenaar wrote:
> On Tue, Jan 28, 2003 at 08:57:38PM -0800, Juli Mallett wrote:
> >
> > Yes, you are following me. But also, you mention that "machine"
> > as implemented means what I said it means, but there is other
> > precident for using it as I say. For example, BSD/OS uses
> > "machine sparc" and "options SUN4M". NetBSD uses machine in a
> > way more similar to what you want, but like "machine sgimips mips"
> > for example. What we want... Could be done with machine, if we
> > allow there to be no files.XXX for a given "machine XXX" and so
> > on, but I think this is less clear. How would you propose to write
> > the following:
> >
> > %%%
> > machine mips
> > platform sgimips
> > %%%
> >
> > Would you write it as:
> >
> > %%%
> > machine mips sgimips
> > %%%
>
> No, I see MACHINE_ARCH implied by where you run config. This seems
> strange and I'm not completely sure it's a good thing, but
> MACHINE_ARCH is defined in /sys/${ARCH}/include/param.h and
> defining the architecture in the kernel config file only allows
> a limited freedom; namely the freedom to have the config file
> outside the source tree. It basicly only defines a directory,
> nothing else. See also below for pc98.
>
> Thus, MACHINE_ARCH is not specified and "machine" holds the
> implementation (ie platform). This is exactly what we have
> now, so you don't change the meaning.This is just confusing. Having just played with this, if I specify machine i386 while in the sys/powerpc/conf directory, I end up with an unbuildable configuration as it sucks in the i386 Makefile but assumes that it's arch-specific files are in ../../include. This means that we would need to use: machine powermac in the config file while being in the powerpc directory, and then have a sys/conf/*.powermac (along with all the other ones). This to me is backwards. If we follow Juli's suggestion, we have: machine powerpc platform powermac and this uses the standard sys/conf/*.powerpc and simply pick up a set of platform-dependant includes from sys/powerpc/powermac. The options logic handles the rest as we already have lines in sys/conf/files.powerpc like: powerpc/powermac/uninorth.c optional powermac pci powerpc/powermac/macio.c optional powermac pci powerpc/powermac/ata_macio.c optional powermac ata Then when we head off to implement a little-endian powerpc platform we can use: machine powerpc platform little-endian-platform and it'll grab it's includes out of sys/powerpc/little-endian-platform and we can do the same sort of files.powerpc magic as above. Juli's form is also more explicit, which I find appealing. > > There's more at stake than just what we need, it also has to make > > sense when we don't need it, and so on. The above two things I > > have suggested break in dumb ways... If you just figure out the > > MACHINE_ARCH based on /sys/XXX/conf's XXX bit, then you could > > define MACHINE based on the machine directive, and as such, on > > i386 and sparc64 and ... it would do the right thing, and it > > would allow the MIPS stuff to be done, but it breaks the existing > > pc98 stuff, because it resides in /sys/$MACHINE. > > Correct. I either want pc98 transformed or if that's not possible > or feasible, a keyword "root", "tree", "directory" or " > "nonstandardlocation" to tell config(8) that the (sub-)port is > not where we normally have it. We then create a new keyword, > but it explcitly means a location, a path. The introduction of > platform is more confusing. First of all it maps to MACHINE, > while we have the machine keyword mapping to something else. > This is illogical. The machine keyword basicly controls > source layout and has nothing to do with the machine you're > building for. Again, illogical. > > So, I'm not opposed to having a new variable if it's too hard to > do it without, but I think there's a more logical/optimal scheme > of naming and attaching meaning that does not affect the common > case (it only affects pc98). Juli's patches don't touch the common case. If you don't specify a platform then you don't get that extra logic. Easy. I agree that moving pc98 over to whatever system we want to use is a good idea, but for the moment I'd be happy with not forcing mips and powerpc down the same road as pc98 which I see as being overly painful and confusing. -- Benno Rice <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
