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...
-John On Mon, Feb 22, 2010 at 11:37 AM, Garrett D'Amore <gdamore at sun.com> wrote: > On 02/22/10 11:28 AM, Roger A. Faulkner wrote: >> >> I am sponsoring this automatic case for myself. >> > > +1 on the case, on the justification for not expanding to 64. > > IMO, this pushes the boundary of what's permissible in a self-review, but I > see no reason to promote it to a full fast track at this point. > > ? ?-- Garrett > >> The number of realtime signals supported by Solaris is quite small (8). >> This is the minimum number required for Posix branding. >> >> However, other systems provide many more. >> Linux supports 32-64 realtime signals depending on the architecture, >> BSD does 32 or 64 depending on architecture, AIX supports 111. >> >> This affects Solaris directly in that the Linux zone >> provided by Solaris cannot support Linux applications >> that use more than 8 realtime signals. ?See the bug report: >> ? ? 6820733 lack of realtime signals causes Linux application >> ? ? ? ? ? ? in BrandZ to fail >> which is a duplicate of the more general bug report: >> ? ? 6820737 Solaris needs to increase the number of realtime signals >> ? ? ? ? ? ? for platform parity >> >> This case proposes to increase the number of realtime signals >> supported by Solaris from 8 to 32. >> >> Why not just go to 64, one might ask? >> The reason is contained in the 6820737 bug report's Evaluation: >> >> ? ? Now, as to the request to increase the number of real-time signals >> ? ? to 64, this would more than double the currently supported number >> ? ? of signals. ?The sigset_t structure, in its present definition, >> ? ? can only support a maximum of 128 signals. ?It's a limited resource. >> ? ? Increasing the number of real-time signals to 64 would leave only >> ? ? 24 bits remaining in the sigset_t definition for future expansion. >> ? ? We need more wiggle-room than that for future expansion. >> >> ? ? So, when the number of real-time signals is increased, it will only >> ? ? be increased to 32, not 64. ?We can increase to 64 only by changing >> ? ? the definition of sigset_t and this breaks binary compatibility, >> ? ? so this can be done only when we move from Solaris 2.x to Solaris 3.x >> ? ? (or whatever the next naming scheme will be called). >> >> Roger Faulkner >> >> > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org >
