Date: Tue, 15 Apr 2003 12:15:35 -0500 From: Juli Mallett <jmallett@FreeBSD.org> To: Robert Drehmel <robert@zoot.drehmel.com> Cc: mips@FreeBSD.org Subject: Re: PERFORCE change 28827 for review Message-ID: <20030415121535.A73039@FreeBSD.org> In-Reply-To: <20030415091420.GB39845@bsd.develop.ferrari.local>; from robert@zoot.drehmel.com on Tue, Apr 15, 2003 at 11:14:20AM %2B0200 References: <20030415091420.GB39845@bsd.develop.ferrari.local>
next in thread | previous in thread | raw e-mail | index | archive | help
* De: Robert Drehmel <robert@zoot.drehmel.com> [ Data: 2003-04-15 ] [ Subjecte: Re: PERFORCE change 28827 for review ] > > $PLATFORM is best spelled $MACHINE or $TARGET_MACHINE depending on > > the context (in this one it's $MACHINE), wouldn't you say? > > I just took the next best name grep revealed to me > (from sys/conf/Makefile.mips); you are right, I will > change the name of the variable to MACHINE. Yeah, that example is a bad one, as the methodology with which one gets MACHINE & MACHINE_ARCH in that part of the build was a bit different. When I saw your change I eventually figured this was the reason why, and it took even longer to remember why it was needed there at all. > At this stage, I just want to get it working. Obviously! > I think the two > ARC libraries (in sys/dev and sys/boot) we currently have should > be merged later, at least the ARC data structure definitions > which currently reside in dev/arcbios/arcbios.h and > boot/arc/include/arc(types|funcs).h. Aye. Splitting out the codebase-independent bits into _subr files and trying to share those or something would probably work. I do definitely agree with you on that. > (They need to be changed anyway - some of the structures have a > wrong layout for the SGI Octane I am testing on, and that requires > tedious trail-and-error sequences. I did not find any documentation > about the specialties of the SGI ARC.) Did you look at the dev/arcbios sgimips checks? Or you mean that the Octane has things different even from other SGIs? > My plan was to start using (and modifying) the structures and > constants imported from NetBSD, in new ARC code, mainly to enable > code-sharing. This is ugly as long as the `other' headers > (the original boot/arc/include files) are used in the same library, > but should turn out to be cleaner after every piece of ARC code > uses dev/arcbios/arcbios.h. Of couse, this is only theoretical > and I need to ask the alpha people for their opinion first. > > What do you think? I think nobody uses the ARC loader for Alpha, and it was uncompleted. Anyone that needs it is dead in the water, anyway, even if the loader did work, as the kernel's arcbios support was added in the mips branch, and wasn't part of the earlier ARC effort. I had had an ARC Alpha on the wantlist so I could approach this, at one point. I think it'd be worthwhile to try to get/keep Alpha people involved (if anyone cares, apparently the only ARC alphas aren't really FreeBSD-quality), but I think it would be more worthwhile still to have something up and running. It's not like this is in CVS right now anyway, so "make it work now" is good. If Alpha people really want it, they can always try trial-and-error themselves, if something that changes doesn't work. > Let me reply to your other mail because of the knotted topics: > > > Unfortunately, 'sgimips' is not fine-grained enough here. Need to > > have a tunable to build it for other SGI machines, where that > > location may not be right at all. Do you have any particular > > stylistic feelings on how to do that? > > I guess we should stay compatible with NetBSD. If they are not > distinguishing SGI machines on that level, we could use 'sgimips' > and e.g. 'sgimips_ip32' for more granularity (or just 'ip32'?). They only make a very simple distinction between things, that is to say the kernel hack to change the .text address wrt IP22 or IP32. As far as I know, anyway. I think maybe just a make.conf tunable or such would work here. WANT_SGI_IP32, or \&_ARCBIOS maybe. I don't know quite what you'd want to call things or how, I suppose worst-case, if everything is the same except the addr, and we can't just have the code probe (arcbios_init(addr1), if (ARCBIOS->Running != TRUE) arcbios_init(addr2) or such, maybe) then worst case you could always just make *that* the tunable. Thanx! juli. -- juli mallett. email: jmallett@freebsd.org; aim: bsdflata; efnet: juli;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030415121535.A73039>