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

Reply via email to