On 02/22/10 12:30 PM, Jason King wrote:
> On Mon, Feb 22, 2010 at 2:11 PM, Garrett D'Amore<gdamore at sun.com> wrote:
>
>> On 02/22/10 12:00 PM, John Plocher wrote:
>>
>>> Given Roger's comment that 64 and beyone "breaks binary compatibility"
>>> and should only be done on a major release boundry, isn't *this* the
>>> exact right time to do so? The Solaris10 to OpenSolaris Enterprise
>>> change IMO *is* such a major release point. There won't be such an
>>> opportunity again for decades...
>>>
>>>
>> OpenSolaris still retains most of the binary compatibility with Solaris
>> Nevada. Unless there is a really compelling reason, I'd be loathe to
>> support any change which breaks existing S10 binaries.
>>
>> The ARCs are still (I believe) operating on the assumption that Solaris Next
>> and/or OpenSolaris represent a "pseudo major" release boundary. This means
>> that we can allow some interface breakage where it makes sense, but we are
>> still expected to try to ensure that most normal applications that work on
>> Solaris 10 and earlier will continue to function on the next release.
>>
>> We actually have more flexibility, IMO, in administrative interfaces such as
>> dladm, packaging, etc.
>>
> Isn't this what S10 containers are for? Could this be done in a way
> that S10 containers still run things correctly, while 'new' stuff gets
> the advantage of having the upper limit? As John said, the
> opportunity probably won't arise to revisit this again for a very
> long time, and as a customer who was burned for a very long time by
> the 256 fd limit for stdio (until a rather clever workaround was
> created), I'd be loathe to revisit similar limitations if it appears
> we are starting to approach them.
>
You should not have to use a Container to run *any* S10 application,
which is what such a change would effectively cause. It would create
huge heartache and pain for everyone involved, and create a *serious*
impediment for moving customers to using OpenSolaris.
If there was a really compelling argument, I can see investigating a way
for applications to be built with a special flag that enables this (not
even sure if that is possible) ala the 64-bit file offset flags, but I
haven't heard any compelling evidence that more than 32 such signals is
actually necessary for any real world applications.
- Garrett
