On Mon, Aug 23, 1999 at 03:37:33PM +0200, Christian Meder wrote: > > This is completely untrue. In fact the slink sparc release was with a > > 2.2.1 kernel _because_ it was more stable than the 2.0.x kernels for this > > architecture. > > Sorry to say that your comment is only partially true ;-) > The 2.2.1 kernel was added to the slink sparc release for two reasons: > > * sun4u (Ultra) support was only usable with > 2.1.x kernels > * 2.0.35 had a slowdown kernel bug on some sparc cpu models which was > only fixed in 2.1.x kernels > > On my Sparcstation10 2.0.35 was a perfectly stable kernel. Steve Dunham > pushed 2.2.1 in to support the sun4u architecture and we weren't sure > if it would work out well on all sparc cpu's because it was still brand > new stuff when we released slink ;-)
Looks like stability reasons to me (atleast in the case of the sun4c slow down issue). Either way, even if 2.0.35 ok on your machine, it does not mean it's not more stable across _all_ sun platforms, which IMO, wins by default. > > In case you want to know, right now I plan on trying to push getting the > > 2.1.2 glibc into the sparc/slink re-release simply because the 2.1pre > > (2.0.105) is not as stable, and actually compiles binaries that aren't > > binary compatible with other sparc distributions. > > Could you elaborate in which areas 2.0.105 is unstable ? I'd be pretty > hesistant to upgrade glibc without some striking arguments (binary > compatibility with other distributions is a somewhat weak argument as > there's only RedHat in the sparc arena and RH5.2 was based on glibc2.0 > which is incompatible by design and RH6.0 is glibc2.1 which should be > mostly compatible to 2.0.105). Besides we need to test first if there's > a working upgrade path for 2.0.35 users when upgrading to glibc2.1.2. Last > time I checked a 2.2.x kernel was a prerequiste for upgrading glibc2.1 > which should be fixed (the upgrade should be possible with a 2.0.35 kernel). 2.0.105 is a pre-release, for the most part it's imcomplete in certain areas, and leaving our dist with it makes us one of those dists who release with alpha/beta software as "stable". Anything compiled with this version of libc wont run on RH's stock unpatched version of glibc 2.1 (not because of RH, but because of certain issues with egcs and chown() blah blah blah). Now the version we have in potato of libc and egcs (right now gcc2.95) will not only run our old binaries, and run RH's binaries, it also compiles binaries that run on the old slink system (99% atleast) but also run on RH's sparc glibc 2.1 too. This is a major thing. There are companies out there (I know from direct contact) that have held off using Debian as their sparc/linux development platform because of this incompatibility. I'm sure there are a lot of other non-commercial developers that are in the same boat. > Sparc needs an updated egcs and egcs64 package (important bug fixes, > miscompilation of 2.2.x kernels) and a > newer kernel (although 2.2.9 should be fine). Additionally I would like to > sync the source packages in the update, sparc has got a few .1 packages > which can't be build from the corresponding source packages without a > patch (the patches weren't included by the maintainers in time for the > release). The Xsun24 should be updated (Steve incorporated the relevant > patches in the potato package) because the Creator graphics board support > is sooooooooo slow in slink. > That's my wishlist ;-) egcs64 is up to date and compiles kernels fine. gcc 2.95.1pre is in the potato archive. As far as some of the .1 NMU packages, that will need to be scripted out. The wanna-build db reports a surprisingly syncronised dist on our part for slink with a few exceptions. Steve and Branden have been working together on the X and Creator support (Creator support _will_ require a fairly new 2.2 kernel according to Steve). As far as the support for 2.0.x support in glibc, that's what got us the problem with 2.0.105's binary incompatibility with stock libc's. Personally I would not run a 2.0 kernel on a sparc any more because of all the problems with libc/syscalls. Ben
