I went ahead and built under rh9. Will test today or tomorrow and upload if all goes well. However, I have several questions, and I really, really need an answer to the first question.
Q: In a past thread Brian said:
"Last night I discovered why I've been unable to boot and test on my uni-processor test machine for the past few weeks -- CONFIG_SMP=y got into the linux.i386.config somehow."
SMP is still turned on in the current 3.2.2 tarball's linux.i386.config. Should I turn it off?
Q: If the answer above is yes... Does that mean we need to go to 3.2.3?
Yes, I believe so. I'm looking into cutting a 3.2.3 release now.
Q: The current spec file has a bunch of 'migration' code in the pre/post scripts. I'd like to rip that out and put it into the documentation instead. The reason is that Fedora has a stated policy against RPMs that do terminal I/O. I'd like to conform to that. I'd also like to tweak it to respect any relocation information in systemimager.conf. Objections?
Dann?
Q: The current spec file builds a package named systemimager-i386boot-standard. The kernel in that package, however, is compiled for i486 (i586 in 3.2.0). We've had at least one bug report related to that. Should I tweak the spec file to change the name to reflect the kernel architecture rather than the build machine's architecture? I'm thinking we may need this RSN for native 64-bit support. Is that worthy of a minor revision increment?
Heh. Good point, Jerry. I don't think this has ever been brought up before. I believe we derived that 'keyword' from the architecture name that the kernel source uses to refer to intel 32bit architectures (i386), but it may be confusing, and may be appropriate to change it.
Dann, what ramifications do you see if we were to change this?
Q: Do we care about i386 any more?
Technically, no.
Q: Do we want to have more than one kernel arch boot image (e.g. 486,586,686)? This would probably require tweaks to the make rules.
No. The 486 kernel will work fine on any higher architecture, and for
the special purpose application we use it for, there's no significant downside either.
So it looks like our options are: a) keep it as i386boot, and explain in the description (rpm -qi) that the i386 refers to the kernel name for that architecture, as opposed to it's hardware optimization, and that it was built for 486 and higher level systems. b) change it to i486boot, and all the ripple effect in the code and path naming that that would imply. c) change it to ia32boot? still explain in description that it's for 486 and higher
I'm kinda leaning towards a).
-Brian
------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Sisuite-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
--
------------------------------------------------------
Brian Elliott Finley Argonne, MCS Division Mobile: 630.631.6621 Office: 630.252.4742
gpg --keyserver wwwkeys.pgp.net --recv-keys 10F8EE52
------------------------------------------------------
------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Sisuite-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
