Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack, timeout 06/15/2010]
This case has timed out with a +1 and, in addition, was approved during the PSARC meeting of 16-Jun-2010. pete ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
EOF legacy processor type truth values [PSARC/2010/211 FastTrack, timeout 06/15/2010]
Below is an amended proposal. Timer is not reset as it essentially clarifies the discussion so far. Required release binding: Patch binding for the announcement and marking as Obsolete. Minor binding for the removal. 1. Introduction 1.1. Project/Component Working Name: EOF legacy processor type truth values 1.2. Name of Document Author/Supplier: Venky TV 1.3. Date of This Document: June 04, 2010 4. Technical Description: 4.1. Details: This projects aims to remove processor type truth values in /usr/bin which are no longer relevant -- namely, i286, i860, iAPX286, m68k, mc68000, mc68010, mc68020, mc68030, mc68040, sun2, sun3, sun3x, sun4, sun4c, sun4d, sun4e, u370, u3b, u3b15, u3b2, u3b5, vax and pdp11 Since none of these platforms are supported by the current release of Solaris, these executable always return a non-zero exit code. Any utility still depending on these executables for processor type checks will continue working as expected (with some extra error messages) as command not found equates to false as far as the exit codes are concerned. As an exception, support for sun4m is still being retained because it is possible that a script which is also designed to run on Solaris 9 (a release that supports sun4m) might possibly benefit from not encountering command not found error messages. Once Solaris 9 is EOL'd, the sun4m binary can be dropped. 4.2. Bug/RFE Number(s): 6958555 Remove processor type truth which are no longer relevant 4.5. Interfaces: The following interfaces will be deleted: /usr/bin/i286 /usr/bin/i860 /usr/bin/iAPX286 /usr/bin/m68k /usr/bin/mc68000 /usr/bin/mc68010 /usr/bin/mc68020 /usr/bin/mc68030 /usr/bin/mc68040 /usr/bin/sun2 /usr/bin/sun3 /usr/bin/sun3x /usr/bin/sun4 /usr/bin/sun4c /usr/bin/sun4d /usr/bin/sun4e /usr/bin/u370 /usr/bin/u3b /usr/bin/u3b15 /usr/bin/u3b2 /usr/bin/u3b5 /usr/bin/vax /usr/bin/pdp11 4.6. Doc Impact: The man pages for each of these utilities will be removed. iAPX286.1 i286.1 i860.1 pdp11.1 u3b.1 u3b2.1u3b5.1 u3b15.i vax.i u370.1 4.10. Packaging Delivery: All these are part of the SUNWcs package. There is no impact on install/upgrade. 6. Resources and Schedule: 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: Open ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack, timeout 06/15/2010]
KzEKClBldGVyIERlbm5pcyA8cGV0ZXIuZGVubmlzQG9yYWNsZS5jb20+IHdyb3RlOgoKPkJlbG93 IGlzIGFuIGFtZW5kZWQgcHJvcG9zYWwuIFRpbWVyIGlzIG5vdCByZXNldCBhcyBpdCBlc3NlbnRp YWxseQo+Y2xhcmlmaWVzIHRoZSBkaXNjdXNzaW9uIHNvIGZhci4KPgo+UmVxdWlyZWQgcmVsZWFz ZSBiaW5kaW5nOgo+ICAgICBQYXRjaCBiaW5kaW5nIGZvciB0aGUgYW5ub3VuY2VtZW50IGFuZCBt YXJraW5nIGFzIE9ic29sZXRlLgo+ICAgICBNaW5vciBiaW5kaW5nIGZvciB0aGUgcmVtb3ZhbC4K Pgo+Cj4xLiBJbnRyb2R1Y3Rpb24KPiAgICAxLjEuIFByb2plY3QvQ29tcG9uZW50IFdvcmtpbmcg TmFtZToKPiAgICAgICAgIEVPRiBsZWdhY3kgcHJvY2Vzc29yIHR5cGUgdHJ1dGggdmFsdWVzCj4K PiAgICAxLjIuIE5hbWUgb2YgRG9jdW1lbnQgQXV0aG9yL1N1cHBsaWVyOgo+ICAgICAgICAgVmVu a3kgVFYKPgo+ICAgIDEuMy4gRGF0ZSBvZiBUaGlzIERvY3VtZW50Ogo+ICAgICAgICAgSnVuZSAw NCwgMjAxMAo+Cj4KPjQuIFRlY2huaWNhbCBEZXNjcmlwdGlvbjoKPgo+ICAgICA0LjEuIERldGFp bHM6Cj4KPiAgICAgICAgICBUaGlzIHByb2plY3RzIGFpbXMgdG8gcmVtb3ZlIHByb2Nlc3NvciB0 eXBlIHRydXRoIHZhbHVlcyBpbgo+ICAgICAgICAgIC91c3IvYmluIHdoaWNoIGFyZSBubyBsb25n ZXIgcmVsZXZhbnQgLS0gbmFtZWx5LCBpMjg2LCBpODYwLAo+ICAgICAgICAgIGlBUFgyODYsIG02 OGssIG1jNjgwMDAsIG1jNjgwMTAsIG1jNjgwMjAsIG1jNjgwMzAsIG1jNjgwNDAsCj4gICAgICAg ICAgc3VuMiwgc3VuMywgc3VuM3gsIHN1bjQsIHN1bjRjLCBzdW40ZCwgc3VuNGUsIHUzNzAsIHUz YiwgdTNiMTUsCj4gICAgICAgICAgdTNiMiwgdTNiNSwgdmF4IGFuZCBwZHAxMQo+Cj4gICAgICAg ICAgU2luY2Ugbm9uZSBvZiB0aGVzZSBwbGF0Zm9ybXMgYXJlIHN1cHBvcnRlZCBieSB0aGUgY3Vy cmVudAo+ICAgICAgICAgIHJlbGVhc2Ugb2YgU29sYXJpcywgdGhlc2UgZXhlY3V0YWJsZSBhbHdh eXMgcmV0dXJuIGEgbm9uLXplcm8KPiAgICAgICAgICBleGl0IGNvZGUuICBBbnkgdXRpbGl0eSBz dGlsbCBkZXBlbmRpbmcgb24gdGhlc2UgZXhlY3V0YWJsZXMKPiAgICAgICAgICBmb3IgcHJvY2Vz c29yIHR5cGUgY2hlY2tzIHdpbGwgY29udGludWUgd29ya2luZyBhcyBleHBlY3RlZAo+ICAgICAg ICAgICh3aXRoIHNvbWUgZXh0cmEgZXJyb3IgbWVzc2FnZXMpIGFzICJjb21tYW5kIG5vdCBmb3Vu ZCIgZXF1YXRlcwo+ICAgICAgICAgIHRvICJmYWxzZSIgYXMgZmFyIGFzIHRoZSBleGl0IGNvZGVz IGFyZSBjb25jZXJuZWQuCj4KPiAgICAgICAgICBBcyBhbiBleGNlcHRpb24sIHN1cHBvcnQgZm9y IHN1bjRtIGlzIHN0aWxsIGJlaW5nIHJldGFpbmVkCj4gICAgICAgICAgYmVjYXVzZSBpdCBpcyBw b3NzaWJsZSB0aGF0IGEgc2NyaXB0IHdoaWNoIGlzIGFsc28gZGVzaWduZWQgdG8KPiAgICAgICAg ICBydW4gb24gU29sYXJpcyA5IChhIHJlbGVhc2UgdGhhdCBzdXBwb3J0cyBzdW40bSkgbWlnaHQg cG9zc2libHkKPiAgICAgICAgICBiZW5lZml0IGZyb20gbm90IGVuY291bnRlcmluZyAiY29tbWFu ZCBub3QgZm91bmQiIGVycm9yCj4gICAgICAgICAgbWVzc2FnZXMuICBPbmNlIFNvbGFyaXMgOSBp cyBFT0wnZCwgdGhlIHN1bjRtIGJpbmFyeSBjYW4gYmUKPiAgICAgICAgICBkcm9wcGVkLgo+Cj4g ICAgIDQuMi4gQnVnL1JGRSBOdW1iZXIocyk6Cj4KPiAgICAgICAgICA2OTU4NTU1IFJlbW92ZSBw cm9jZXNzb3IgdHlwZSB0cnV0aCB3aGljaCBhcmUgbm8gbG9uZ2VyIHJlbGV2YW50Cj4KPiAgICAg NC41LiBJbnRlcmZhY2VzOgo+Cj4gICAgICAgICAgVGhlIGZvbGxvd2luZyBpbnRlcmZhY2VzIHdp bGwgYmUgZGVsZXRlZDoKPgo+ICAgICAgICAgIC91c3IvYmluL2kyODYKPiAgICAgICAgICAvdXNy L2Jpbi9pODYwCj4gICAgICAgICAgL3Vzci9iaW4vaUFQWDI4Ngo+ICAgICAgICAgIC91c3IvYmlu L202OGsKPiAgICAgICAgICAvdXNyL2Jpbi9tYzY4MDAwCj4gICAgICAgICAgL3Vzci9iaW4vbWM2 ODAxMAo+ICAgICAgICAgIC91c3IvYmluL21jNjgwMjAKPiAgICAgICAgICAvdXNyL2Jpbi9tYzY4 MDMwCj4gICAgICAgICAgL3Vzci9iaW4vbWM2ODA0MAo+ICAgICAgICAgIC91c3IvYmluL3N1bjIK PiAgICAgICAgICAvdXNyL2Jpbi9zdW4zCj4gICAgICAgICAgL3Vzci9iaW4vc3VuM3gKPiAgICAg ICAgICAvdXNyL2Jpbi9zdW40Cj4gICAgICAgICAgL3Vzci9iaW4vc3VuNGMKPiAgICAgICAgICAv dXNyL2Jpbi9zdW40ZAo+ICAgICAgICAgIC91c3IvYmluL3N1bjRlCj4gICAgICAgICAgL3Vzci9i aW4vdTM3MAo+ICAgICAgICAgIC91c3IvYmluL3UzYgo+ICAgICAgICAgIC91c3IvYmluL3UzYjE1 Cj4gICAgICAgICAgL3Vzci9iaW4vdTNiMgo+ICAgICAgICAgIC91c3IvYmluL3UzYjUKPiAgICAg ICAgICAvdXNyL2Jpbi92YXgKPiAgICAgICAgICAvdXNyL2Jpbi9wZHAxMQo+Cj4gICAgIDQuNi4g RG9jIEltcGFjdDoKPgo+ICAgICAgICAgIFRoZSBtYW4gcGFnZXMgZm9yIGVhY2ggb2YgdGhlc2Ug dXRpbGl0aWVzIHdpbGwgYmUgcmVtb3ZlZC4KPgo+ICAgICAgICAgICBpQVBYMjg2LjEgaTI4Ni4x ICBpODYwLjEgIHBkcDExLjEgdTNiLjEKPiAgICAgICAgICAgdTNiMi4xICAgIHUzYjUuMSAgdTNi MTUuaSB2YXguaSAgIHUzNzAuMQo+Cj4gICAgIDQuMTAuIFBhY2thZ2luZyAmIERlbGl2ZXJ5Ogo+ Cj4gICAgICAgICAgIEFsbCB0aGVzZSBhcmUgcGFydCBvZiB0aGUgU1VOV2NzIHBhY2thZ2UuICBU aGVyZSBpcyBubyBpbXBhY3QKPiAgICAgICAgICAgb24gaW5zdGFsbC91cGdyYWRlLgo+Cj4KPjYu IFJlc291cmNlcyBhbmQgU2NoZWR1bGU6Cj4gICAgNi40LiBQcm9kdWN0IEFwcHJvdmFsIENvbW1p dHRlZSByZXF1ZXN0ZWQgaW5mb3JtYXRpb246Cj4gICAgICAgICA2LjQuMS4gQ29uc29saWRhdGlv biBvciBDb21wb25lbnQgTmFtZToKPiAgICAgICAgICAgICAgICBPTgo+Cj4gICAgNi41LiBBUkMg cmV2aWV3IHR5cGU6Cj4gICAgICAgICBGYXN0VHJhY2sKPgo+ICAgIDYuNi4gQVJDIEV4cG9zdXJl Ogo+ICAgICAgICAgT3Blbgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPm9wZW5zb2xhcmlzLWFyYyBtYWlsaW5nIGxpc3QKPm9wZW5zb2xhcmlzLWFyY0Bv cGVuc29sYXJpcy5vcmcK ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack, timeout 06/15/2010]
If you base64 decode it, it just says: +1 ;-) ольга крыжановская wrote: How long did you type on the text below? :) Something is wrong, either list or mail app. Olga 2010/6/10 Garrett D'Amore garr...@damore.org: KzEKClBldGVyIERlbm5pcyA8cGV0ZXIuZGVubmlzQG9yYWNsZS5jb20+IHdyb3RlOgoKPkJlbG93 IGlzIGFuIGFtZW5kZWQgcHJvcG9zYWwuIFRpbWVyIGlzIG5vdCByZXNldCBhcyBpdCBlc3NlbnRp [snip] ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack, timeout 06/15/2010]
On 10.06.10 20:48, Andrew Gabriel wrote: If you base64 decode it, it just says: +1 Garrett does sometimes have a roundabout way of saying things ;-)) cheers -- michael.schus...@oracle.com http://blogs.sun.com/recursion Recursion, n.: see 'Recursion' ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack timeout 06/15/2010]
On 6/8/10 1:15 PM, Garrett D'Amore wrote: d) every bit costs something. to compile, to link, to deliver. Just in the listing of /usr/bin. Anything which serves no useful function should IMO be removed. (Individually, these costs are minuscule, but taken collectively over the entire life of a distribution, across everyone who ever looks at them, has to compile, build or install them, and across multiple such trivially useless projects, the costs can be much larger.) While I don't feel strongly about this particular case, I have to say I don't really buy that argument in general. Many parts of Solaris may have value to only a relatively small audience, but the positive value to that audience is often much larger than the small gain to everyone else from removing the feature. I'm not convinced that we have an effective way to figure out which features fall into this category, unless someone who cares about the feature happens to be watching PSARC when the EOF fast-track goes by. This is similar to the discussion about which packages to remove from SFW; even if each individual package (or feature) is valuable only to a small group, removing enough pieces makes it likely that everyone is affected by at least one of the removals. For the SFW packages, I like the suggestion that was made earlier about reviewing the overall removal plan rather than discovering it through individual fast-tracks. I don't know that it's possible to review a similar plan for small feature removals like this case, but we should be aware that the same limitations apply in our ability to judge the impact of individual removals. Scott -- Scott Rotondo Senior Principal Engineer, Solaris Core OS Engineering President, Trusted Computing Group Phone: +1 650 786 6309 (Internal x86309) ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack timeout 06/15/2010]
Nevertheless, if there are _any_ scripts that use it, unless you get rid of all 29 (or however many) links to it, I don't see any incremental gain by removing some of them. Am taking the conservative approach here by removing only those commands which could not possibly return true. It would be great to be able to remove all processor truth value commands, but the risk of breaking existing scripts is too high. This is an attempt to get rid of as much clutter as possible without breaking anything. (And in the process, get tiny benefits like making tab-completions of command names in bash more relevant, though that is not the main intent of this case.) And you are right. There are more of these commands which are not listed in the manpages and are also not relevant any more -- the Motorola m68k series, for example. Plan to add these to the case. We might end up with just the following left behind -- sun, sparc, i386, i486, i86pc -- and have all of these deleted (along with the ones listed in the original 1pager): /usr/bin/sun[234]* /usr/bin/mc68* /usr/bin/m68k Venky. ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack timeout 06/15/2010]
Nevertheless, if there are _any_ scripts that use it, unless you get rid of all 29 (or however many) links to it, I don't see any incremental gain by removing some of them. Am taking the conservative approach here by removing only those commands which could not possibly return true. It would be great to be able to remove all processor truth value commands, but the risk of breaking existing scripts is too high. This is an attempt to get rid of as much clutter as possible without breaking anything. (And in the process, get tiny benefits like making tab-completions of command names in bash more relevant, though that is not the main intent of this case.) And you are right. There are more of these commands which are not listed in the manpages and are also not relevant any more -- the Motorola m68k series, for example. Plan to add these to the case. We might end up with just the following left behind -- sun, sparc, i386, i486, i86pc -- and have all of these deleted (along with the ones listed in the original 1pager): /usr/bin/sun[234]* /usr/bin/mc68* /usr/bin/m68k ky. Little as I like this, at least it would be more consistent to get rid of more of them. And I've tried the missing command experiment on all of sh, csh, ksh, and bash; as long as -e isn't in effect, all those shells happily proceed past a missing command (well, happily save for an error message), so I have to admit breakage would likely be little or none. Of those you just mentioned, it might be worth keeping sun4m for awhile, since AFAIK Solaris 9 (last that could run on sun4m) is still supported, and thus a script might exist such that it would still be true on Solaris 9 (and might be a nice gesture for it to be silently false on newer versions rather than false with shell error messages). The sun4m link could always be removed later, when no longer true on any still-supported version. -- This message posted from opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack timeout 06/15/2010]
On Wed, Jun 09, 2010 at 02:15:56AM -0700, Richard L. Hamilton wrote: Of those you just mentioned, it might be worth keeping sun4m for awhile, since AFAIK Solaris 9 (last that could run on sun4m) is still supported, and thus a script might exist such that it would still be true on Solaris 9 (and might be a nice gesture for it to be silently false on newer versions rather than false with shell error messages). The sun4m link could always be removed later, when no longer true on any still-supported version. Makes sense. Thanks, Venky. ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack timeout 06/15/2010]
On Tue, Jun 08, 2010 at 01:15:18PM -0700, Garrett D'Amore wrote: d) every bit costs something. to compile, to link, to deliver. [...] There's also a run-time cost. Anyone who's browsed for executables to open media content with from Firefox will have observed that browsing /bin borders on the painful. (Granted, this is a problem in FF, not the OS. For non-GUI apps, with ZFS root, this cost is negligible.) ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack timeout 06/15/2010]
The same script will fail on Ububtu as well - I just checked they don't exist there. if vax; then will fail whether vax exists with one or with vax not present. Whether -e is set is not important. Other than the additional errors the script will continue to run. Casper ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack timeout 06/15/2010]
On Tue, Jun 08, 2010 at 01:44:47PM +0100, Darren J Moffat wrote: On 08/06/2010 13:14, Steve McKinty wrote: If I wrote a portable configure script which contained something like: if [ vax ]; then do vaxy setup else if [ u3b ]; then do ATT setup else if [ sun ]; then do Solaris setup endif it would work unchanged on all those architectures. Take out the vax and u3b commands and it will then crash when run on Solaris. The same script will fail on Ububtu as well - I just checked they don't exist there. And technically, this will continue to work as expected, with an extra error message like: test.sh: vax: not found. Since a command not found evaluates to false, the logic would still be intact. Venky. ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack timeout 06/15/2010]
On 8/06/10 07:59 PM, Steve McKinty wrote: Why are these not relevant? In my experience they are mostly used in scripts and Makefiles, to ensure that the right code path is taken. Won't removing them break older configure-style scripts, i.e. ones that test things like if [ ! vax ] etc.? Is the gain of removal worth more than potential breakage of older (especially FOSS) code? ... /usr/bin/iAPX286 /usr/bin/i286 /usr/bin/i860 /usr/bin/pdp11 /usr/bin/u3b /usr/bin/u3b2 /usr/bin/u3b5 /usr/bin/u3b15 /usr/bin/vax /usr/bin/u370 Can you tell me, with a straight face - and proof- that Solaris 2.6 or later will even run on *any* of the above processors? The above processor truth types are all links to machid, which contains this comment in $SRC/cmd/machid/machid.c: /* * This program replicates the function of the links from a machine name * (such as sun4c) through /usr/kvm to true or false as appropriate. It * knows the correct special cases. * * IMPORTANT NOTE: * * Do not modify this program to know about additional special cases or * reflect new platforms or instruction set architectures. This is a * deprecated interface and strictly for backwards compatibility. This * is psarc/1992/171. Note the following excerpt from the opinion: * *It is most important to note that the manual page states in *the NOTES section: The machid family of commands is *obsolete. Use uname -p and uname -m instead. * *The intent of Kernel Architecture Project team is to provide *only enough functionality to mimic the existing definitions *on the SPARC and Intel x86 versions of Solaris 2.x. No new *identifiers will ever be added to the documented and *undocumented identifiers listed above. */ I think it is long past time that we actually obsoleted the above interfaces. Pete: +1 James C. McPherson -- Senior Software Engineer, Solaris Oracle http://www.jmcp.homeunix.com/blog ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack timeout 06/15/2010]
On 8/06/10 10:33 PM, James Carlson wrote: Steve McKinty wrote: If I wrote a portable configure script which contained something like: if [ vax ]; then do vaxy setup Obviously, that should be if vax; then rather than with the test brackets, but otherwise I think Steve McKinty has a very good point. How many bytes are saved by removing these aliases for /usr/bin/false? Nit: they're links to /usr/bin/i286, which is an instance of machid.c: # List of all links present on all architectures and machines. # # Note that this function is obsolesent and we don't generally # add to this list (see psarc/1992/171). # FIRSTLINK = i286 LINKS = i386 i486 i860 i86pc iAPX286 \ m68k mc68000 mc68010 mc68020 mc68030 mc68040 \ sparc sun sun2 sun3 sun3x sun4 sun4c sun4m sun4d sun4e \ u370 u3b u3b15 u3b2 u3b5 vax pdp11 ROOTFIRSTLINK = $(ROOTBIN)/$(FIRSTLINK) ROOTLINKS = $(LINKS:%=$(ROOTBIN)/%) # # Install the program as the first machine in the list. # A look at the SCCS history for the file shows that it has not been touched since 1994. James C. McPherson -- Senior Software Engineer, Solaris Oracle http://www.jmcp.homeunix.com/blog ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack timeout 06/15/2010]
On Tue, 2010-06-08 at 11:59 +0200, Steve McKinty wrote: Why are these not relevant? In my experience they are mostly used in scripts and Makefiles, to ensure that the right code path is taken. Won't removing them break older configure-style scripts, i.e. ones that test things like if [ ! vax ] etc.? Is the gain of removal worth more than potential breakage of older (especially FOSS) code? Most such code is developed for Linux these days, and uses different approaches (primarily parsing uname output) to determine the machine and model type. I've never seen a script that would misbehave if these tools were absent. (I've seen scripts that would misbehave if they existed and returned a false positive, but even those cases are rare... I think autoconf in particular does not use them.) In case its not clear, here's another +1 on this case. - Garrett Steve Peter Dennis wrote: I'm sponsoring this case for Venky Tv. Required release binding: Patch binding for the announcement and marking as Obsolete. Minor binding for the removal. Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: EOF legacy processor type truth values 1.2. Name of Document Author/Supplier: Author: Venky TV 1.3 Date of This Document: 08 June, 2010 4. Technical Description 1. Introduction 1.1. Project/Component Working Name: EOF legacy processor type truth values 1.2. Name of Document Author/Supplier: Venky TV 1.3. Date of This Document: June 04, 2010 4. Technical Description: 4.1. Details: This projects aims to remove processor type truth values in /usr/bin which are no longer relevant -- namely, iAPX286, i286, i860, pdp11, u3b, u3b2, u3b5, u3b15, vax, and u370. 4.2. Bug/RFE Number(s): 6958555 Remove processor type truth which are no longer relevant 4.5. Interfaces: The following interfaces will be deleted: /usr/bin/iAPX286 /usr/bin/i286 /usr/bin/i860 /usr/bin/pdp11 /usr/bin/u3b /usr/bin/u3b2 /usr/bin/u3b5 /usr/bin/u3b15 /usr/bin/vax /usr/bin/u370 4.6. Doc Impact: The man pages for each of these utilities will be removed. iAPX286.1 i286.1 i860.1 pdp11.1 u3b.1 u3b2.1u3b5.1 u3b15.i vax.i u370.1 4.10. Packaging Delivery: All these are part of the SUNWcs package. There is no impact on install/upgrade. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF legacy processor type truth values [PSARC/2010/211 FastTrack timeout 06/15/2010]
On Tue, 2010-06-08 at 13:03 -0700, Scott Rotondo wrote: Several people have pointed out that the harm from removing these commands isn't that great because (a) recent scripts tend not to use this mechanism to figure out the type of platform, and (b) older scripts will still work (with error messages) because a missing command evaluates to false. But what about the other side of the cost-benefit equation? What's the upside from removing a handful of tiny files? I'm afraid I don't see it. Its there: a) people might decide that these are good tools for portability checks (they aren't!) b) people might complain that other processor types are not included, but we've already said that no new cpu types are getting added c) therefore, should folks doing new ports create them for arm, s390, etc.? I hope not! d) every bit costs something. to compile, to link, to deliver. Just in the listing of /usr/bin. Anything which serves no useful function should IMO be removed. (Individually, these costs are minuscule, but taken collectively over the entire life of a distribution, across everyone who ever looks at them, has to compile, build or install them, and across multiple such trivially useless projects, the costs can be much larger.) -- Garrett In general, this might be true. But in case of these, they're all hard links (total of 29 on snv_97, at least) to a single executable, which just compares the basename of its argv[0] with uname -p, uname -m, uname -c, and some hardcoded constants. It doesn't need to be changed in any way to add or delete names; only links need to be added (or if there were any appreciable benefit, deleted). This is not something that's going to get more broken over time, except in the sense of a smaller percentage of truth values (eventually zero) returning true on any platform existing outside of museums, collectors, and emulators. Granted that it's a stupid command. Granted even that adding more links to it might be counterproductive; and that others (googling shows me HP in particular) have also deprecated the command (although the man page of theirs I found was dated 2002; I have no idea if they or others have weeded out old processor names since then). The common intent seems at the least not to _add_ any more names to it, but to encourage the use of uname or getconf directly instead. Nevertheless, if there are _any_ scripts that use it, unless you get rid of all 29 (or however many) links to it, I don't see any incremental gain by removing some of them. -- This message posted from opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
