From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by mx.groups.io with SMTP id smtpd.web10.22591.1676920477563024173 for ; Mon, 20 Feb 2023 11:14:37 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=fiO3QOVU; spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: quicinc.com, ip: 205.220.180.131, mailfrom: quic_rcran@quicinc.com) Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31KD3jwh017896; Mon, 20 Feb 2023 19:14:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : to : references : from : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=tNp5qxhb77VRqYneBTNUixpkFrsTYiQS07j8ILCbDlk=; b=fiO3QOVUJUzqmQGxvn6+YYiEUMB2xrdCkXTSzXgd1MBw1cQmK4A4i5zRqkckBY0bMoQx nQhL73Tcq7ku6G4TO8Fu1W4oydXTwuly/b1338BBkBgYC3l7mmVnp8XX/AIsBSQ93LME NfCsmLPl9Y3EBT7ta2/LUAep7oL+/ER5WJTYAVj8TwjMibUvC0vVNfD5Ldb1QfI+R5X8 06utkTP9ZZtnbpogHC0Q+emmGCHhp0rcK865ATswPbLGKseli5ZpjNMGB5viqzVxELTz lL9ltm9c2LCuVciU+WnsLnDJVjeYEHFVrnJGycGotprmUTUB/B5uLKq/Ru7RtntzrvAB Tw== Received: from nasanppmta01.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3ntq2enwep-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Feb 2023 19:14:26 +0000 Received: from nasanex01b.na.qualcomm.com (nasanex01b.na.qualcomm.com [10.46.141.250]) by NASANPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 31KJEPDU012577 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Feb 2023 19:14:25 GMT Received: from [10.110.63.83] (10.80.80.8) by nasanex01b.na.qualcomm.com (10.46.141.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.41; Mon, 20 Feb 2023 11:14:25 -0800 Message-ID: Date: Mon, 20 Feb 2023 12:14:24 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v4 1/1] MdePkg: Use ANSI colors to indicate debug message severity To: "Kinney, Michael D" , "devel@edk2.groups.io" , "Gao, Liming" , "Liu, Zhiguang" , Andrew Fish References: <20221027185117.758157-1-rebecca@quicinc.com> From: "Rebecca Cran" In-Reply-To: X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01b.na.qualcomm.com (10.46.141.250) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: NcFS0aiyNPPnhKkugejT_1BD3_Tv7TqE X-Proofpoint-GUID: NcFS0aiyNPPnhKkugejT_1BD3_Tv7TqE X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-20_15,2023-02-20_02,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 priorityscore=1501 clxscore=1015 suspectscore=0 impostorscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 malwarescore=0 bulkscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302200176 Content-Language: en-US Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit On 11/10/22 12:11, Kinney, Michael D wrote: > In the edk2 repo, I see the following instances of the DebugPrintMarker() API > where you are currently adding he ANSI color sequences. Should all of these > be updated? I did not review the edk2-platforms repo. And there may be > downstream custom DebugLib instances. It would better if this feature could > be enabled for all existing DebugLib instances, but the only common location > is the DEBUG() macro definition in MdePkg/Include/Library/DebugLib.h and > adding code to that macro adds statements to the module calling the DebugLib > services, which can increase code size. I'll update the other instances. Given it's purely an aesthetic change, I'm not sure we need to worry about custom instances? > Also, the ErrorLevel parameter is a bitmask. It cannot be used in > a switch/case statement for only 1 bit being set. To test for a > debug message of type ERROR or WARN, a check must be done for that > one bit being set in ErrorLevel. Thanks, I'll fix that. > > The DebugLib also provides support for ASSERT() macros. Should > ASSERT() messages have the same color as an ERROR message? Or > its own color? I wasn't thinking about ASSERT messages because those are super clear being one of the last messages printed. > The logic below changes the color for the message based on message > type. But is does not save/restore the current ANSI color setting. > It see it using the END_ESC_SEQ. Does that put the color settings > back to the previous setting? No, it resets it to the terminal's default color scheme. I'm not aware of a way to save/restore the color. -- Rebecca Cran