[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>
  • From: Juergen Gross <jgross@xxxxxxxx>
  • Date: Tue, 5 Feb 2019 07:02:06 +0100
  • Autocrypt: addr=jgross@xxxxxxxx; prefer-encrypt=mutual; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNHkp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmRlPsLAeQQTAQIAIwUCU4xw6wIbAwcL CQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJELDendYovxMvi4UH/Ri+OXlObzqMANruTd4N zmVBAZgx1VW6jLc8JZjQuJPSsd/a+bNr3BZeLV6lu4Pf1Yl2Log129EX1KWYiFFvPbIiq5M5 kOXTO8Eas4CaScCvAZ9jCMQCgK3pFqYgirwTgfwnPtxFxO/F3ZcS8jovza5khkSKL9JGq8Nk czDTruQ/oy0WUHdUr9uwEfiD9yPFOGqp4S6cISuzBMvaAiC5YGdUGXuPZKXLpnGSjkZswUzY d9BVSitRL5ldsQCg6GhDoEAeIhUC4SQnT9SOWkoDOSFRXZ+7+WIBGLiWMd+yKDdRG5RyP/8f 3tgGiB6cyuYfPDRGsELGjUaTUq3H2xZgIPfOwE0EU4xwFgEIAMsx+gDjgzAY4H1hPVXgoLK8 B93sTQFN9oC6tsb46VpxyLPfJ3T1A6Z6MVkLoCejKTJ3K9MUsBZhxIJ0hIyvzwI6aYJsnOew cCiCN7FeKJ/oA1RSUemPGUcIJwQuZlTOiY0OcQ5PFkV5YxMUX1F/aTYXROXgTmSaw0aC1Jpo w7Ss1mg4SIP/tR88/d1+HwkJDVW1RSxC1PWzGizwRv8eauImGdpNnseneO2BNWRXTJumAWDD pYxpGSsGHXuZXTPZqOOZpsHtInFyi5KRHSFyk2Xigzvh3b9WqhbgHHHE4PUVw0I5sIQt8hJq 5nH5dPqz4ITtCL9zjiJsExHuHKN3NZsAEQEAAcLAXwQYAQIACQUCU4xwFgIbDAAKCRCw3p3W KL8TL0P4B/9YWver5uD/y/m0KScK2f3Z3mXJhME23vGBbMNlfwbr+meDMrJZ950CuWWnQ+d+ Ahe0w1X7e3wuLVODzjcReQ/v7b4JD3wwHxe+88tgB9byc0NXzlPJWBaWV01yB2/uefVKryAf AHYEd0gCRhx7eESgNBe3+YqWAQawunMlycsqKa09dBDL1PFRosF708ic9346GLHRc6Vj5SRA UTHnQqLetIOXZm3a2eQ1gpQK9MmruO86Vo93p39bS1mqnLLspVrL4rhoyhsOyh0Hd28QCzpJ wKeHTd0MAWAirmewHXWPco8p1Wg+V+5xfZzuQY0f4tQxvOpXpt4gQ1817GQ5/Ed/wsDtBBgB CAAgFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAlrd8NACGwIAgQkQsN6d1ii/Ey92IAQZFggA HRYhBFMtsHpB9jjzHji4HoBcYbtP2GO+BQJa3fDQAAoJEIBcYbtP2GO+TYsA/30H/0V6cr/W V+J/FCayg6uNtm3MJLo4rE+o4sdpjjsGAQCooqffpgA+luTT13YZNV62hAnCLKXH9n3+ZAgJ RtAyDWk1B/0SMDVs1wxufMkKC3Q/1D3BYIvBlrTVKdBYXPxngcRoqV2J77lscEvkLNUGsu/z W2pf7+P3mWWlrPMJdlbax00vevyBeqtqNKjHstHatgMZ2W0CFC4hJ3YEetuRBURYPiGzuJXU pAd7a7BdsqWC4o+GTm5tnGrCyD+4gfDSpkOT53S/GNO07YkPkm/8J4OBoFfgSaCnQ1izwgJQ jIpcG2fPCI2/hxf2oqXPYbKr1v4Z1wthmoyUgGN0LPTIm+B5vdY82wI5qe9uN6UOGyTH2B3p hRQUWqCwu2sqkI3LLbTdrnyDZaixT2T0f4tyF5Lfs+Ha8xVMhIyzNb1byDI5FKCb
  • Cc: Stefano Stabellini <stefanos@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, lars.kurth.xen@xxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <dunlapg@xxxxxxxxx>, Julien Grall <julien.grall@xxxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Stewart Hildebrand <Stewart.Hildebrand@xxxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 05 Feb 2019 06:02:22 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Openpgp: preference=signencrypt

On 04/02/2019 20:08, Stefano Stabellini wrote:
> On Mon, 4 Feb 2019, Jan Beulich wrote:
>>>>> On 01.02.19 at 19:52, <dunlapg@xxxxxxxxx> wrote:
>> I'm not going to reply in detail to all of what you wrote about fanatics,
>> but I would like to say that I think compiler people less of that than
>> you appear to imply, at least the ones I know. In particular, they can
>> be convinced of there being bugs by pointing out what aspect of the
>> standard their implementation violates. (Of course there are also
>> going to be areas where interpretations of the standard vary too
>> much to come to an agreement.)
>>> Improvements this series seeks to make, as I understand it, include
>>> (in order of urgency):
>>> 1. Fixing one concrete instance of "UB hazard"
>> Right, and we want to work around compiler bugs here.
>>> 2. Minimize risk of further "UB hazard" in this bit of functionality
>>> 3. Retain the effort Stefano has put in identifying all the places
>>> where such UB hazards need to be addressed.
>>> 4. Move towards MISRA-C compliance.
>>> As far as I can tell, primary objections you've leveled at the options
>>> which try to address 2-4 are:
>>> a. "UB hazard" still not zero
>>> b. MISRA compliancy no 100%
>>> c. Ugly
>>> d. Inefficient
>>> (Obviously some proposals have had more technical discussion.)
>>> Anything I missed?
>> I don't think so, especially since various aspects can fall under "ugly"
>> and/or "inefficient". What I'm not sure I see is what you mean to
>> express with all you wrote in terms of finding a way out of the
>> current situation (besides requesting a vote): Improving on a. and
>> b. is not a good excuse to extend c., at least not unequivocally.
>> Whether d. actually matters is a separate aspect, partly because it
>> may mean different things (it could e.g. be taken as another
>> wording for a. and b.).
> I would be OK with a vote (or Juergen making a decision for us), but
> this issue is not so fundamentally critical that I want to move forward
> with it at the cost of making one or more maintainers unhappy. Ideally,
> I would like to find an option that is acceptable for everybody.
> Unfortunately, it doesn't look like it's possible.

I can make a decision whether the series is fine for 4.12, but for being
ready to be committed I can only have an opinion or make a suggestion.

In my opinion we should try to move forward. Fighting opinions of
compiler developers won't help as George pointed out in a slightly
sarcastic way. ;-)

While a completely future proof solution would be nice I don't think
this is achievable now. And we should be aware that a solution being
better than what we have today should be preferred over a perfect
solution which doesn't work due to compiler issues.

>> And btw - I can't judge on b. anyway, as I still don't know what
>> exactly MISRA compliance is to mean, with the rules to adhere to
>> suitably justified.
> I can't pretend to know exactly what MISRAC compliance means for this
> specific issue, but we do have the recommended way forward by the
> compliance experts, which also matches the rough understanding of most
> of the engineers involved in this discussion. Picking the option
> suggested by the MISRAC people, could be a decent way to settle this
> debate?

This would be my suggestion, too.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.