Irek, You seem to believe that there is a compelling need for > 32 real time signals. Can you provide some justification for this? Are there any specific examples you can cite that will not function well with only 32 such signals?
As far as your idea of reducing signals in the future -- I'm of the opinion that its harder to *reduce* a resource than grow it. We should not design with that escape hatch as a plan. I also confess I don't know why we should feel the need to reserve more than 24 signals, but I also am not privy to the plans and future projects of the kernel group. If they aren't comfortable leaving themselves that few allocated signals, then my inclination is to trust that judgment. Roger, can you elaborate (in private if need be) on the concern of leaving only 24 available signal slots? As far as your request for a derail -- no, I don't think that this is appropriate. However, I am going to request that we go ahead and promote this to a fast track. The amount of discussion we've already had here puts this outside the scope of a self-review. Roger, please mark this as such with a timer set for one week from today (although it can probably be approved at Wednesday's PSARC meeting). - Garrett