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.
