"Garrett D'Amore" wrote:
> (As far as "something better", I think I prefer something along the
> lines of how AFS handles it, where $VARIABLE could be used within a
> symbolic link -- the kernel expands the variable when following the
> symlink. But we shouldn't try to design the solution he
Bart Smaalders wrote:
> x86 will for now need to deliver both 32 and 64 bit binaries. If you're
> worried
> about the performance issues involved w/ isaexec, then let's design
> something
If we start talking about isaexec, we should also talk about pfexec. I would
like to see the code moved
Alan Coopersmith wrote:
> Joseph Kowalski wrote:
> > I don't see why /usr/gnu/bin/awk should get preference over /usr/bin/awk
> > just because its in gnucore.
>
> How about because it's already known to be 64-bit clean since the GNU
> utilities run on platforms that are 64-bit only, while the Sol
Joerg Schilling wrote:
> If we start talking about isaexec, we should also talk about pfexec. I would
> like to see the code moved into the kernel. Other possible ways of getting
> rid
> of a userspace implementation for the pfexec features would be to implement
> something like capabilities th
On Mon, Jun 02, 2008 at 12:14:12PM -0700, Garrett D'Amore wrote:
> Yes, isaexec is needed for correctness, but its not used on any
> performance critical paths, and remains, IMO, an ugly hack rather than
> an elegant solution.
isaexec handling could move into the kernel if it had to to avoid the
Bart Smaalders wrote:
> Garrett D'Amore wrote:
>
>> My personal preference, for now, would be to deliver *both* 32- and
>> 64-bit versions of the applications for both SPARC and x86, but
>> deliver the 64-bit versions in a separate path (/usr/bin/sparcv9 and
>> /usr/bin/amd64 or somesuch), so th
Garrett D'Amore wrote:
> My personal preference, for now, would be to deliver *both* 32- and
> 64-bit versions of the applications for both SPARC and x86, but
> deliver the 64-bit versions in a separate path (/usr/bin/sparcv9 and
> /usr/bin/amd64 or somesuch), so that end users can just adjust t
Bart Smaalders wrote:
> I assume that the proposal here is to deliver 64 bit versions of these
> commands
> on sparc, and both 32 and 64 bit versions on x86.
I never saw this in the proposal. I believe is only said that the 64
bit versions
would be delivered on SPARC. No significant mention of
Alan Coopersmith wrote:
> Joseph Kowalski wrote:
>
>> Speaking of how a "volunteer open *source* community works",
>> this is a proposal about how a *binary* distribution should be constructed.
>> This is Sun's decision or a decision about a future OpenSolaris
>> reference distribution. Tell me
Garrett D'Amore wrote:
> My personal preference, for now, would be to deliver *both* 32- and
> 64-bit versions of the applications for both SPARC and x86, but deliver
> the 64-bit versions in a separate path (/usr/bin/sparcv9 and
> /usr/bin/amd64 or somesuch), so that end users can just adjust
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 Doc
Bart Smaalders wrote:
> Darren J Moffat wrote:
>
>> 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.
>
> Because we support x86 machines that don't implement 64 b
Darren J Moffat wrote:
> 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.
Because we support x86 machines that don't implement 64 bit support?
The same reason we
Joseph Kowalski wrote:
> Speaking of how a "volunteer open *source* community works",
> this is a proposal about how a *binary* distribution should be constructed.
> This is Sun's decision or a decision about a future OpenSolaris
> reference distribution. Tell me again how a volunteer makes this
>
John Plocher writes:
> Joseph Kowalski wrote:
> > To be more constructive, maybe we should look at the CLIP
> > case. On the surface, its not relevant, but perhaps we should
> > remember the strong advice (er, requirement) in that case of
> >
> >"When in Rome, do as the Romans".
>
> Since we
Joseph Kowalski writes:
> John Plocher wrote:
> > Joseph Kowalski wrote:
> >> Sorry, I want a fast-track.
> >
> > What are the architectural (as opposed to C-Team, Design or RE) issues?
> >>
> >> 1) I believe this is an incomplete project.
> >
> > This sounds to me like "go boil the ocean" scope
Joseph Kowalski wrote:
> To be more constructive, maybe we should look at the CLIP
> case. On the surface, its not relevant, but perhaps we should
> remember the strong advice (er, requirement) in that case of
>
>"When in Rome, do as the Romans".
Since we are moving all the inhabitants of th
Joseph Kowalski wrote:
> I don't see why /usr/gnu/bin/awk should get preference over /usr/bin/awk
> just because its in gnucore.
How about because it's already known to be 64-bit clean since the GNU
utilities run on platforms that are 64-bit only, while the Solaris
versions may or may not be ready
Joseph Kowalski wrote:
> Sorry, I want a fast-track.
What are the architectural (as opposed to C-Team, Design or RE) issues?
>
> 1) I believe this is an incomplete project.
This sounds to me like "go boil the ocean" scope creep.
Roland has identified several utilities that would benefit from
John Plocher wrote:
> Joseph Kowalski wrote:
>> To be more constructive, maybe we should look at the CLIP
>> case. On the surface, its not relevant, but perhaps we should
>> remember the strong advice (er, requirement) in that case of
>>
>>"When in Rome, do as the Romans".
>
> Since we are mov
Alan Coopersmith wrote:
> Joseph Kowalski wrote:
>
>> I don't see why /usr/gnu/bin/awk should get preference over /usr/bin/awk
>> just because its in gnucore.
>>
>
> How about because it's already known to be 64-bit clean since the GNU
> utilities run on platforms that are 64-bit only, whil
James Carlson wrote:
> Joseph Kowalski writes:
>
>> John Plocher wrote:
>>
>>> Joseph Kowalski wrote:
>>>
Sorry, I want a fast-track.
>>> What are the architectural (as opposed to C-Team, Design or RE) issues?
>>>
1) I believe this is an incomplete pr
John Plocher wrote:
> Joseph Kowalski wrote:
>> Sorry, I want a fast-track.
>
> What are the architectural (as opposed to C-Team, Design or RE) issues?
>>
>> 1) I believe this is an incomplete project.
>
> This sounds to me like "go boil the ocean" scope creep.
Sometimes the burners need to be
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
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:
>
25 matches
Mail list logo
