> >Even if the code was pulled early, there's no real reason to drop out >a workable release of code(t hat is, something that would build cleanly >for sun4m, not just raw code known not to work without u nobtainable >tools) for perfectly runnable machines. It'd not be much, but something >based off of bu ild 22(or whatever was the last working Solaris 10 >build for sun4m) combined with proper support of >sbus hardware previously dropped since Solaris 7 would be what some >people are asking to have put in. Nothing purposefully crippled, >nothing purposefully limited would be the intended goal of what would >be wanted for the "final release" (within version 10).
The issue isn't quite that simple; there were several reasons why sun4m support was removed. An important one being that we no longer had sufficient of them around of support and testing. S10 build 22 would not not be "S10" as we know and love it as Bryan pointed out (no dtrace, privileges, SMF, FMA, KCF, zones) and you must understand that old code rots. The lower levels of the kernel underwent substantial changes during S10 development; the sun4m s10_22 kernel modules would simply no longer work with the current Solaris kernel. (A lot of change goes in in 3 years) Then there's the additional effort of vetting the code, etc. Casper _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
