[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions
> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |