Jiewen:
SecurityPackage Patches are good to me.
Reviewed by : Chao Zhang
Thanks & Best regards
Chao Zhang
-Original Message-
From: Yao, Jiewen
Sent: Wednesday, September 21, 2016 2:45 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng; Zeng, Star; Kinney, Michael D; Gao, Liming; Zh
Hi Brian,
This is a good idea. I will have to study it some more
to figure out what the EBC versions of these macros would
map to.
Mike
> -Original Message-
> From: Brian J. Johnson [mailto:bjohn...@sgi.com]
> Sent: Tuesday, September 27, 2016 10:14 AM
> To: Andrew Fish ; Eugene Cohen
Eugene,
I agree. There are use cases for using UINTN so values can scale to CPU arch.
Casting those specific use cases from UINTN to UINT64 when used in a print call
is likely the safest method.
There are many use case of UINTN where the value is limited to 32-bits, and
a typecast is not requi
MIke,
> Portable sources that use type UINTN must never use values larger
> than
> 32-bits. Same for type INTN. Only use values in signed 32-bit range.
If the value is something like an enumeration or bitmask then I agree, but not
if it's something numeric that is supposed to scale to larger n
On 09/27/16 19:14, Brian J. Johnson wrote:
> On 09/27/2016 11:47 AM, Andrew Fish wrote:
>>
>>> On Sep 27, 2016, at 9:03 AM, Cohen, Eugene wrote:
>>>
Printing UINTN with %x *or* with %d are equally bugs.
For X64 / AARCH64 / IA64 builds, they are actual bugs (that happen to
work
Andrew,
Yes. Using fixed with base types instead of natural width base types is clearer
and very portable.
We do use UINTN in UEFI/PI spec APIs on purpose when the range of the argument
does need vary for different CPU widths. Using UINTN in function args
and local variables also generates sm
> On Sep 27, 2016, at 10:27 AM, Kinney, Michael D
> wrote:
>
> Andrew,
>
> Here is the comment in current code that explains some of the why.
>
> case 'd':
>if ((Flags & LONG_TYPE) == 0) {
> //
> // 'd', 'u', 'x', and 'X' that are not preceded by 'l' or 'L' are
Andrew,
Here is the comment in current code that explains some of the why.
case 'd':
if ((Flags & LONG_TYPE) == 0) {
//
// 'd', 'u', 'x', and 'X' that are not preceded by 'l' or 'L' are
assumed to be type "int".
// This assumption is made so the format
On 09/27/2016 11:47 AM, Andrew Fish wrote:
On Sep 27, 2016, at 9:03 AM, Cohen, Eugene wrote:
Printing UINTN with %x *or* with %d are equally bugs.
For X64 / AARCH64 / IA64 builds, they are actual bugs (that happen to
work most of the time).
Feel free to file a Bugzilla on the extensive us
Thanks, Andrew, Laurie, Laszlo, Jaben, for quick help!! :)
Regards,
Keshava
On Tue 27 Sep, 2016 10:18 pm Andrew Fish, wrote:
> I was kind of surprised that an example like this did not exist in:
> https://github.com/tianocore/edk2/tree/master/ShellPkg/Application
>
> Thanks,
>
> Andrew Fish
>
>
I was kind of surprised that an example like this did not exist in:
https://github.com/tianocore/edk2/tree/master/ShellPkg/Application
Thanks,
Andrew Fish
> On Sep 27, 2016, at 9:44 AM, Jarlstrom, Laurie
> wrote:
>
> Keshava,
> Attached Sample code is an example that will open a file name p
> On Sep 27, 2016, at 9:03 AM, Cohen, Eugene wrote:
>
>> Printing UINTN with %x *or* with %d are equally bugs.
>>
>> For X64 / AARCH64 / IA64 builds, they are actual bugs (that happen to
>> work most of the time).
>
> Feel free to file a Bugzilla on the extensive usage of this in edk2 [ducking
Keshava,
Attached Sample code is an example that will open a file name passed through
the command line using the Shell.
thanks,
Laurie
laurie.jarlst...@intel.com
Intel SSG/STO/EBP
(503) 712-9395
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
On 09/27/16 18:03, Cohen, Eugene wrote:
>> Printing UINTN with %x *or* with %d are equally bugs.
>>
>> For X64 / AARCH64 / IA64 builds, they are actual bugs (that happen to
>> work most of the time).
>
> Feel free to file a Bugzilla on the extensive usage of this in edk2 [ducking
> and running].
> Printing UINTN with %x *or* with %d are equally bugs.
>
> For X64 / AARCH64 / IA64 builds, they are actual bugs (that happen to
> work most of the time).
Feel free to file a Bugzilla on the extensive usage of this in edk2 [ducking
and running]. :)
> > I'm envisioning having to create a slid
On 09/27/16 17:07, Carsey, Jaben wrote:
> Apparently all the good threads happen at night for me...
The blessings of a distributed team! ;)
> Kesheva,
>
> There are a few functions in the ShellLib that call into the UEFI Shell
> binary to help you. Some of these are duplicates of what others su
Apparently all the good threads happen at night for me...
Kesheva,
There are a few functions in the ShellLib that call into the UEFI Shell binary
to help you. Some of these are duplicates of what others suggested, but I
figured I would elaborate.
ShellOpenFileMetaArg - open a file or group of
On 09/27/16 14:29, Cohen, Eugene wrote:
> Laszlo,
>
>> I print INTN / UINTN values with:
>> - casting them unconditionally to INT64 / UINT64,
>> - printing the converted values with the matching conversion
>> specifiers,
>> such as %Ld (for INT64) and %Lu or %Lx (for UINT64).
>>
>> This solution
Laszlo,
> I print INTN / UINTN values with:
> - casting them unconditionally to INT64 / UINT64,
> - printing the converted values with the matching conversion
> specifiers,
> such as %Ld (for INT64) and %Lu or %Lx (for UINT64).
>
> This solution requires a bit more typing, and it is a bit pessim
Thank you Laszlo.
I'll check it out. :)
Thanks again.
Regards,
Keshava
On Tue, 27 Sep 2016 at 16:47 Laszlo Ersek wrote:
> On 09/27/16 12:46, GN Keshava wrote:
> > Hi Laszlo,
> >
> > Thank you for the answer. It was helpful.
> >
> > Considering option #1, can you give some more details (a small
On 09/27/16 12:46, GN Keshava wrote:
> Hi Laszlo,
>
> Thank you for the answer. It was helpful.
>
> Considering option #1, can you give some more details (a small example
> or any reference link would be helpful), how I can use Shell APIs in my
> C file (which will compile to my .efi app)?
Hmmm,
Hi Laszlo,
Thank you for the answer. It was helpful.
Considering option #1, can you give some more details (a small example or
any reference link would be helpful), how I can use Shell APIs in my C file
(which will compile to my .efi app)?
Considering option #2, How I can find device path program
Cc: Liming Gao
Cc: Eric Dong
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi
---
.../BootMaintenanceManagerUiLib/BootMaintenance.c | 206 ++---
.../Library/BootMaintenanceManagerUiLib/Variable.c | 28 ++-
2 files changed, 207 insertions(+), 27
On 09/27/16 11:25, GN Keshava wrote:
> Hi Laszlo,
>
> Thanks for the reply. I meant I have complete file path. I believe the
> "device path" is different. Is it possible to obtain DevicePath using my
> full file path?
The pathname you seem to have (as "complete") is specific to a given
simple FS,
Hi Andrew,
Thanks for the reply.
Can you tell more about (or some links) about the Shell APIs that you have
mentioned? Is it possible to access these from my C code? (not script, its
C code for my .efi app).
Also, can you give more idea about how I can map my volume name to device
path in my C f
Hi Laszlo,
Thanks for the reply. I meant I have complete file path. I believe the
"device path" is different. Is it possible to obtain DevicePath using my
full file path?
Thanks.
Regards,
Keshava
On Tue, 27 Sep 2016 at 14:46 Laszlo Ersek wrote:
> On 09/27/16 11:03, GN Keshava wrote:
> > Hi all
On 09/27/16 11:03, GN Keshava wrote:
> Hi all,
>
>
> I'm trying to open a file from my UEFI application. The path of file is
>
> fs1:/myfolder/myfile.txt
>
> The code :
>
> efiStatus = bs->LocateHandleBuffer(ByProtocol,
>&sfspGuid,
>
> On Sep 27, 2016, at 2:03 AM, GN Keshava wrote:
>
> Hi all,
>
>
> I'm trying to open a file from my UEFI application. The path of file is
>
> fs1:/myfolder/myfile.txt
>
Keshava,
The volume names are EFI Shell concepts, not UEFI Firmware concepts. Basically
the Shell uses "fs1:" to match
Hi all,
I'm trying to open a file from my UEFI application. The path of file is
fs1:/myfolder/myfile.txt
The code :
efiStatus = bs->LocateHandleBuffer(ByProtocol,
&sfspGuid,
NULL,
&handleCo
Jiewen,
1. Could you move structure definitions (like
MICROCODE_FMP_LAST_ATTEMPT_VARIABLE, etc ) and function declarations reference
(like GetMicrocodeInfo, etc) from MicrocodeFmp.c to MicrocodeUpdate.h?
2. Correct EFI_D_ERROR to EFI_D_INFO on following DEBUG ().
DEBUG((EFI_D_ERROR, "Mi
Reviewed-by: Feng Tian
Thanks
Feng
-Original Message-
From: Ni, Ruiyu
Sent: Tuesday, September 27, 2016 3:42 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: [PATCH] MdeModulePkg/PciSioSerialDxe: Remove unused global variables
Contributed-under: TianoCore Contribution Agreement
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Feng Tian
---
MdeModulePkg/Bus/Pci/PciSioSerialDxe/ComponentName.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/PciSioSerialDxe/ComponentName.c
b/MdeModulePkg/Bus/
Yonghong:
This is my mistake. I use the wrong way to apply for this patch. With the
correct way, those patches can work well.
Reviewed-by: Liming Gao
Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Gao, Liming
> Sent: Mon
33 matches
Mail list logo
