From sacadmin Thu Jan 9 09:58:43 2003 Date: Thu, 9 Jan 2003 09:58:43 -0800 (PST) From: Richard McDougall To: PSARC@sac.eng.sun.com Subject: FastTrack: PSARC 2003/014 EOL of 32-bit SPARC Kernels Content-Length: 4817 Subject: FastTrack: PSARC 2003/014 EOL of 32-bit SPARC Kernels [timeout 01/15/2003] Template Version: @(#)sac_nextcase 1.47 12/20/02 SMI 1. Introduction 1.1. Project/Component Working Name: EOL of 32-bit SPARC Kernels PSARC FastTrack, proposed timeout 01/15/2003 Case Number: PSARC/2003/014 1.2. Name of Document Author/Supplier: Author: russ blaine Sponsor: rmc 1.3 Date of This Document: 09 January, 2003 4. Technical Description See the case directory for more detail URL: http://sac.eng/arc/PSARC/2003/014 -------- FastTrack Proposal -------- 1. Introduction 1.1. Project/Component Working Name: EOL of 32-bit SPARC kernels (follow-on case) 1.2. Name of Document Author/Supplier: Russell Blaine 1.3. Date of This Document: 1/9/2003 1.4. Name of Major Document Customer(s)/Consumer(s): PSARC, SOESC, ONSC 1.5. Email Aliases: 1.5.1. Responsible Manager: kirk.wells@sun.com 1.5.2. Responsible Engineer: russell.blaine@sun.com 2. Project Summary 2.1. Project Description This proposal is to remove support for 32-bit SPARC kernels from Solaris 10. The advance warning of this EOL has already been delivered in an update of Solaris 9 (see [3]). This proposal is also to remove support for UltraSPARC-I processors. Advance warning of this EOL has already been delivered in an update of Solaris 9 (see [3]). The advance warning stated that UltraSPARC-I processors running at 200 MHz or slower may not be supported in a future release. Since there were no UltraSPARC-I processors sold! running at greater than 200 MHz, support for all UltraSPARC-I processors will be removed with no additional customer impact. 2.2. Risks and Assumptions See [1]. 3. Business Summary See [1]. 3.5. Opportunity Window/Exposure Solaris 10 3.6. How will you know when you are done? When the changes have been integrated into the ON gate, and all corresponding changes have been made to the Solaris installer and Solaris documentation. 4. Technical Description The following changes will be made: 1. Remove all 32-bit SPARC modules. Leave 64-bit modules where they are, except for the changes noted in this document. 64-bit modules will continue to be delivered in the "xxx/sparcv9" directories, so the kernel run time linker will not be modified. Some customers use the OBP variable "boot-file" to specify which file to boot their system with. Since /platform/sun4u/kernel/unix is a 32-bit binary and will no lon! ger be delivered, any customers with the "boot-file" OBP ! variable set to "kernel/unix" will get a "file not found" error at boot time. To mitigate this, the following will be done: o The Solaris 10 release notes will contain a section noting that the "kernel/unix" boot-file no longer exists and users should either clear that OBP variable to let Solaris choose the correct file, or set it to "kernel/sparcv9/unix" manually. The section should contain an example of the "file not found" error that users will encounter should they leave boot-file as "kernel/unix". This section should also note that the installer will give the user an option to do this automatically at install time. o The Solaris 10 installer will check the value of the OBP "boot-file" variable. If that variable contains "kernel/unix" and the machine is a SPARC machine, the installer will present the user with an option to change the variable to "kernel/sparcv9/unix". The def! ault for that installer page will be to make the change, and the page will contain a description of the change and an explanation of why it is necessary, including a reference to the appropriate section in the release notes. 2. Remove all 32-bit sparc-only packages. The only exception to this is SUNWcar.u, upon which too many things depend. Where appropriate, driver conf files and install scripts will be moved into the corresponding 64-bit sparc package. The following packages will be removed: SUNWcpc.u SUNWcpr.u SUNWcg6.u SUNWcvc.u SUNWdfb.u SUNWdrr.u SUNWfctl SUNWfcip SUNWfcp SUNWhmd SUNWidn.u SUNWifp SUNWk5ok.u SUNWluxd.u SUNWluxl SUNWpd SUNWqlc SUNWses SUNWssad SUNWusoc SUNWuxfl1.u 3. EOL support of all UltraSPARC-I CPUs. If the secondary boot loaders detect an UltraSPARC-I processor, a polite message will be printed for the user and the kerne 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack timeout 01/15/2003 From sacadmin Thu Jan 9 10:06:17 2003 Date: Thu, 09 Jan 2003 10:07:01 -0800 From: Richard McDougall User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@sac.eng.sun.com CC: rab@eng.sun.com Subject: 2003/014: EOL of 32-bit SPARC Kernels Content-Type: multipart/mixed; boundary="------------070709030907000701000604" Content-Length: 8194 This is a multi-part message in MIME format. --------------070709030907000701000604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This fast track is to remove support for 32-bit SPARC kernels from Solaris 10. The advance warning of this EOL has already been delivered in an update of Solaris 9 (2002/255). This proposal is also to remove support for UltraSPARC-I processors. Advance warning of this EOL has already been delivered in an update of Solaris 9. The project seeks approval to deliver into a minor release. Please comment by 1/15. Thanks, Richard. --------------070709030907000701000604 Content-Type: text/plain; x-mac-type="54455854"; x-mac-creator="74747874"; name="onepager.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="onepager.txt" 1. Introduction 1.1. Project/Component Working Name: EOL of 32-bit SPARC kernels (follow-on case) 1.2. Name of Document Author/Supplier: Russell Blaine 1.3. Date of This Document: 1/9/2003 1.4. Name of Major Document Customer(s)/Consumer(s): PSARC, SOESC, ONSC 1.5. Email Aliases: 1.5.1. Responsible Manager: kirk.wells@sun.com 1.5.2. Responsible Engineer: russell.blaine@sun.com 2. Project Summary 2.1. Project Description This proposal is to remove support for 32-bit SPARC kernels from Solaris 10. The advance warning of this EOL has already been delivered in an update of Solaris 9 (see [3]). This proposal is also to remove support for UltraSPARC-I processors. Advance warning of this EOL has already been delivered in an update of Solaris 9 (see [3]). The advance warning stated that UltraSPARC-I processors running at 200 MHz or slower may not be supported in a future release. Since there were no UltraSPARC-I processors sold running at greater than 200 MHz, support for all UltraSPARC-I processors will be removed with no additional customer impact. 2.2. Risks and Assumptions See [1]. 3. Business Summary See [1]. 3.5. Opportunity Window/Exposure Solaris 10 3.6. How will you know when you are done? When the changes have been integrated into the ON gate, and all corresponding changes have been made to the Solaris installer and Solaris documentation. 4. Technical Description The following changes will be made: 1. Remove all 32-bit SPARC modules. Leave 64-bit modules where they are, except for the changes noted in this document. 64-bit modules will continue to be delivered in the "xxx/sparcv9" directories, so the kernel run time linker will not be modified. Some customers use the OBP variable "boot-file" to specify which file to boot their system with. Since /platform/sun4u/kernel/unix is a 32-bit binary and will no longer be delivered, any customers with the "boot-file" OBP variable set to "kernel/unix" will get a "file not found" error at boot time. To mitigate this, the following will be done: o The Solaris 10 release notes will contain a section noting that the "kernel/unix" boot-file no longer exists and users should either clear that OBP variable to let Solaris choose the correct file, or set it to "kernel/sparcv9/unix" manually. The section should contain an example of the "file not found" error that users will encounter should they leave boot-file as "kernel/unix". This section should also note that the installer will give the user an option to do this automatically at install time. o The Solaris 10 installer will check the value of the OBP "boot-file" variable. If that variable contains "kernel/unix" and the machine is a SPARC machine, the installer will present the user with an option to change the variable to "kernel/sparcv9/unix". The default for that installer page will be to make the change, and the page will contain a description of the change and an explanation of why it is necessary, including a reference to the appropriate section in the release notes. 2. Remove all 32-bit sparc-only packages. The only exception to this is SUNWcar.u, upon which too many things depend. Where appropriate, driver conf files and install scripts will be moved into the corresponding 64-bit sparc package. The following packages will be removed: SUNWcpc.u SUNWcpr.u SUNWcg6.u SUNWcvc.u SUNWdfb.u SUNWdrr.u SUNWfctl SUNWfcip SUNWfcp SUNWhmd SUNWidn.u SUNWifp SUNWk5ok.u SUNWluxd.u SUNWluxl SUNWpd SUNWqlc SUNWses SUNWssad SUNWusoc SUNWuxfl1.u 3. EOL support of all UltraSPARC-I CPUs. If the secondary boot loaders detect an UltraSPARC-I processor, a polite message will be printed for the user and the kernel will not be loaded. To the user, this will appear as such: ok boot Resetting ... Sun Ultra 1 SBus (UltraSPARC 143MHz), No Keyboard OpenBoot 3.11, 64 MB memory installed, Serial #8767953. Ethernet address 8:0:20:85:c9:d1, Host ID: 8085c9d1. Rebooting with command: boot Boot device: /sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@0,0:a File and args: This CPU is not supported by this release of Solaris. Program terminated ok 4. Remove the boot.conf boot policy file from Solaris, including all code which deals with the boot policy (see [4]). 5. Support for the SUNW,Ultra-1 platform will no longer be delivered, as that platform only uses UltraSPARC-I CPUs. SUNW,Ultra-2 will become the reference implemented desktop platform to which the other desktop platforms (i.e. Ultra-30, Ultra-60) link to in /usr/platform. 6. Currently, if Solaris detects downrev firmware running on a machine at boot time, a warning is printed and the 32-bit OS is booted (see [4]). Since the 32-bit OS will no longer be delivered, if Solaris detects downrev firmware, a polite message will be printed which instructs the user to upgrade the firmware and the kernel will not be loaded. This proposal does not seek to alter the arrangement of binaries in isa-specific directories linked to isaexec. The current system is well-known by our customers and developers and there is no need to change it at the present time. Furthermore, the isaexec scheme will remain necessary going forward as long as the possibility of supporting dual-boot systems exists (e.g. x86-64). If Solaris 10 is installed via upgrade onto a supported machine which previously did not have 64-bit packages, the installer will silently install all necessary 64-bit packages. The installer will no longer ask the user if 64-bit support should be included. The Solaris 10 release notes will have a section describing this EOL. 5. Reference Documents [1] PSARC 2002/255 delivered the advance notice. [2] PSARC 2002/013 removed sun4m architecture support from Solaris 10. [3] The End-of-Support section of the Solaris 9 9/02 Release Notes includes 32-bit kernels as well as UltraSPARC-I processors as Future End-of-Support Products. [4] boot(1M) man page 6. Resources and Schedule 6.1. Projected Availability Q3 FY03 6.2. Cost of Effort 1 development engineer 3 months 1 install engineer 1 month 1 test engineer 1 month 6.3. Cost of Capital Resources Existing. 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON C-Team 6.4.2. Contributing OpCo/BU/Division Name: SKT 6.4.3. Type of SC Approval needed: Fasttrack 6.4.5. Is this a necessary project for OEM agreements: N 6.4.6. Notes/Dependencies: None. 6.4.7. Target RTI Date/Release: S10 Alpha 6.4.8. Target Code Design Review Date February 1, 2002 6.4.9. Did this project have prior SOESC approval for a Marketing Release and now your requesting to go into an Update Release or Early Access CD? No. 6.5. ARC review type: Fasttrack 7. Prototype Availability 7.1. Prototype Availability Prototype available first week of February 2003. 7.2. Prototype Cost 1 development engineer 2 months. --------------070709030907000701000604-- From sacadmin Thu Jan 9 11:15:37 2003 Date: Thu, 09 Jan 2003 11:14:15 -0800 From: Jordan Brown X-Accept-Language: fr, en MIME-Version: 1.0 To: Richard McDougall CC: psarc@sac.eng.sun.com, rab@eng.sun.com Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 339 As I understand the proposal, after this change all kernel modules will be in directories named "sparcv9" and all kernel package names will end in "x". (Well, maybe not *all*.) Would it perhaps result in a simpler system if the 64-bit stuff all got moved into the "base" directories and "base" package names, replacing the 32-bit stuff? From sacadmin Thu Jan 9 11:59:11 2003 From: Bill Sommerfeld To: Richard McDougall cc: psarc@sac.eng.sun.com, rab@eng.sun.com Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels Date: Thu, 09 Jan 2003 14:58:37 -0500 Content-Length: 841 > Some customers use the OBP variable "boot-file" to specify which > file to boot their system with. Since > /platform/sun4u/kernel/unix is a 32-bit binary and will no > longer be delivered, any customers with the "boot-file" OBP > variable set to "kernel/unix" will get a "file not found" error > at boot time. I vaguely recall seeing mention (in the ON EOL flag day email) that we did something a little different with the sun4d and sun4m EOL -- we now deliver bootblocks which print a "sorry no longer supported"-type message. Could we arrange to set things up so that people who try to boot the old 32-bit kernel now get a similar message -- along the lines of "sorry, no more 32-bit kernel; switch to the 64-bit version instead" -- instead of a much more generic "file not found" ? - Bill From sacadmin Thu Jan 9 12:00:46 2003 Date: Thu, 9 Jan 2003 12:00:14 -0800 (PST) From: Tim Marsland To: Richard.McDougall@sun.com, Jordan.Brown@sun.com Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels Cc: psarc@sac.eng.sun.com, rab@eng.sun.com Content-Length: 672 | From psarc-member-list-request@sun.com Thu Jan 9 11:14 PST 2003 | | As I understand the proposal, after this change all kernel modules will | be in directories named "sparcv9" and all kernel package names will end | in "x". (Well, maybe not *all*.) | | Would it perhaps result in a simpler system if the 64-bit stuff all got | moved into the "base" directories and "base" package names, replacing | the 32-bit stuff? Perhaps, but as long as there remains a possibility of creating an x86-64-based Solaris system -- which would have the same packaging issues as we did for S7 for SPARC i.e. foo plus foox packages -- I'd think we should just leave this alone. tim From sacadmin Thu Jan 9 16:15:26 2003 Date: Thu, 9 Jan 2003 16:14:53 -0800 From: Russ Blaine To: Bill Sommerfeld Cc: Richard McDougall , psarc@sac.eng.sun.com Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Content-Length: 1662 On Thu, Jan 09, 2003 at 02:58:37PM -0500, Bill Sommerfeld wrote: > > Some customers use the OBP variable "boot-file" to specify which > > file to boot their system with. Since > > /platform/sun4u/kernel/unix is a 32-bit binary and will no > > longer be delivered, any customers with the "boot-file" OBP > > variable set to "kernel/unix" will get a "file not found" error > > at boot time. > > I vaguely recall seeing mention (in the ON EOL flag day email) that we > did something a little different with the sun4d and sun4m EOL -- we > now deliver bootblocks which print a "sorry no longer supported"-type > message. Yes, I believe this is true - we deliver sun4d and sun4m bootblocks in /platform/sun4{d,m} which print a message and then exit. This case is slightly different, because we still want a fully-functioning sun4u boot block to boot the 64-bit kernel. > Could we arrange to set things up so that people who try to boot the > old 32-bit kernel now get a similar message -- along the lines of > "sorry, no more 32-bit kernel; switch to the 64-bit version instead" > -- instead of a much more generic "file not found" ? The difficulty becomes determining whether the user is indeed trying to boot a 32-bit kernel. Looking for "kernel/unix" as the boot file would work, but what about kernel.xxx/unix? What if (for whatever reason) someone tries to boot a 64-bit kernel located at "kernel/unix" ? Of course, checking for the string "kernel/unix" and issuing a warning if it matches would cover most users. - Russ ---------------------------------------------- Russ Blaine | Solaris Kernel | rab@eng.sun.com From sacadmin Thu Jan 9 16:24:56 2003 From: Bill Sommerfeld To: Russ Blaine cc: Bill Sommerfeld , Richard McDougall , psarc@sac.eng.sun.com Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels Date: Thu, 09 Jan 2003 19:24:21 -0500 Content-Length: 597 > The difficulty becomes determining whether the user is indeed trying > to boot a 32-bit kernel. Looking for "kernel/unix" as the boot file > would work, but what about kernel.xxx/unix? What if (for whatever > reason) someone tries to boot a 64-bit kernel located at > "kernel/unix" ? > > Of course, checking for the string "kernel/unix" and issuing a > warning if it matches would cover most users. if the end user has renamed the kernel they better know what they're doing -- but how about delivering a placebo "kernel/unix" which prints the message and dumps you back to OBP? - Bill From sacadmin Thu Jan 9 16:31:43 2003 Date: Fri, 10 Jan 2003 00:28:22 +0000 (GMT) From: Andrew Gabriel Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels To: Richard.McDougall@Sun.COM, psarc@sac.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JPbZrEZeXIYKygpZOAKlAw== Content-Length: 403 >> Of course, checking for the string "kernel/unix" and issuing a >> warning if it matches would cover most users. > >if the end user has renamed the kernel they better know what they're >doing -- but how about delivering a placebo "kernel/unix" which >prints the message and dumps you back to OBP? ... or transfers control to the 64 bit kernel after printing the warning message. -- Andrew Gabriel From sacadmin Thu Jan 9 16:38:48 2003 Date: Thu, 9 Jan 2003 16:38:13 -0800 (PST) From: Tim Marsland To: Richard.McDougall@sun.com, psarc@sac.eng.sun.com, andrew.gabriel@sun.com Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels Content-Length: 609 | From psarc-member-list-request@sun.com Thu Jan 9 16:30 PST 2003 | | >> Of course, checking for the string "kernel/unix" and issuing a | >> warning if it matches would cover most users. | > | >if the end user has renamed the kernel they better know what they're | >doing -- but how about delivering a placebo "kernel/unix" which | >prints the message and dumps you back to OBP? | | ... or transfers control to the 64 bit kernel after printing the | warning message. Or even just make kernel/unix be a symlink to kernel/sparcv9/unix .. (It's a lot simpler to understand than a whizzy new binary ;-) tim From sacadmin Thu Jan 9 17:00:13 2003 Date: Thu, 9 Jan 2003 16:59:40 -0800 From: Russ Blaine To: Bill Sommerfeld Cc: Richard McDougall , psarc@sac.eng.sun.com, Tim Marsland Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Content-Length: 514 On Thu, Jan 09, 2003 at 07:24:21PM -0500, Bill Sommerfeld wrote: > if the end user has renamed the kernel they better know what they're > doing -- but how about delivering a placebo "kernel/unix" which > prints the message and dumps you back to OBP? Tim Marsland had the idea of making kernel/unix a symlink to kernel/sparcv9/unix. Assuming that the relevant code can parse symlinks, would that be acceptable? - Russ ---------------------------------------------- Russ Blaine | Solaris Kernel | rab@eng.sun.com From sacadmin Thu Jan 9 17:20:06 2003 Date: Thu, 09 Jan 2003 17:19:25 -0800 From: Keith Holder User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ Blaine CC: Bill Sommerfeld , Richard McDougall , psarc@sac.eng.sun.com, Tim Marsland Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 928 Russ Blaine wrote: >On Thu, Jan 09, 2003 at 07:24:21PM -0500, Bill Sommerfeld wrote: > > >>if the end user has renamed the kernel they better know what they're >>doing -- but how about delivering a placebo "kernel/unix" which >>prints the message and dumps you back to OBP? >> >> > >Tim Marsland had the idea of making kernel/unix a symlink to >kernel/sparcv9/unix. Assuming that the relevant code can parse symlinks, would >that be acceptable? > > That will just load the 64 bit kernel module. You are not then aware that the user tried to boot a 32 bit kernel. It would then proceed to load other 32 bit modules and I don't think Solaris supports mixing 32 & 64 bit kernel modules. You could repeat what the UltraSPARC-IIe platforms do. When the 32 bit 'cpu' module is loaded, a message is displayed from spitfire.c::cpu_setup() that states 32-bit kernels are not supported, and then calls halt(). keith. From sacadmin Thu Jan 9 17:42:42 2003 Date: Fri, 10 Jan 2003 01:39:22 +0000 (GMT) From: Andrew Gabriel Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels To: keith.holder@Sun.COM Cc: Richard.McDougall@Sun.COM, psarc@sac.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zKm4e8rRjfVgrYYbeFmRJg== Content-Length: 2041 Keith Holder wrote: >Russ Blaine wrote: >>Tim Marsland had the idea of making kernel/unix a symlink to >>kernel/sparcv9/unix. Assuming that the relevant code can parse symlinks, would >>that be acceptable? >> >That will just load the 64 bit kernel module. You are not then aware >that the user >tried to boot a 32 bit kernel. It would then proceed to load other 32 >bit modules >and I don't think Solaris supports mixing 32 & 64 bit kernel modules. I just tried it on an Ultra 5, and it seems to boot OK without trying to load any 32 bit modules... # ls -l /platform/sun4u/kernel total 6962 drwxr-xr-x 3 root sys 512 Jan 7 01:47 cpu drwxr-xr-x 3 root sys 512 Jan 7 01:42 dacf drwxr-xr-x 3 root sys 1024 Jan 9 19:07 drv -rwxr-xr-x 1 root sys 2576140 Jan 7 01:43 genunix drwxr-xr-x 4 root sys 512 Jan 7 01:43 misc drwxr-xr-x 2 root sys 512 Jan 7 01:44 sparcv9 drwxr-xr-x 3 root sys 512 Jan 7 01:42 strmod drwxr-xr-x 3 root sys 512 Jan 7 01:38 sys drwxr-xr-x 3 root sys 512 Jan 7 01:40 tod lrwxrwxrwx 1 root other 14 Jan 10 01:28 unix -> ./sparcv9/unix -rwxr-xr-x 1 root sys 955608 Jan 7 01:31 unix.orig # ok boot kernel/unix Resetting ... Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz), No Keyboard OpenBoot 3.11, 256 MB memory installed, Serial #9482791. Ethernet address 8:0:20:90:b2:27, Host ID: 8090b227. Rebooting with command: boot kernel/unix Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0:a File and args: kernel/unix SunOS Release 5.10 Version v4u-420rb:kevlar-gate:01/07/2003 64-bit Copyright 1983-2002 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. DEBUG enabled misc/forthdebug (374685 bytes) loaded configuring IPv4 interfaces: hme0. Hostname: v4u-5a [snip] # isainfo -k sparcv9 # I don't have a spare Ultra 1 to see if that behaves the same way. -- Andrew Gabriel From sacadmin Thu Jan 9 18:13:37 2003 From: Bill Sommerfeld To: Russ Blaine cc: Bill Sommerfeld , Richard McDougall , psarc@sac.eng.sun.com, Tim Marsland Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels Date: Thu, 09 Jan 2003 21:13:02 -0500 Content-Length: 254 > Tim Marsland had the idea of making kernel/unix a symlink to > kernel/sparcv9/unix. Assuming that the relevant code can parse > symlinks, would that be acceptable? That's fine with me, as would any similar approach with the same result.. - Bill From sacadmin Fri Jan 10 15:39:00 2003 Date: Fri, 10 Jan 2003 15:38:25 -0800 (PST) From: Tim Marsland To: keith.holder@sun.com, andrew.gabriel@sun.com Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels Cc: Richard.McDougall@sun.com, psarc@sac.eng.sun.com Content-Length: 363 | I just tried it on an Ultra 5, and it seems to boot OK without | trying to load any 32 bit modules... and even if it didn't, we could obviously fix it, because the kernel no longer has to deal with figuring out which kind of kernel modules to load -- they all have to be ELF64 modules, they all live in a fixed namespace i.e. /sparcv9/modulename tim From sacadmin Mon Jan 13 13:33:57 2003 Date: Mon, 13 Jan 2003 13:33:24 -0800 From: Russ Blaine To: Keith Holder Cc: Bill Sommerfeld , Richard McDougall , psarc@sac.eng.sun.com, Tim Marsland Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Content-Length: 1300 On Thu, Jan 09, 2003 at 05:19:25PM -0800, Keith Holder wrote: > >Tim Marsland had the idea of making kernel/unix a symlink to > >kernel/sparcv9/unix. Assuming that the relevant code can parse symlinks, > >would > >that be acceptable? > > > > > That will just load the 64 bit kernel module. You are not then aware > that the user > tried to boot a 32 bit kernel. It would then proceed to load other 32 > bit modules > and I don't think Solaris supports mixing 32 & 64 bit kernel modules. > You could repeat what the UltraSPARC-IIe platforms do. When the 32 bit 'cpu' > module is loaded, a message is displayed from spitfire.c::cpu_setup() that > states 32-bit kernels are not supported, and then calls halt(). Actually, making kernel/unix a symlink to kernel/sparcv9/unix will solve this problem neatly. The 64-bit kernel is booted, and everything just works. The 64-bit kernel knows to look in the sparcv9 directories regardless of where its unix file was loaded from. Therefore the installer won't need to be futzed with at all; a machine with "boot-file" set to "kernel/unix" will just work without modification. We can note in the release notes that users should clear the OBP variable. - Russ ---------------------------------------------- Russ Blaine | Solaris Kernel | rab@eng.sun.com From sacadmin Wed Jan 15 10:20:42 2003 Date: Wed, 15 Jan 2003 10:21:21 -0800 From: Richard McDougall User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rab@phys-ha1mpka.eng.sun.com, tpm@eng.sun.com CC: psarc-record@sac.eng.sun.com Subject: 2003/014 was approved today Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 228 The case was approved today, pending an updated spec that captures the final implementation. Could you please send an updated one-pager showing the implementation that was discussed in the various emails? Thanks, Richard. From sacadmin Wed Jan 15 13:19:51 2003 Date: Wed, 15 Jan 2003 13:19:16 -0800 From: Russ Blaine To: Richard McDougall Cc: tpm@eng.sun.com, psarc-record@sac.eng.sun.com Subject: Re: 2003/014 was approved today Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Content-Length: 6912 On Wed, Jan 15, 2003 at 10:21:21AM -0800, Richard McDougall wrote: > > The case was approved today, pending an updated spec that captures the > final implementation. Could you please send an updated one-pager showing > the implementation that was discussed in the various emails? Here is the updated spec. The only change from the submitted spec is concerning the OBP boot-file variable problem, the solution to which was to symlink kernel/unix to kernel/sparcv9/unix and document that link in the release notes. 1. Introduction 1.1. Project/Component Working Name: EOL of 32-bit SPARC kernels (follow-on case) 1.2. Name of Document Author/Supplier: Russell Blaine 1.3. Date of This Document: 1/15/2003 1.4. Name of Major Document Customer(s)/Consumer(s): PSARC, SOESC, ONSC 1.5. Email Aliases: 1.5.1. Responsible Manager: kirk.wells@sun.com 1.5.2. Responsible Engineer: russell.blaine@sun.com 2. Project Summary 2.1. Project Description This proposal is to remove support for 32-bit SPARC kernels from Solaris 10. The advance warning of this EOL has already been delivered in an update of Solaris 9 (see [3]). This proposal is also to remove support for UltraSPARC-I processors. Advance warning of this EOL has already been delivered in an update of Solaris 9 (see [3]). The advance warning stated that UltraSPARC-I processors running at 200 MHz or slower may not be supported in a future release. Since there were no UltraSPARC-I processors sold running at greater than 200 MHz, support for all UltraSPARC-I processors will be removed with no additional customer impact. 2.2. Risks and Assumptions See [1]. 3. Business Summary See [1]. 3.5. Opportunity Window/Exposure Solaris 10 3.6. How will you know when you are done? When the changes have been integrated into the ON gate, and all corresponding changes have been made to the Solaris installer and Solaris documentation. 4. Technical Description The following changes will be made: 1. Remove all 32-bit SPARC modules. Leave 64-bit modules where they are, except for the changes noted in this document. 64-bit modules will continue to be delivered in the "xxx/sparcv9" directories, so the kernel run time linker will not be modified. Some customers use the OBP variable "boot-file" to specify which file to boot their system with. /platform/sun4u/kernel/unix is a 32-bit binary and will no longer be delivered. To allow customers whose "boot-file" OBP variable is set to "kernel/unix" to continue to boot, /platform/sun4u/kernel/unix will become a symbolic link to /platform/sun4u/kernel/sparcv9/unix. The 64-bit OS will thus be booted even if "boot-file" is set to "kernel/unix". The Solaris 10 release notes will explicitly note this change. 2. Remove all 32-bit sparc-only packages. The only exception to this is SUNWcar.u, upon which too many things depend. Where appropriate, driver conf files and install scripts will be moved into the corresponding 64-bit sparc package. The following packages will be removed: SUNWcpc.u SUNWcpr.u SUNWcg6.u SUNWcvc.u SUNWdfb.u SUNWdrr.u SUNWfctl SUNWfcip SUNWfcp SUNWhmd SUNWidn.u SUNWifp SUNWk5ok.u SUNWluxd.u SUNWluxl SUNWpd SUNWqlc SUNWses SUNWssad SUNWusoc SUNWuxfl1.u 3. EOL support of all UltraSPARC-I CPUs. If the secondary boot loaders detect an UltraSPARC-I processor, a polite message will be printed for the user and the kernel will not be loaded. To the user, this will appear as such: ok boot Resetting ... Sun Ultra 1 SBus (UltraSPARC 143MHz), No Keyboard OpenBoot 3.11, 64 MB memory installed, Serial #8767953. Ethernet address 8:0:20:85:c9:d1, Host ID: 8085c9d1. Rebooting with command: boot Boot device: /sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@0,0:a File and args: This CPU is not supported by this release of Solaris. Program terminated ok 4. Remove the boot.conf boot policy file from Solaris, including all code which deals with the boot policy (see [4]). 5. Support for the SUNW,Ultra-1 platform will no longer be delivered, as that platform only uses UltraSPARC-I CPUs. SUNW,Ultra-2 will become the reference implemented desktop platform to which the other desktop platforms (i.e. Ultra-30, Ultra-60) link to in /usr/platform. 6. Currently, if Solaris detects downrev firmware running on a machine at boot time, a warning is printed and the 32-bit OS is booted (see [4]). Since the 32-bit OS will no longer be delivered, if Solaris detects downrev firmware, a polite message will be printed which instructs the user to upgrade the firmware and the kernel will not be loaded. This proposal does not seek to alter the arrangement of binaries in isa-specific directories linked to isaexec. The current system is well-known by our customers and developers and there is no need to change it at the present time. Furthermore, the isaexec scheme will remain necessary going forward as long as the possibility of supporting dual-boot systems exists (e.g. x86-64). If Solaris 10 is installed via upgrade onto a supported machine which previously did not have 64-bit packages, the installer will silently install all necessary 64-bit packages. The installer will no longer ask the user if 64-bit support should be included. The Solaris 10 release notes will have a section describing this EOL. 5. Reference Documents [1] PSARC 2002/255 delivered the advance notice. [2] PSARC 2002/013 removed sun4m architecture support from Solaris 10. [3] The End-of-Support section of the Solaris 9 9/02 Release Notes includes 32-bit kernels as well as UltraSPARC-I processors as Future End-of-Support Products. [4] boot(1M) man page 6. Resources and Schedule 6.1. Projected Availability Q3 FY03 6.2. Cost of Effort 1 development engineer 3 months 1 install engineer 1 month 1 test engineer 1 month 6.3. Cost of Capital Resources Existing. 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON C-Team 6.4.2. Contributing OpCo/BU/Division Name: SKT 6.4.3. Type of SC Approval needed: Fasttrack 6.4.5. Is this a necessary project for OEM agreements: N 6.4.6. Notes/Dependencies: None. 6.4.7. Target RTI Date/Release: S10 Alpha 6.4.8. Target Code Design Review Date February 1, 2002 6.4.9. Did this project have prior SOESC approval for a Marketing Release and now your requesting to go into an Update Release or Early Access CD? No. 6.5. ARC review type: Fasttrack 7. Prototype Availability 7.1. Prototype Availability Prototype available first week of February 2003. 7.2. Prototype Cost 1 development engineer 2 months. From sacadmin Wed Jan 15 15:54:16 2003 Date: Wed, 15 Jan 2003 15:53:10 -0800 From: Richard McDougall User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ Blaine CC: Richard McDougall , tpm@eng.sun.com, psarc@sac.eng.sun.com Subject: Re: (PSARC) Re: 2003/014 was approved today Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 7314 Thanks - your done. Richard. Russ Blaine wrote: > On Wed, Jan 15, 2003 at 10:21:21AM -0800, Richard McDougall wrote: > > >The case was approved today, pending an updated spec that captures the > >final implementation. Could you please send an updated one-pager showing > >the implementation that was discussed in the various emails? > > > Here is the updated spec. The only change from the submitted spec is concerning > the OBP boot-file variable problem, the solution to which was to symlink > kernel/unix to kernel/sparcv9/unix and document that link in the release notes. > > 1. Introduction > 1.1. Project/Component Working Name: > > EOL of 32-bit SPARC kernels (follow-on case) > > 1.2. Name of Document Author/Supplier: > > Russell Blaine > > 1.3. Date of This Document: > > 1/15/2003 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > > PSARC, SOESC, ONSC > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: kirk.wells@sun.com > 1.5.2. Responsible Engineer: russell.blaine@sun.com > > 2. Project Summary > 2.1. Project Description > > This proposal is to remove support for 32-bit SPARC kernels > from Solaris 10. The advance warning of this EOL has already > been delivered in an update of Solaris 9 (see [3]). > > This proposal is also to remove support for UltraSPARC-I > processors. Advance warning of this EOL has already been > delivered in an update of Solaris 9 (see [3]). The advance > warning stated that UltraSPARC-I processors running at 200 MHz > or slower may not be supported in a future release. Since > there were no UltraSPARC-I processors sold running at greater > than 200 MHz, support for all UltraSPARC-I processors will be > removed with no additional customer impact. > > > 2.2. Risks and Assumptions > > See [1]. > > 3. Business Summary > > See [1]. > > 3.5. Opportunity Window/Exposure > > Solaris 10 > > 3.6. How will you know when you are done? > > When the changes have been integrated into the ON gate, and > all corresponding changes have been made to the Solaris > installer and Solaris documentation. > > 4. Technical Description > > The following changes will be made: > > 1. Remove all 32-bit SPARC modules. Leave 64-bit modules where they > are, except for the changes noted in this document. 64-bit > modules will continue to be delivered in the "xxx/sparcv9" > directories, so the kernel run time linker will not be modified. > > Some customers use the OBP variable "boot-file" to specify which > file to boot their system with. /platform/sun4u/kernel/unix is a > 32-bit binary and will no longer be delivered. To allow > customers whose "boot-file" OBP variable is set to "kernel/unix" > to continue to boot, /platform/sun4u/kernel/unix will become a > symbolic link to /platform/sun4u/kernel/sparcv9/unix. The 64-bit > OS will thus be booted even if "boot-file" is set to > "kernel/unix". The Solaris 10 release notes will explicitly > note this change. > > 2. Remove all 32-bit sparc-only packages. The only exception to > this is SUNWcar.u, upon which too many things depend. Where > appropriate, driver conf files and install scripts will be moved > into the corresponding 64-bit sparc package. The following > packages will be removed: > > SUNWcpc.u > SUNWcpr.u > SUNWcg6.u > SUNWcvc.u > SUNWdfb.u > SUNWdrr.u > SUNWfctl > SUNWfcip > SUNWfcp > SUNWhmd > SUNWidn.u > SUNWifp > SUNWk5ok.u > SUNWluxd.u > SUNWluxl > SUNWpd > SUNWqlc > SUNWses > SUNWssad > SUNWusoc > SUNWuxfl1.u > > 3. EOL support of all UltraSPARC-I CPUs. If the secondary boot loaders > detect an UltraSPARC-I processor, a polite message will be printed for the > user and the kernel will not be loaded. To the user, this will appear as > such: > > ok boot > Resetting ... > > Sun Ultra 1 SBus (UltraSPARC 143MHz), No Keyboard > OpenBoot 3.11, 64 MB memory installed, Serial #8767953. > Ethernet address 8:0:20:85:c9:d1, Host ID: 8085c9d1. > > Rebooting with command: boot > Boot device: /sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@0,0:a File and args: > This CPU is not supported by this release of Solaris. > Program terminated > ok > > 4. Remove the boot.conf boot policy file from Solaris, including all code > which deals with the boot policy (see [4]). > > 5. Support for the SUNW,Ultra-1 platform will no longer be delivered, as that > platform only uses UltraSPARC-I CPUs. SUNW,Ultra-2 will become > the reference implemented desktop platform to which the other > desktop platforms (i.e. Ultra-30, Ultra-60) link to in /usr/platform. > > 6. Currently, if Solaris detects downrev firmware running on a machine at > boot time, a warning is printed and the 32-bit OS is booted (see > [4]). Since the 32-bit OS will no longer be delivered, if Solaris detects > downrev firmware, a polite message will be printed which instructs the > user to upgrade the firmware and the kernel will not be loaded. > > This proposal does not seek to alter the arrangement of binaries in > isa-specific directories linked to isaexec. The current system is well-known > by our customers and developers and there is no need to change it at the > present time. Furthermore, the isaexec scheme will remain necessary going > forward as long as the possibility of supporting dual-boot systems exists > (e.g. x86-64). > > If Solaris 10 is installed via upgrade onto a supported machine which > previously did not have 64-bit packages, the installer will silently install > all necessary 64-bit packages. The installer will no longer ask the user > if 64-bit support should be included. > > The Solaris 10 release notes will have a section describing this EOL. > > 5. Reference Documents > > [1] PSARC 2002/255 delivered the advance notice. > > [2] PSARC 2002/013 removed sun4m architecture support from Solaris 10. > > [3] The End-of-Support section of the Solaris 9 9/02 Release Notes > includes 32-bit kernels as well as UltraSPARC-I processors as Future > End-of-Support Products. > > [4] boot(1M) man page > > 6. Resources and Schedule > 6.1. Projected Availability > > Q3 FY03 > > 6.2. Cost of Effort > > 1 development engineer 3 months > 1 install engineer 1 month > 1 test engineer 1 month > > 6.3. Cost of Capital Resources > > Existing. > > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: ON C-Team > 6.4.2. Contributing OpCo/BU/Division Name: SKT > 6.4.3. Type of SC Approval needed: Fasttrack > 6.4.5. Is this a necessary project for OEM agreements: N > 6.4.6. Notes/Dependencies: None. > 6.4.7. Target RTI Date/Release: S10 Alpha > 6.4.8. Target Code Design Review Date February 1, 2002 > 6.4.9. Did this project have prior SOESC approval for a > Marketing Release and now your requesting to go into an > Update Release or Early Access CD? No. > > 6.5. ARC review type: Fasttrack > > 7. Prototype Availability > 7.1. Prototype Availability > > Prototype available first week of February 2003. > > 7.2. Prototype Cost > > 1 development engineer 2 months. From sacadmin Wed Jan 15 16:03:20 2003 X-Authentication-Warning: pumbaa.eng.sun.com: simmonmt set sender to simmonmt@eng.sun.com using -f To: Russ Blaine Cc: Keith Holder , Bill Sommerfeld , Richard McDougall , psarc@sac.eng.sun.com, Tim Marsland Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels From: Matt Simmons Date: Wed, 15 Jan 2003 16:02:44 -0800 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Honest Recruiter, sparc-sun-solaris2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 500 >>>>> "RB" == Russ Blaine writes: RB> Therefore the installer won't need to be futzed with at all; a RB> machine with "boot-file" set to "kernel/unix" will just work RB> without modification. We can note in the release notes that RB> users should clear the OBP variable. Why shouldn't it warn and offer to fix anyway? Matt -- Matt Simmons - simmonmt@eng.sun.com "Money will buy you a pretty good dog, but it won't buy the wag of his tail." -- Unknown From sacadmin Wed Jan 15 16:50:59 2003 Date: Wed, 15 Jan 2003 16:50:22 -0800 (PST) From: Tim Marsland To: rab@eng.sun.com, simmonmt@eng.sun.com Subject: Re: 2003/014: EOL of 32-bit SPARC Kernels Cc: keith.holder@sun.com, sommerfeld@east.sun.com, Richard.McDougall@sun.com, psarc@sac.eng.sun.com, tpm@eng.sun.com Content-Length: 533 | From simmonmt@eng.sun.com Wed Jan 15 16:01 PST 2003 | | >>>>> "RB" == Russ Blaine writes: | | RB> Therefore the installer won't need to be futzed with at all; a | RB> machine with "boot-file" set to "kernel/unix" will just work | RB> without modification. We can note in the release notes that | RB> users should clear the OBP variable. | Why shouldn't it warn and offer to fix anyway? In part because it may not be wrong .. particularly on a machine with different bootable OS versions. tim