Re: [sv-cc] Proposal for Mantis 345 has been updated

Hi Steven,

many thanks for the updates on this topic. As you requested I have 
reviewed your updates again, here
is my feedback about the new version:
a) I strongly believe that it is not a good idea to leave the number of 
nested decryption envelopes that can
   be processed as implementation specific; in fact I demand that there 
is a minimum number of nestings
   that shall be processed by any implementation. Without such a least 
common denominator, we leave a
   rat hole for incompatibilities I would like to avoid.
b) I still have large concerns about the incompatibilities that might be 
introduces by failing VPI functions
    due to encryption of source code. There will be a lot of legacy code 
that will not check for such cases
    (bad style, but I am sure this exists). And having to do these kind 
of checks in new code might also
    introduce some runtime penalty I am not sure we can so easily neglect.
    Therefore I would ask for bringing up some creative ideas how to 
take both cases into account and
    have some solutions for them. IMHO the performance impact of such 
things will exceed the effect
    of dynamic variables and here we already spent some on the 
discussion of vpiValid, so why not here ???

If VPI would be a C++ interface, then I would suggest to have some 
register function that results in creating
a 'access to encrypted object' exception that my code could catch and 
properly process. This would be an
ideal solution (in my simple mind) for both problems, since its is not 
very intrusive and has a low runtime
overhead. But we are in C world now.  Bad luck.

That's all, but currently I see both issues as problems. The rest looks 
O.K. to me.

Best regards,
-Michael




Steven J. Dovich wrote:

>I have updated the wording as requested previously. And have
>incorporated comments from Michael and Jim where appropriate.
>
>I am still working out the text for vpi_get_value/vpi_put_value
>and will refresh the proposal at that time.
>
>/sjd
>  
>


-- 

NOTE: The content of this message may contain personal views 
      which are not neccessarily the views of Freescale, unless specifically stated.
 
         ___________________________________________________
        |                                                   |
      _ | Michael Rohleder            Tel: +49-89-92103-259 | _
     / )| Freescale Semiconductor     Fax: +49-89-92103-680 |( \
    / / |      Freescale Halbleiter Deutschland GmbH        | \ \
  _( (_ |  _   Schatzbogen 7, D-81829 Munich, Germany    _  | _) )_
 (((\ \>|_/ >                                           < \_|</ /)))
 (\\\\ \_/ /    mailto:Michael.Rohleder@freescale.com     \ \_/ ////)
  \       /_______________________________________________\       /
   \    _/                                                 \_    /
   /   /                                                     \   \

The information contained in this email has been classified as:
General Business Information                     ( )
Freescale Internal Use Only         ( )
Freescale Confidential Proprietary  ( )


*** This note may contain Freescale Confidential Proprietary or Freescale Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. 
    Thank you! ***