Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 18 Feb 2019, at 12:01, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> 
> On 18/02/2019 11:57, Wei Liu wrote:
>> On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
>>> 
>>>> On 18 Feb 2019, at 11:30, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
>>>> 
>>>> On 2/18/19 11:23 AM, Wei Liu wrote:
>>>>> On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars Kurth wrote:
>>>>>> Thank you Wei. It's interesting though that the full vs HVM only is 
>>>>>> almost identical in terms of SLOC's
>>>>>> Lars
>>>>> The cloc target counts the files in the dependency graph generated by
>>>>> make.
>>> Do we know for sure that CLOC counts everything in a file or does it honour 
>>> the pre-processor settings?
>> We certainly don't feed any preprocessor defines to it. I doubt it
>> understand C to that level of details anyway.
> 
> LoC isn't a fantastic metric under any circumstance.
> 
> Bigger code is definitely better, if the reason it is bigger is because
> it is because it is formatted for readability/clarity etc.

I don't disagree. A measure such as Logical Lines Of Code may be more 
appropriate longer term, as it removes the formatting/readability aspect. 

> Attempting to optimise for smaller LoC, other than making entire
> functional areas optional, is usually short sighted.

Agreed. 

We are basically using the SLOC figure as a proxy for "potential cost of safety 
certification" at least for Arm
I was hoping the results were clearer and I could use the figures to illustrate 
the impact of a PV or HVM only build to illustrate the safety impact, but maybe 
I should stay clear of this.

Regards
Lars



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel