Joseph Kowalski wrote:
> John Plocher wrote:
>> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
>> This information is Copyright 2008 Sun Microsystems
>> 1. Introduction
>>     1.1. Project/Component Working Name:
>>      Switch SPARC GNU coreutils+bash from 32 to 64bit
>>     1.2. Name of Document Author/Supplier:
>>      Author:  Roland Mainz
>>     1.3  Date of This Document:
>>     30 May, 2008
>> 4. Technical Description
>>
>>     gisburn: Does it require an ARC case if we switch the GNU coreutils
>>          from 32bit to 64bit on SPARC only (no changes in interfaces and
>>          delivered files)?
>>     plocher: It doesn't sound like this has any architectural 
>> implications...
>>     gisburn: Not that I am aware of.
>>     plocher: so, I'd say that this was the entire arc review  :-)
>> 6. Resources and Schedule
>>     6.4. Steering Committee requested information
>>        6.4.1. Consolidation C-team Name:
>>         SFW
>>     6.5. ARC review type: Automatic
>>     6.6. ARC Exposure: open
>>   
> 
> Sorry, I want a fast-track.
> 
> 1)   I believe this is an incomplete project.  What's good for GNU 
> coreutils
>      is also good for the rest of the utilities.  The source of the 
> utilities doesn't
>      matter.
> 
>      Project completeness is always an arc concern.
> 
> 2)   We have a 32-bit user land (only) because 32-bit utilities on SPARC
>      weren't any faster than 64-bits (so why support both?).  Since we have
>      unsupported any 32-bit SPARC hardware, the change could be made
>      now.  However, validation needs to be done that this doesn't result in
>      performance regression.  (Should be faster on an x86 - its all about
>      the number of registers, not the data path.)  This is a C-team (PAC?)
>      issue, but it should be considered.

I completely agree with Joe here.

I'm derailing this automatic approval.  I want at least a fast-track 
that explains why the asymetry between SPARC and x86 is actually useful 
in addition to what Joe asked for.  I think this should actually be a 
full case rather than a fast-track given this would be a significant 
architectural change.  As Joe said the GNU part is irrelevant here what 
is relevant is the change in direction.

This case, if approved, will need an opinion to document the new policy 
and will also likely need updates to various best practices.

-- 
Darren J Moffat

Reply via email to