Re: [edk2] Data Structure alignment

[Tim Lewis]

I believe the option ROM header itself has an alignment requirement greater
than a DWORD. This is true whether it is from the option ROM BAR or whether
it is copied into allocated memory via AllocatePool. In this case, the check
you showed will still be adequate. But I am going from memory.

Thanks,
Tim

-Original Message-
From: edk2-devel  On Behalf Of TVKR
Sent: Thursday, March 14, 2019 1:47 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Data Structure alignment

Hi,
The PCI FW spec says PCI Data Structure must be DWORD aligned and I came
across this code the uses the following check

(RomHeader->PcirOffset & 3) != 0

The above is using the PcirOffset to do the check and not the actual data
structure itself (located at RomHeader + RomHeader->PcirOffset) Shouldn't it
instead be

(RomHeader + RomHeader->PcirOffset & 3) != 0

Thanks
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment variable

[Tim Lewis]

Jaben --

Following on this: shouldn't this be a spec issue? If you are asking people
to depend on the behavior.

Thanks,
Tim

-Original Message-
From: edk2-devel  On Behalf Of Laszlo Ersek
Sent: Friday, October 5, 2018 4:33 AM
To: Carsey, Jaben ; Andrew Fish 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment
variable

On 10/04/18 22:54, Carsey, Jaben wrote:
> Laszlo,
> 
> The leading "_" was required for out of spec, but built in, commands.  The
spec has no restrictions on environment variables except some have special
meaning and may be read only.
> 
> I can certainly work on slowing down the process.  I have been complaining
about that same thing and should have been more aware.  I would like to have
a community minimum amount of time before commits are done that we all agree
to.  Something like 1 full day would be nice I think.

Good idea! I believe 24 hours should be tolerable on all ends. It also gives
a chance to people in other time zones to comment.

I think there should be one exception: grave regressions -- build failures,
or total boot failures -- should be possible to revert (or
fix) as soon as there's one review.

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] FFS Alignment and the FDF Specification

[Tim Lewis]

1.28. 

2.5.6 says: Alignment - Data (value is one of: 1, 2 4, 8, 16, 32, 64 128,
512, 1K, 2K, 4K, 8K, 16K,32K, 64K) byte aligned

The grammar 3.2.1 says:

 ::= {"Auto"} {"8"} {"16"} {"32"} {"64"} {"128"}{"512"}
{"1K"} {"4K"} {"32K"} {"64K"}

This is the version from the EDK2 specs page.

-Original Message-
From: edk2-devel  On Behalf Of Zhu,
Yonghong
Sent: Thursday, July 26, 2018 5:59 PM
To: Tim Lewis ; edk2-devel@lists.01.org
Subject: Re: [edk2] FFS Alignment and the FDF Specification

Which version of FDF spec you use now ? I remember current we already
support 16M ffs alignment.  FDF spec Version 1.28 have such info "Per PI 1.6
to extend FFS alignment to 16M".

Best Regards,
Zhu Yonghong

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim
Lewis
Sent: Friday, July 27, 2018 8:55 AM
To: edk2-devel@lists.01.org
Subject: [edk2] FFS Alignment and the FDF Specification

Is my understanding correct: the FDF specification only supports a maximum
of 64KB alignment for files (section 2.5.6), but the PI specification
supports (table 7), up to 16MB alignment. Or am I misreading it?

Thanks,

Tim

-Original Message-
From: edk2-devel  On Behalf Of Andrew Fish
Sent: Thursday, July 19, 2018 11:26 AM
To: Marvin H?user 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Help on AutoGen Files

Udit,

As Marvin points out the [LibraryClasses] section of the INF file are going
to imply the order of the library constructor calls in the AutoGen

Worst case you can demote FpgaInterfaceInit () from being a constructor to
just being a public library function that the other lib can call explicitly
from its constructor. Maybe that is too drastic and you could must move a
function out of FpgaInterfaceInit () and make that function part of the
Public library interface?

Thanks,

Andrew Fish

> On Jul 19, 2018, at 11:14 AM, Marvin H?user 
> 
wrote:
> 
> Hey Udit,
> 
> You cannot explicitly influence the order of the calls, but implicitly 
> via
the dependency tree, which means you need to make SerialPortLib depend on
your LibraryClass instance.
> You did not mention which SerialPortLib instance you use, but probably 
> you
need to execute FpgaInterfaceInit() earlier in platform code or fork
SerialPortLib for now.
> 
> Regards,
> Marvin
> 
>> -Original Message-
>> From: edk2-devel  On Behalf Of Udit 
>> Kumar
>> Sent: Thursday, July 19, 2018 9:33 AM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] Help on AutoGen Files
>> 
>> Hi Experts,
>> How I can change the order of initialization in Constructor list of
autogen file.
>> In my build system, if I look at
>> MdeModulePkg/Universal/PCD/Pei/Pcd/DEBUG/AutoGen.c
>> Below is function of Library Constructor List
>> 
>> VOID
>> EFIAPI
>> ProcessLibraryConstructorList (
>>  IN   EFI_PEI_FILE_HANDLE   FileHandle,
>>  IN CONST EFI_PEI_SERVICES  **PeiServices
>>  )
>> {
>>  EFI_STATUS  Status;
>> 
>>  Status = BaseDebugLibSerialPortConstructor ();  ASSERT_EFI_ERROR 
>> (Status);
>> 
>>  Status = PeiServicesTablePointerLibConstructor (FileHandle, 
>> PeiServices);  ASSERT_EFI_ERROR (Status);
>> 
>>  Status = TimerConstructor ();
>>  ASSERT_EFI_ERROR (Status);
>> 
>>  Status = FpgaInterfaceInit ();
>>  ASSERT_EFI_ERROR (Status);
>> 
>> }
>> 
>> 
>> My problem is SerialPortConstructor needs frequency, which can be 
>> retrieved after  FpgaInterfaceInit() Therefore, my preferred way for 
>> this constructor list will be
>> FpgaInterfaceInit() followed by  BaseDebugLibSerialPortConstructor()
>> 
>> how I can achieve this.
>> 
>> 
>> Many Thanks
>> Udit
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] FFS Alignment and the FDF Specification

[Tim Lewis]

Is my understanding correct: the FDF specification only supports a maximum
of 64KB alignment for files (section 2.5.6), but the PI specification
supports (table 7), up to 16MB alignment. Or am I misreading it?

Thanks,

Tim

-Original Message-
From: edk2-devel  On Behalf Of Andrew Fish
Sent: Thursday, July 19, 2018 11:26 AM
To: Marvin H?user 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Help on AutoGen Files

Udit,

As Marvin points out the [LibraryClasses] section of the INF file are going
to imply the order of the library constructor calls in the AutoGen

Worst case you can demote FpgaInterfaceInit () from being a constructor to
just being a public library function that the other lib can call explicitly
from its constructor. Maybe that is too drastic and you could must move a
function out of FpgaInterfaceInit () and make that function part of the
Public library interface?

Thanks,

Andrew Fish

> On Jul 19, 2018, at 11:14 AM, Marvin H?user 
wrote:
> 
> Hey Udit,
> 
> You cannot explicitly influence the order of the calls, but implicitly via
the dependency tree, which means you need to make SerialPortLib depend on
your LibraryClass instance.
> You did not mention which SerialPortLib instance you use, but probably you
need to execute FpgaInterfaceInit() earlier in platform code or fork
SerialPortLib for now.
> 
> Regards,
> Marvin
> 
>> -Original Message-
>> From: edk2-devel  On Behalf Of Udit 
>> Kumar
>> Sent: Thursday, July 19, 2018 9:33 AM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] Help on AutoGen Files
>> 
>> Hi Experts,
>> How I can change the order of initialization in Constructor list of
autogen file.
>> In my build system, if I look at
>> MdeModulePkg/Universal/PCD/Pei/Pcd/DEBUG/AutoGen.c
>> Below is function of Library Constructor List
>> 
>> VOID
>> EFIAPI
>> ProcessLibraryConstructorList (
>>  IN   EFI_PEI_FILE_HANDLE   FileHandle,
>>  IN CONST EFI_PEI_SERVICES  **PeiServices
>>  )
>> {
>>  EFI_STATUS  Status;
>> 
>>  Status = BaseDebugLibSerialPortConstructor ();  ASSERT_EFI_ERROR 
>> (Status);
>> 
>>  Status = PeiServicesTablePointerLibConstructor (FileHandle, 
>> PeiServices);  ASSERT_EFI_ERROR (Status);
>> 
>>  Status = TimerConstructor ();
>>  ASSERT_EFI_ERROR (Status);
>> 
>>  Status = FpgaInterfaceInit ();
>>  ASSERT_EFI_ERROR (Status);
>> 
>> }
>> 
>> 
>> My problem is SerialPortConstructor needs frequency, which can be 
>> retrieved after  FpgaInterfaceInit() Therefore, my preferred way for 
>> this constructor list will be
>> FpgaInterfaceInit() followed by  BaseDebugLibSerialPortConstructor()
>> 
>> how I can achieve this.
>> 
>> 
>> Many Thanks
>> Udit
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Does __attribute__ ((selectany)) make sense now for GCC?

[Tim Lewis]

Andrew -

 

I know for Visual Studio it does the same thing for data that /Gy does for
code.

 

That is, if the data is unreferenced, then it doesn't get brought it.

 

Maybe link-time code generation has the same effect. That's what I'm curious
about. 

 

Tim

 

From: af...@apple.com <af...@apple.com> 
Sent: Friday, May 18, 2018 3:39 PM
To: Tim Lewis <tim.le...@insyde.com>
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Does __attribute__ ((selectany)) make sense now for GCC?

 

Tim,

 

Looks like that is only available on Windows versions of GCC, and is more
about compatible behavior. 

 

selectany

The selectany attribute causes an initialized global variable to have
link-once semantics. When multiple definitions of the variable are
encountered by the linker, the first is selected and the remainder are
discarded. Following usage by the Microsoft compiler, the linker is told not
to warn about size or content differences of the multiple definitions.

Although the primary usage of this attribute is for POD types, the attribute
can also be applied to global C++ objects that are initialized by a
constructor. In this case, the static initialization and destruction code
for the object is emitted in each translation defining the object, but the
calls to the constructor and destructor are protected by a link-once guard
variable.

The selectany attribute is only available on Microsoft Windows targets. You
can use __declspec (selectany) as a synonym for __attribute__ ((selectany))
for compatibility with other compilers.

 

What I've noticed with clang/LLVM is the unreferenced globals get removed
when you enable link time optimizations. 

 

I'd actually ask the opposite question. Does __declspec(selectany) impact
dead code removal on current versions of VC++? 

 

Thanks,

 

Andrew Fish





On May 18, 2018, at 3:22 PM, Tim Lewis <tim.le...@insyde.com
<mailto:tim.le...@insyde.com> > wrote:

 

In Visual Studio we have __declspec(selectany) to limit the impact of unused
data.



I see that GCC for Windows has __attribute__ ((selectany)).



Should we me using this for GLOBAL_REMOVE_IF_UNREFERENCED in
MdePkg\Include\Base.h?



Tim

___
edk2-devel mailing list
 <mailto:edk2-devel@lists.01.org> edk2-devel@lists.01.org
 <https://lists.01.org/mailman/listinfo/edk2-devel>
https://lists.01.org/mailman/listinfo/edk2-devel

 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Does __attribute__ ((selectany)) make sense now for GCC?

[Tim Lewis]

In Visual Studio we have __declspec(selectany) to limit the impact of unused
data.

 

I see that GCC for Windows has __attribute__ ((selectany)).

 

Should we me using this for GLOBAL_REMOVE_IF_UNREFERENCED in
MdePkg\Include\Base.h?

 

Tim

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Query regarding hole in EFI Memory Map

[Tim Lewis]

And now you see it again with 64-bit machines, where the flash and PCI
config space (and MMIO) appear below 4GB, but there is DRAM above and below
4GB. 

Tim

-Original Message-
From: edk2-devel  On Behalf Of Bill Paul
Sent: Monday, May 14, 2018 6:13 PM
To: edk2-devel@lists.01.org
Cc: Neri, Ricardo 
Subject: Re: [edk2] Query regarding hole in EFI Memory Map

Of all the gin joints in all the towns in all the world, Prakhya, Sai
Praneeth had to walk into mine at 16:30 on Monday 14 May 2018 and say:

> Hi All,
> 
> Recently, I have observed that there was a hole in EFI Memory Map 
> passed by firmware to Linux kernel. So, wanted to check with you if 
> this is expected or not.
> 
> My Test setup:
> I usually boot qemu with OVMF and Linux kernel. I use below command to 
> boot kernel. "qemu-system-x86_64 -cpu host -hda  -serial 
> stdio -bios  -m 2G -enable-kvm -smp 2"
> 
> I have noticed that the EFI Memory Map (printed by kernel) is almost 
> contiguous but with only one hole ranging from 0xA to 0x10. As 
> far as I know, kernel hasn't modified this EFI Memory Map, so I am 
> assuming that firmware has passed memory map with a hole. I have 
> looked at UEFI spec "GetMemoryMap()" definition, and it says "The map 
> describes all of memory, no matter how it is being used". So, I am 
> thinking that EFI Memory Map shouldn't have any holes, am I correct? 
> If not, could someone please explain me the reason for this hole in EFI
Memory Map.

The map may describe all of physical RAM, however it is not necessarily the
case that all available RAM be physically contiguous.

With older IBM PCs based on the Intel 8088 processor, you could only have a
1MB address space. The first 640KB was available for RAM. The remaining
space traditionally contained memory-mapped option ROMs, particularly for
things like the video BIOS routines. The VGA text screen was also mapped to
0xB8000.

Obviously, later processors made it possible to have additional memory above
1MB (sometimes called "high memory"), but for backward compatibility
purposes, the gap from 0xA to 0xF remained.

So basically, on Intel machines you will always see this gap in RAM due to
"hysterical raisins." It's just an artifact of the platform design. (And for
that reason you'll see it both with the UEFI memory map facility and the
legacy E820 BIOS facility).

-Bill


> 
> 
> Please let me know if you want me to post the EFI Memory Map or E820 
> map that I am looking at.
> 
> Note: I have also observed the same hole in E820 map.
> 
> 
> 
> Regards,
> 
> Sai
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
--

=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River
Systems

=
   "I put a dollar in a change machine. Nothing changed." - George Carlin

=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

[Tim Lewis]

Marvin -

My suggestion would be the same as yours: to generate a runtime error.

Tim

-Original Message-
From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Marvin
Häuser
Sent: Wednesday, May 9, 2018 1:45 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen <jiewen@intel.com>; Tim Lewis <tim.le...@insyde.com>
Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

Hey Tim,

The compiler has no information regarding the size of the stack and hence
cannot determine an overflow.
This is basically a warning that stack of a single function is big enough to
reach past the Guard Page and ensures it will be accessed.

Yao,

I just realized there already is Stack protection code in edk2, I was only
aware of Heap protection.
Wouldn't a proper implementation make sense now to maybe not expand the
stack, but at least runtime-error?

Regards,
Marvin

> -Original Message-----
> From: Tim Lewis <tim.le...@insyde.com>
> Sent: Wednesday, May 9, 2018 3:28 AM
> To: 'Yao, Jiewen' <jiewen@intel.com>; marvin.haeu...@outlook.com; 
> edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> I think that this is a fatal error in EDK2. It basically says, "we are 
> out of stack space." The alternative is: the system hangs in an 
> unexpected way since the stack overflows into other pages.
> 
> Tim
> 
> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Yao, 
> Jiewen
> Sent: Tuesday, May 8, 2018 5:25 PM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> We discussed internally in Intel.
> 
> The quick workaround is: use /Gs65536. :-)
> 
> At the same time, our recommendation is to revisit the code which 
> triggers this error. Why this function need such a big stack? And try 
> to reduce the local stack usage.
> 
> What is why we still use /Gs32768 as default, instead of /Gs65536.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Marvin H?user
> > Sent: Tuesday, May 8, 2018 5:21 PM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>
> > Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include 
> > ChkStk.c
> >
> > Oh, if you are prefering a good implementation, I will be all for 
> > that. This was just a 'quick workaround', same as currently done for
GCC.
> > I'm actually unsure whether a good implementation is possible with a 
> > flat memory model. It will likely be mere luck whether there is 
> > enough space free below the stack, except for maybe when it's 
> > located very high (preferably past the 32-bit space).
> > Has there been any prior discussion on this topic? Would be 
> > interested to follow up if there was.
> >
> > Thanks,
> > Marvin
> >
> > > -Original Message-
> > > From: Yao, Jiewen <jiewen@intel.com>
> > > Sent: Wednesday, May 9, 2018 2:13 AM
> > > To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> > > Cc: Gao, Liming <liming@intel.com>
> > > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > >
> > > There are some open source implementation:
> > > MSVC: https://github.com/ispc/ispc/issues/542
> > > GCC:
> > >
> https://android.googlesource.com/toolchain/gcc/+/b094d6c4bf572654a03
> > > 1e cc4afe675154c886dc5/gcc-4.4.3/gcc/config/i386/chkstk.asm
> > >
> > > The compiler generated code assumes the stack is enlarged after we 
> > > can chkstk.
> > >
> > > I agree empty function can make build pass.
> > > But more important, we need make it work if there is a need to 
> > > increase the stack.
> > > The potential issue is that the later code (after chkstk) assumes 
> > > the stack is increased, but actually it is not.
> > >
> > > That is why I ask how this is validated.
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > >
> > > > -Original Message-
> > > > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > > > Sent: Tuesday, May 8, 2018 4:58 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Yao, Jiewen <jiewen@intel.com>; Gao, Liming 
> > > > <liming@intel.com>
> > > > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > > >
> > > > Hey Yao,
> &g

Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

[Tim Lewis]

I think that this is a fatal error in EDK2. It basically says, "we are out
of stack space." The alternative is: the system hangs in an unexpected way
since the stack overflows into other pages.

Tim

-Original Message-
From: edk2-devel  On Behalf Of Yao, Jiewen
Sent: Tuesday, May 8, 2018 5:25 PM
To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

We discussed internally in Intel.

The quick workaround is: use /Gs65536. :-)

At the same time, our recommendation is to revisit the code which triggers
this error. Why this function need such a big stack? And try to reduce the
local stack usage.

What is why we still use /Gs32768 as default, instead of /Gs65536.

Thank you
Yao Jiewen


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Marvin H?user
> Sent: Tuesday, May 8, 2018 5:21 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> Oh, if you are prefering a good implementation, I will be all for 
> that. This was just a 'quick workaround', same as currently done for GCC.
> I'm actually unsure whether a good implementation is possible with a 
> flat memory model. It will likely be mere luck whether there is enough 
> space free below the stack, except for maybe when it's located very 
> high (preferably past the 32-bit space).
> Has there been any prior discussion on this topic? Would be interested 
> to follow up if there was.
> 
> Thanks,
> Marvin
> 
> > -Original Message-
> > From: Yao, Jiewen 
> > Sent: Wednesday, May 9, 2018 2:13 AM
> > To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> > Cc: Gao, Liming 
> > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> >
> > There are some open source implementation:
> > MSVC: https://github.com/ispc/ispc/issues/542
> > GCC:
> > https://android.googlesource.com/toolchain/gcc/+/b094d6c4bf572654a03
> > 1e cc4afe675154c886dc5/gcc-4.4.3/gcc/config/i386/chkstk.asm
> >
> > The compiler generated code assumes the stack is enlarged after we 
> > can chkstk.
> >
> > I agree empty function can make build pass.
> > But more important, we need make it work if there is a need to 
> > increase the stack.
> > The potential issue is that the later code (after chkstk) assumes 
> > the stack is increased, but actually it is not.
> >
> > That is why I ask how this is validated.
> >
> > Thank you
> > Yao Jiewen
> >
> >
> > > -Original Message-
> > > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > > Sent: Tuesday, May 8, 2018 4:58 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Yao, Jiewen ; Gao, Liming 
> > > 
> > > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > >
> > > Hey Yao,
> > >
> > > As far as I am aware, all __chkstk does is access the stack in 4 
> > > KB intervals from the current location to the maximum requested 
> > > location to eventually hit the Windows Guard Page, which then 
> > > triggers the stack
> > increase.
> > > Because I do not know of any equivalent concept in edk2 and the 
> > > intrinsic was already disabled for GCC, I supposed it was a good 
> > > idea to do so globally. Are the potential issues I am not aware of?
> > >
> > > Thanks,
> > > Marvin.
> > >
> > > > -Original Message-
> > > > From: Yao, Jiewen 
> > > > Sent: Wednesday, May 9, 2018 1:52 AM
> > > > To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> > > > Cc: Gao, Liming 
> > > > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > > >
> > > > HI Marvin
> > > > Would you mind to share the information on how you test this update?
> > > >
> > > >
> > > > Per my experience, chkstk not only does the check but also does 
> > > > the real work to allocate more stack.
> > > >
> > > > /Gs can be used to indicate the size (/Gs[num] control stack 
> > > > checking calls)
> > > >
> > > > We use /Gs32768 by default, see tools_def.txt.
> > > >
> > > > Usually, we just increase this value to override the default 
> > > > one, if we hit this issue.
> > > >
> > > > Thank you
> > > > Yao Jiewen
> > > >
> > > > > -Original Message-
> > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On 
> > > > > Behalf Of Marvin H?user
> > > > > Sent: Tuesday, May 8, 2018 4:37 PM
> > > > > To: edk2-devel@lists.01.org
> > > > > Cc: Gao, Liming 
> > > > > Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include 
> > > > > ChkStk.c
> > > > >
> > > > > Hey Liming,
> > > > >
> > > > > According to the MSDN documentation, the call will be inserted 
> > > > > for a stack usage past a defined threshold - 4 KB for IA32, 8 
> > > > > KB for X64
> > (source:
> > > > > 

Re: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when enter/exit setup menu

[Tim Lewis]

If we start to see UEFI drivers that are using this, then it is a spec
issue, because it means that systems which do not implement the event will
not function correctly.

Tim

-Original Message-
From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Bi, Dandan
Sent: Wednesday, April 11, 2018 9:53 PM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>; Dong, Eric <eric.d...@intel.com>; Gao,
Liming <liming@intel.com>
Subject: Re: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when
enter/exit setup menu

There is no need to update UEFI spec, just implementation related. It has no
impact to the modules which do not care these two events.

Thanks,
Dandan

-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Thursday, April 12, 2018 11:49 AM
To: Bi, Dandan <dandan...@intel.com>; Kinney, Michael D
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when
enter/exit setup menu

This is starting to sound like something that requires a UEFI spec update.
Tim

-Original Message-
From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Bi, Dandan
Sent: Wednesday, April 11, 2018 8:47 PM
To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>; Dong, Eric <eric.d...@intel.com>; Gao,
Liming <liming@intel.com>
Subject: Re: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when
enter/exit setup menu

Hi all,

All setup menu enter/exit cases includes:
a.  UiApp entry point is called and then setup menu is shown
(enter setup menu) 
b.  User select Continue menu in setup menu to exit.
(exit setup menu)
c.  User select Reset menu in setup page to leave exit.
(exit setup menu)
d.  User boot from file to exit setup page.
(exit setup menu)
e.  Exit from boot from file and return to UiApp.
(enter setup menu)
f.  User boot from boot manager to exit setup page.
(exit setup menu)
g.Exit the boot option in boot manager and return to UiApp.
(enter setup menu)

I didn't describe it in details in the commit messages.  I am sorry that if
it make you confused.
I will add them in the commit messages of V2 patches.


Thanks,
Dandan

-Original Message-
From: Bi, Dandan
Sent: Thursday, April 12, 2018 11:17 AM
To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>;
Bi, Dandan <dandan...@intel.com>
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when
enter/exit setup menu

Hi Mike,

We can't move the enter/exit event signaling into the FormBrowwer SendForm()
function.

Because we can't decide whether enter/exit setup through SendForm() is
called or not.  Some examples:

1. SendForm() is not called when exit setup menu and re-enter setup menu.
Such as, SendForm() is only called when enter front page firstly. But when
go to Boot Manager menu to select an option to boot and exit setup menu,
then exit the option and return to setup menu, SendForm() is not called in
this case.

2. SendForm () may be also called more than one time even if we don't  leave
setup menu. Such as, if we want to add an boot option in setup menu, when
choose file to add boot option, SendForm() will be called to show files. But
we don't  think we leave setup menu in this case.

So if we signal setup enter/exit event in SendForm(), may cause less/more
notifications. Which is not a correct behavior.


Thanks,
Dandan

-Original Message-
From: Kinney, Michael D
Sent: Thursday, April 12, 2018 9:44 AM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org; Kinney,
Michael D <michael.d.kin...@intel.com>
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when
enter/exit setup menu

Dandan Bi,

Is it possible to move the enter/exit event signaling into the FormBrowwer
SendForm() function?  The current patch set adds these signal calls in all
the places that
SendForm() is called and if one of these is missed, a notification will be
missed.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Dandan Bi
> Sent: Wednesday, April 11, 2018 6:32 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming 
> <liming@intel.com>
> Subject: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
> enter/exit setup menu
> 
> These changes are to support notify callbacks when enter/exit setup 
> menu, since some 

Re: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when enter/exit setup menu

[Tim Lewis]

This is starting to sound like something that requires a UEFI spec update.
Tim

-Original Message-
From: edk2-devel  On Behalf Of Bi, Dandan
Sent: Wednesday, April 11, 2018 8:47 PM
To: Kinney, Michael D ; edk2-devel@lists.01.org
Cc: Bi, Dandan ; Dong, Eric ; Gao,
Liming 
Subject: Re: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when
enter/exit setup menu

Hi all,

All setup menu enter/exit cases includes:
a.  UiApp entry point is called and then setup menu is shown
(enter setup menu) 
b.  User select Continue menu in setup menu to exit.
(exit setup menu)
c.  User select Reset menu in setup page to leave exit.
(exit setup menu)
d.  User boot from file to exit setup page.
(exit setup menu)
e.  Exit from boot from file and return to UiApp.
(enter setup menu)
f.  User boot from boot manager to exit setup page.
(exit setup menu)
g.Exit the boot option in boot manager and return to UiApp.
(enter setup menu)

I didn't describe it in details in the commit messages.  I am sorry that if
it make you confused.
I will add them in the commit messages of V2 patches.


Thanks,
Dandan

-Original Message-
From: Bi, Dandan
Sent: Thursday, April 12, 2018 11:17 AM
To: Kinney, Michael D ; edk2-devel@lists.01.org
Cc: Dong, Eric ; Gao, Liming ;
Bi, Dandan 
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when
enter/exit setup menu

Hi Mike,

We can't move the enter/exit event signaling into the FormBrowwer SendForm()
function.

Because we can't decide whether enter/exit setup through SendForm() is
called or not.  Some examples:

1. SendForm() is not called when exit setup menu and re-enter setup menu.
Such as, SendForm() is only called when enter front page firstly. But when
go to Boot Manager menu to select an option to boot and exit setup menu,
then exit the option and return to setup menu, SendForm() is not called in
this case.

2. SendForm () may be also called more than one time even if we don't  leave
setup menu. Such as, if we want to add an boot option in setup menu, when
choose file to add boot option, SendForm() will be called to show files. But
we don't  think we leave setup menu in this case.

So if we signal setup enter/exit event in SendForm(), may cause less/more
notifications. Which is not a correct behavior.


Thanks,
Dandan

-Original Message-
From: Kinney, Michael D
Sent: Thursday, April 12, 2018 9:44 AM
To: Bi, Dandan ; edk2-devel@lists.01.org; Kinney,
Michael D 
Cc: Dong, Eric ; Gao, Liming 
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when
enter/exit setup menu

Dandan Bi,

Is it possible to move the enter/exit event signaling into the FormBrowwer
SendForm() function?  The current patch set adds these signal calls in all
the places that
SendForm() is called and if one of these is missed, a notification will be
missed.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Dandan Bi
> Sent: Wednesday, April 11, 2018 6:32 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric ; Gao, Liming 
> 
> Subject: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
> enter/exit setup menu
> 
> These changes are to support notify callbacks when enter/exit setup 
> menu, since some driver may need to hook setup enter/exit points to do 
> something.
> 
> We will signal setup enter/exit events for all setup menu enter/exit 
> cases.Then the module which pay attention to these events can execute 
> the callback.
> 
> Cc: Eric Dong 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> 
> Dandan Bi (3):
>   MdeModulePkg/UiApp: Signal event when enter/exit setup menu
>   MdeModulePkg/BMMUiLib: Signal event when enter/exit setup menu
>   MdeModulePkg/BMUiLib: Signal event when enter/exit setup menu
> 
>  MdeModulePkg/Application/UiApp/FrontPage.c
> | 4 +++-
> 
> MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupp
> ort.c | 3 ++-
>  MdeModulePkg/Application/UiApp/UiApp.inf
> | 4 +++-
> 
> .../BootMaintenanceManagerUiLib/BootMaintenanceManagerUi
> Lib.inf   | 4 +++-
> 
> MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOpt
> ion.c | 8 +++-
>  MdeModulePkg/Library/BootManagerUiLib/BootManager.c
> | 7 ++-
> 
> MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.i
> nf| 4 +++-
>  MdeModulePkg/MdeModulePkg.dec
> | 6 ++
>  8 files changed, 33 insertions(+), 7 deletions(-)
> 
> --
> 2.14.3.windows.1
> 
> ___
> edk2-devel mailing list
> 

Re: [edk2] RFC: Proposal to halt automatic builds of Windows BaseTools executables

[Tim Lewis]

Laszlo, Erik --

I understand this dislike from some open source developers. I respect that and 
am glad that EDK2 provides a way to accommodate this preference. But "most" is 
a strong term. I would venture to say that a good number (and probably the 
majority) of the people using EDK2-derived code and tools are fine with the 
current situation.

The only reason I would have Python on most of my company's dev systems would 
be for EDK2. Since (a) the current system is working and (b) since the 
possibility for rebuild is available for those who want it, it doesn't weigh 
heavily enough IMO to change the current situation. 

Regards,

Tim

-Original Message-
From: Laszlo Ersek <ler...@redhat.com> 
Sent: Thursday, March 8, 2018 1:19 PM
To: Tim Lewis <tim.le...@insyde.com>; 'Bjorge, Erik C' 
<erik.c.bjo...@intel.com>; edk2-devel@lists.01.org
Subject: Re: [edk2] RFC: Proposal to halt automatic builds of Windows BaseTools 
executables

On 03/08/18 19:05, Tim Lewis wrote:
> Erik --
> 
> What is the justification? Moving from more immediately usable to less 
> immediately usable doesn't seem, on the surface, to be  a good direction.
> Why not go the other direction and pre-build the binaries for the 
> other environments?

I'd just like to offer one data point for the last question: most open source 
developers *really* dislike running any native binaries that were built by 
neither (a) themselves nor (b) the provider of their OS distribution.

To give you an example for (b), Fedora provides the "edk2-tools" package (built 
from the "edk2" source package), and "edk2-tools" definitely installs native 
binaries:

https://koji.fedoraproject.org/koji/rpminfo?rpmID=13354362

The difference is that these binaries were built in a build environment that 
matches the rest of Fedora [*] and is generally trusted by Fedora users.

[*] For example, binaries could be instrumented for security purposes 
system-wide; some buffer overflows in a native (C) application could be caught 
automatically as a result.

Thanks,
Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] RFC: Proposal to halt automatic builds of Windows BaseTools executables

[Tim Lewis]

Erik --

What is the justification? Moving from more immediately usable to less
immediately usable doesn't seem, on the surface, to be  a good direction.
Why not go the other direction and pre-build the binaries for the other
environments?

Thanks,

Tim

-Original Message-
From: edk2-devel  On Behalf Of Bjorge, Erik
C
Sent: Wednesday, March 7, 2018 9:57 AM
To: edk2-devel@lists.01.org
Subject: [edk2] RFC: Proposal to halt automatic builds of Windows BaseTools
executables

I would like to propose that the automatic builds of Windows BaseTools
executables be halted.  This implies there will no longer be updates to the
edk2-BaseTools-win32 repository.

With this change, developers using Windows must install Python 2.7.x and
configure their environment to build C tools  and run python scripts from
sources.  This matches the development experience for non-Windows
environments.

Please respond with comments by 03/23/2018.

Thanks,
-Erik

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex.

[Tim Lewis]

Supreeth --

Doesn't Appendix A of the PI 1.6 define this as:

#define EFI_FV_FILETYPE_SMM EFI_FV_FILETYPE_MM
#define EFI_FV_FILETYPE_SMM_CORE EFI_FV_FILETYPE_MM_CORE

Thanks,

Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Supreeth Venkatesh
Sent: Thursday, January 25, 2018 9:45 AM
To: Marvin H?user ; edk2-devel@lists.01.org
Cc: michael.d.kin...@intel.com; liming@intel.com
Subject: Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV
file type and depex.

Marvin,

Thanks for your comments.
As per PI v1.6 specification,
EFI_FV_FILETYPE_MM_CORE value is 0x0D (MM Foundation that support MM
Traditional Mode.)

This is traditional MM mode, which ARM is not supporting at this point. We
are more interested in MM_CORE_STANDALONE mode.
However, I have no issues in adding this in the patch, but would prefer if
this is added when MM traditional mode is supported in ARM.

Further,
w.r.t defining *_SMM_* definitions via the *_MM_* definitions. I don't want
to break backwards compatibility with existing SMM traditional mode
implementations.
I will be happy to let folks who have migrated to _MM_ definitions from
_SMM_ definitions to send the patch across.

Thanks,
Supreeth

-Original Message-
From: Marvin H?user [mailto:marvin.haeu...@outlook.com]
Sent: Tuesday, January 23, 2018 6:34 PM
To: edk2-devel@lists.01.org
Cc: Supreeth Venkatesh ;
michael.d.kin...@intel.com; liming@intel.com
Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV
file type and depex.

Good day,

I noticed this patch lacks the definition of "EFI_FV_FILETYPE_MM_CORE"
(0x0C).
Furthermore, may I suggest changing the *_SMM_* definitions to be defined
via the *_MM_* definitions?

Best regards,
Marvin.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Supreeth Venkatesh
> Sent: Tuesday, January 23, 2018 9:03 PM
> To: edk2-devel@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV 
> file type and depex.
>
> As per PI specification v1.6,
> The following new file types are added:
> EFI_FV_FILETYPE_MM_STANDALONE
> EFI_FV_FILETYPE_MM_CORE_STANDALONE
>
> The following new section type is added:
> EFI_SECTION_MM_DEPEX
>
> This patch adds the management mode FV file type and depex.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> Reviewed-by: Jiewen Yao 
> ---
>  MdePkg/Include/Pi/PiFirmwareFile.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h
> b/MdePkg/Include/Pi/PiFirmwareFile.h
> index b982c9eda3..6086d1bb2f 100644
> --- a/MdePkg/Include/Pi/PiFirmwareFile.h
> +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
> @@ -72,9 +72,12 @@ typedef UINT8 EFI_FFS_FILE_STATE;  #define 
> EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER  0x08
>  #define EFI_FV_FILETYPE_APPLICATION   0x09
>  #define EFI_FV_FILETYPE_SMM   0x0A
> +#define EFI_FV_FILETYPE_MM0x0A
>  #define EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0B
>  #define EFI_FV_FILETYPE_COMBINED_SMM_DXE  0x0C
> +#define EFI_FV_FILETYPE_COMBINED_MM_DXE   0x0C
>  #define EFI_FV_FILETYPE_SMM_CORE  0x0D
> +#define EFI_FV_FILETYPE_MM_STANDALONE 0x0E
>  #define EFI_FV_FILETYPE_OEM_MIN   0xc0
>  #define EFI_FV_FILETYPE_OEM_MAX   0xdf
>  #define EFI_FV_FILETYPE_DEBUG_MIN 0xe0
> @@ -218,6 +221,7 @@ typedef UINT8 EFI_SECTION_TYPE;
>  #define EFI_SECTION_RAW   0x19
>  #define EFI_SECTION_PEI_DEPEX 0x1B
>  #define EFI_SECTION_SMM_DEPEX 0x1C
> +#define EFI_SECTION_MM_DEPEX  0x1C
>
>  ///
>  /// Common section header.
> --
> 2.14.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Build error in StdLib with VS 2015 compiler

[Tim Lewis]

Are you building C++ (.cpp)? Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Karunakar P
Sent: Wednesday, November 1, 2017 8:27 PM
To: 'edk2-devel@lists.01.org' 
Cc: 'Ye, Ting' ; 'Fu, Siyuan' ; 'Wu,
Jiaxin' 
Subject: Re: [edk2] Build error in StdLib with VS 2015 compiler

Any comment on this?

From: Karunakar P
Sent: Tuesday, October 31, 2017 3:18 PM
To: 'edk2-devel@lists.01.org'
Cc: 'Wu, Jiaxin'; 'Fu, Siyuan'; 'Ye, Ting'
Subject: Build error in StdLib with VS 2015 compiler

Hello All,

Facing an build error with Stdlib module when built with VS 2015 compiler.

e:\test\StdLib\Include\sys/EfiCdefs.h(357): error C2220: warning treated as
error - no 'object' file generated
e:\test\StdLib\Include\sys/EfiCdefs.h(357): warning C4117: macro name
'__STDC_HOSTED__' is reserved, '#define' ignored

below change resolving this error. Would you please review and provide
comments.

#ifndef __STDC_HOSTED__
#define __STDC_HOSTED__ 1
#endif


Thank You,
Karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Shell Non-conformity to the Spec

[Tim Lewis]

Ah, now I remember. It was about aliases and case sensitivity, not environment 
variables. Tim

Sent from my Windows 10 phone

From: Carsey, Jaben
Sent: Tuesday, October 24, 2017 1:11 PM
To: Tim Lewis; jim.dai...@dell.com; Ni, Ruiyu
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Shell Non-conformity to the Spec

I don't remember.  Is there a defect in the Bugzilla?

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Tuesday, October 24, 2017 12:14 PM
> To: Carsey, Jaben <jaben.car...@intel.com>; jim.dai...@dell.com; Ni, Ruiyu
> <ruiyu...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] Shell Non-conformity to the Spec
> Importance: High
> 
> Jaben --
> 
> Wasn't there are previous e-mail thread about this?
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Carsey, Jaben
> Sent: Tuesday, October 24, 2017 11:29 AM
> To: jim.dai...@dell.com; Ni, Ruiyu <ruiyu...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Shell Non-conformity to the Spec
> 
> Yes.
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > jim.dai...@dell.com
> > Sent: Tuesday, October 24, 2017 11:20 AM
> > To: Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu
> > <ruiyu...@intel.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: [edk2] Shell Non-conformity to the Spec
> > Importance: High
> >
> > The shell spec says that "Each environment variable has a
> > case-sensitive name ...".
> >
> > In the EfiShellSetEnv function of ShellProtocol.c a case-insensitive
> > compare is performed against the variable that is to be set to see if
> > it is one of the read-only variables.  That means one cannot set a
> > variable named, for example, CWD, even though "cwd" and "CWD" are two
> > different variable names according to the spec.
> >
> > Should this be changed to a case-sensitive comparison?
> >
> > Regards,
> > Jim
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Shell Non-conformity to the Spec

[Tim Lewis]

Jaben --

Wasn't there are previous e-mail thread about this?

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Carsey, Jaben
Sent: Tuesday, October 24, 2017 11:29 AM
To: jim.dai...@dell.com; Ni, Ruiyu 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Shell Non-conformity to the Spec

Yes.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> jim.dai...@dell.com
> Sent: Tuesday, October 24, 2017 11:20 AM
> To: Carsey, Jaben ; Ni, Ruiyu 
> 
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] Shell Non-conformity to the Spec
> Importance: High
> 
> The shell spec says that "Each environment variable has a 
> case-sensitive name ...".
> 
> In the EfiShellSetEnv function of ShellProtocol.c a case-insensitive 
> compare is performed against the variable that is to be set to see if 
> it is one of the read-only variables.  That means one cannot set a 
> variable named, for example, CWD, even though "cwd" and "CWD" are two 
> different variable names according to the spec.
> 
> Should this be changed to a case-sensitive comparison?
> 
> Regards,
> Jim
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green color

[Tim Lewis]

And we always turn off the multiple colors. Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Jarlstrom, Laurie
Sent: Monday, October 16, 2017 12:47 PM
To: Carsey, Jaben ; Ni, Ruiyu ; 
edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green 
color

The Idea of PCDs would be great.  I always change the UefiShellLib EFI_BLUE to 
EFI_CYAN to get a brighter blue.

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 Of Carsey, 
Jaben
Sent: Monday, October 16, 2017 9:32 AM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green 
color

Reviewed-by: Jaben Carsey 

We could also use some PCDs if different people really want different colors in 
the future...

> -Original Message-
> From: Ni, Ruiyu
> Sent: Monday, October 16, 2017 12:31 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben 
> Subject: [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green 
> color
> Importance: High
> 
> Some developers/QAs complain the color of directory or executable 
> files is hard to see and suggest to use a more bright color.
> I agree with this suggestion so make this patch.
> The look and feel is much better now.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jaben Carsey 
> ---
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index 64565f81d8..25d3e33533 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -2849,10 +2849,10 @@ InternalShellPrintWorker(
>  gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_WHITE, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
>  break;
>case (L'B'):
> -gST->ConOut->SetAttribute(gST->ConOut, EFI_TEXT_ATTR(EFI_BLUE,
> ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> +gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_LIGHTBLUE, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
>  break;
>case (L'V'):
> -gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_GREEN, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> +gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_LIGHTGREEN,
> ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
>  break;
>default:
>  //
> --
> 2.12.2.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] Implement NULL pointer detection feature

[Tim Lewis]

Just a +1 for 4 separate PCDs.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Johnson, 
Brian (EXL - Eagan)
Sent: Tuesday, August 29, 2017 10:12 AM
To: Kinney, Michael D ; Yao, Jiewen 
; Wang, Jian J ; 
edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/2] Implement NULL pointer detection feature

It makes no difference to me.  But it sounds more flexible and less cumbersome 
to use 4 PCDs.  That way you don't have to define the meanings of individual 
bits, in the code or in the .dec file.  And you could use different PCD types 
for the different PCDs, eg. FeatureFlag or FixedAtBuild for 
PcdNullPointerDetectionPei (since the GCDs are built at compile time, and it 
would take quite a bit of recoding to change that) but Dynamic for 
PcdNullPointerDetectionDxe, as Jiewen requested.

But I'm good either way.

Brian Johnson

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, August 29, 2017 11:02 AM
To: Johnson, Brian (EXL - Eagan) ; Yao, Jiewen 
; Wang, Jian J ; 
edk2-devel@lists.01.org; Kinney, Michael D 
Subject: RE: [edk2] [PATCH 0/2] Implement NULL pointer detection feature

Brian,

Do you prefer 4 new PCDs or one new PCD with a bitmask to enable detection in 
different phases?

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Johnson, Brian (EXL - Eagan)
> Sent: Tuesday, August 29, 2017 8:17 AM
> To: Yao, Jiewen ; Wang, Jian J 
> ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 0/2] Implement NULL pointer detection 
> feature
> 
> Thank you for implementing this feature!  It is very  helpful for 
> catching pointer-related problems.  We have used a similar scheme on 
> our systems for years, and caught several important bugs.  Some 
> comments:
> 
> * It's possible to implement similar protections in PEI (IA32) by 
> modifying the GDT descriptors.
> 
> * For flexibility, I'd like NULL pointer protection to be controlled 
> independently in PEI, DXE, and SMM, using separate PCDs.
> 
> * We have seen various option ROMs and OS boot loaders which have NULL 
> pointer issues, but are outside of our control.  It is useful to 
> enable NULL pointer protection during as much of the boot as possible, 
> but disable it before running these other executables.  So I'd suggest 
> adding another PCD, perhaps PcdNullPointerDetectionPostDxe, to control 
> NULL pointer protection late in boot.  If PcdNullPointerDetection != 
> PcdNullPointerDetectionPostDxe, install an end-of-DXE event
> (gEfiEndOfDxeEventGroupGuid) which changes the protection of page 0 
> using a call to EFI_CPU_ARCH_PROTOCOL.
> SetMemoryAttributes(CpuArch, 0, EFI_PAGE_SIZE, 0).
> 
> So ideally I'd like to have 4 PCDs:
> 
> PcdNullPointerDetectionPei
> PcdNullPointerDetectionDxe
> PcdNullPointerDetectionSmm
> PcdNullPointerDetectionPostDxe
> 
> Thanks,
> Brian Johnson
> HPE
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Yao, Jiewen
> Sent: Sunday, August 27, 2017 10:39 PM
> To: Wang, Jian J ; edk2- de...@lists.01.org
> Subject: Re: [edk2] [PATCH 0/2] Implement NULL pointer detection 
> feature
> 
> Comment in line.
> 
> From: Wang, Jian J
> Sent: Monday, August 28, 2017 11:24 AM
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH 0/2] Implement NULL pointer detection 
> feature
> 
> 
> 1)  I think this feature should be 'FALSE' by default. I
> forgot to reset its default value. This feature makes use of page 
> mechanism to detect NULL pointer. So any ARCH doesn't support paging 
> in EDK-II can't use it. Currently validated platform includes VLV2 and 
> Denlow. Let me know if all platform must be validated or not.
> 
> [Jiewen] Yes, I am OK to set to be FALSE to provide best 
> compatibility.
> I suggest we validate all open source IA platforms, such as Quark, and 
> OVMF with TRUE.
> 
> 
> 2)  It's hard to make it a dynamic feature because we need
> to setup page table for physical address 0-4095 in advance. If there's 
> no memory alloc/free action after enabling this feature, there's no 
> chance to make those change in page table.
> Then the usage of feature will be limited in such case.
> 
> [Jiewen] Dynamic means the initial value is dynamic. I am not saying 
> we need modify the page table.
> 
> An implementation could be:
> A platform can set this PCD in PEI phase based upon a setup variable 
> to choose CSM enable or disable.
> 
> The IPL sets page table based upon this PCD value. The DXE Core cannot 
> consume PCD directly, because it might be dynamic. But we can pass the 
> information from IPL via HOB. All the DXE 

Re: [edk2] Using NULL| style library linkable in EDK2

[Tim Lewis]

Mike --

Ok, I will enter it into Bugzilla later today.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney, 
Michael D
Sent: Thursday, July 20, 2017 10:57 AM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael 
D <michael.d.kin...@intel.com>
Subject: Re: [edk2] Using NULL| style library linkable in EDK2

Hi Tim,

You are correct.  The use of NULL lib class in [LibrrayClass] section appears 
to have been functional since at least 2010 when it was added to the 
BeagleBoardPkg.dsc file.

https://github.com/tianocore/edk2/commit/a957d4a7810e3bf1c95e9bb30d83271e407093a0

Though this specific use case is for intrinsic libs that need to be 
unconditionally linked to all ARM modules, the EDK II build feature is not 
limited to intrinsic libs.  I think an intrinsic lib is just a good example use 
of this feature.

Can you please enter a Bugzilla issue against the specs that have these 
incorrect statements?

Thanks,

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Thursday, July 20, 2017 9:30 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Using NULL| style library linkable in EDK2
> 
> Per the DSC specification (section 2.7), it is not legal to use a
> NULL| in the LIbraryClasses section.
> 
> The reserved library class keyword, NULL is not permitted in any of 
> the [LibraryClasses] sections. The NULL Library class keyword is only 
> permitted within the [Components] section's INF file subsection.
> However, it appears that this exact construct is not only used, but 
> required for Compiler Intrinsic libraries (such as used in the ARM 
> build in ArmPkg.dsc).
> 
> So I suggest that this line in the specification be modified to state 
> "Except for compiler intrinsic libraries, the..."
> 
> Thanks,
> 
> Tim Lewis
> CTO, Insyde Software
> www.insyde.com<http://www.insyde.com>
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Using NULL| style library linkable in EDK2

[Tim Lewis]

Per the DSC specification (section 2.7), it is not legal to use a NULL| in the 
LIbraryClasses section.

The reserved library class keyword, NULL is not permitted in any of the 
[LibraryClasses]
sections. The NULL Library class keyword is only permitted within the 
[Components] section's
INF file subsection.
However, it appears that this exact construct is not only used, but required 
for Compiler Intrinsic libraries (such as used in the ARM build in ArmPkg.dsc).

So I suggest that this line in the specification be modified to state "Except 
for compiler intrinsic libraries, the..."

Thanks,

Tim Lewis
CTO, Insyde Software
www.insyde.com<http://www.insyde.com>

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] PCD: Database size optimization for multi-SKU

[Tim Lewis]

Star-



One more requirement that I propose is the the format update be detectable 
easily by inspection of the binary image. We have tools that dump and 
manipulate the PCD database and the revision or version number allows us to 
support multiple core versions. I think this is already your intent and I want 
to make it an explicit requirement.



Other than that, I think this is a much needed change for multi-sku firmware 
images.



Thanks,

Tim



Sent from my Windows 10 phone



From: Star Zeng<mailto:star.z...@intel.com>
Sent: Tuesday, May 16, 2017 7:33 AM
To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Star Zeng<mailto:star.z...@intel.com>; Michael 
Kinney<mailto:michael.d.kin...@intel.com>; Liming 
Gao<mailto:liming@intel.com>; Tim Lewis<mailto:tim.le...@insyde.com>; 
Yonghong Zhu<mailto:yonghong@intel.com>
Subject: [RFC] PCD: Database size optimization for multi-SKU



- Requirement
Reduce PCD database size for multi-SKU case to save image size at build time 
and memory resource at boot time.


- Current limitation
When multiple SKUs are enabled, the full set of PCD values for all SKUs will be 
generated into PCD database,
and HOB will be created for the PCD database, the HOB will consume much memory 
resource when many SKUs are specified,
but the HOB length and pre-memory phase memory resource are limited.


- Proposal
BaseTools can generate the optimized PCD database to save the image size at 
build time,
the optimized PCD database layout will be like below, the PCD database will be 
composed of the full
default SKU data(PCD_DATABASE_INIT) and the non-default SKU delta 
data(PCD_DATABASE_SKU_DELTA).
PCD driver will build HOB to store the full default SKU data, and patch HOB 
data based on
non-default SKU delta data for the SKU set by SetSku(), it can save memory 
resource at boot time.

//
// PCD database layout:
// +-+
// | PCD_DATABASE_INIT (DEFAULT SKU) |
// +-+
// | PCD_DATABASE_SKU_DELTA (SKU A)  |
// +-+
// | PCD_DATABASE_SKU_DELTA (SKU B)  |
// +-+
// | ..  |
// +-+
//

The patch below shows the detailed PCD database format change.

BaseTools, PCD database and driver updates are needed for this proposal.
BaseTools can even be intelligent to generate smallest SKU delta based on the 
PCD values for different SKUs and the relationship between SKUs.
For single SKU (default) case, this proposal is expected to have no impact.
Note: For multi-SKU case, PCD database format will be changed, so PCD driver 
will have to be updated together with BaseTools.

Cc: Michael Kinney <michael.d.kin...@intel.com>
Cc: Liming Gao <liming@intel.com>
Cc: Tim Lewis <tim.le...@insyde.com>
Cc: Yonghong Zhu <yonghong@intel.com>

---
 .../Include/Guid/PcdDataBaseSignatureGuid.h| 32 +-
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h 
b/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h
index d2e848800b75..0069823458cd 100644
--- a/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h
+++ b/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h
@@ -62,11 +62,6 @@ typedef struct  {
 } DYNAMICEX_MAPPING;

 typedef struct {
-  UINT32  SkuDataStartOffset;   // Offset(with DATUM TYPE info) from the 
PCD_DB.
-  UINT32  SkuIdTableOffset; // Offset from the PCD_DB.
-} SKU_HEAD;
-
-typedef struct {
   UINT32  StringIndex;  // Offset in String Table in units of UINT8.
   UINT32  DefaultValueOffset;   // Offset of the Default Value.
   UINT16  GuidTableIndex;   // Offset in Guid Table in units of GUID.
@@ -115,7 +110,6 @@ typedef struct {
 // Padding is needed to keep necessary alignment
 //
 //SKU_ID SkuIdTable[];// SkuIds system 
supports.
-//SKU_ID SkuIndexTable[]; // SkuIds for 
each PCD with SKU enable.
 //UINT64 ValueUint64[];
 //UINT32 ValueUint32[];
 //VPD_HEAD   VpdHead[];   // VPD Offset
@@ -125,7 +119,6 @@ typedef struct {
 //STRING_HEADStringHead[];// String PCD
 //PCD_NAME_INDEX PcdNameTable[];  // PCD name 
index info. It can be accessed by the PcdNameTableOffset.
 //VARIABLE_HEAD  VariableHead[];  // HII PCD
-//SKU_HEAD   SkuHead[];   // Store SKU 
info for each PCD with SKU enable.
 //UINT8  StringTable[];   // String for 
String PCD value and HII PCD Variable Name. It can be accessed by 
StringTableOffset.
 //SIZE_INFO  SizeTable[]; // MaxSize 

Re: [edk2] [PATCH] ShellPkg/Touch: Create file if it doesn't exist

[Tim Lewis]

I don't think it is good to change the behavior of the tool beyond what is in 
the specification. Further, this tool has existed for quite a long time in the 
EDK shell and now the UEFI shell without this behavior. So the de-facto 
standard of this environment is "don't create". Leaving behind stray 0 byte 
files would be an unwanted side effect for existing scripts that use this 
command.

Further, this doesn't add any corresponding command-line options to , and 
certainly not without corresponding command-line options like -c to disable 
this behavior.

Thanks,

Tim


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff 
Westfahl
Sent: Monday, May 15, 2017 2:02 PM
To: edk2-devel@lists.01.org
Cc: Ruiyu Ni ; Jaben Carsey 
Subject: [edk2] [PATCH] ShellPkg/Touch: Create file if it doesn't exist

The UEFI Shell touch command returns an error if a file to be touched doesn't 
exist. In other command line operating environments, the touch command 
typically creates a file if it doesn't exist. This patch updates the UEFI Shell 
touch command to follow this convention.

Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl 
---
 ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c 
b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
index 639346f..921de5a 100644
--- a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
+++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
@@ -175,11 +175,13 @@ ShellCommandRunTouch (
   UINTN   ParamCount;
   EFI_SHELL_FILE_INFO *FileList;
   EFI_SHELL_FILE_INFO *Node;
+  SHELL_FILE_HANDLE   FileHandle;
 
   ProblemParam= NULL;
   ShellStatus = SHELL_SUCCESS;
   ParamCount  = 0;
   FileList= NULL;
+  FileHandle  = NULL;
 
   //
   // initialize the shell lib (we must be in non-auto-init...) @@ -226,9 
+228,17 @@ ShellCommandRunTouch (
  ){
 Status = ShellOpenFileMetaArg((CHAR16*)Param, 
EFI_FILE_MODE_READ|EFI_FILE_MODE_WRITE, );
 if (EFI_ERROR(Status)) {
-  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_PARAM_INV), 
gShellLevel3HiiHandle, L"touch", (CHAR16*)Param);  
-  ShellStatus = SHELL_NOT_FOUND;
-  break;
+  //
+  // try to create the file in case it doesn't exist
+  //
+  gEfiShellProtocol->CreateFile(Param, 0, );
+  gEfiShellProtocol->CloseFile(FileHandle);
+  Status = ShellOpenFileMetaArg((CHAR16*)Param, 
EFI_FILE_MODE_READ|EFI_FILE_MODE_WRITE, );
+  if (EFI_ERROR(Status)) {
+ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_PARAM_INV), 
gShellLevel3HiiHandle, L"touch", (CHAR16*)Param);
+ShellStatus = SHELL_NOT_FOUND;
+break;
+  }
 }
 //
 // make sure we completed the param parsing sucessfully...
--
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Star --

Thanks for your work on this. I have reviewed this and it looks good, 
addressing all of our concerns.

Tim

-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com] 
Sent: Monday, May 15, 2017 2:46 AM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Thanks all for the comments to this RFC.

I have sent out the V2 of this RFC at 
https://www.mail-archive.com/edk2-devel@lists.01.org/msg25687.html.

Tim,
Could you help review the V2 of this RFC and provide feedback?

With the V2 of this RFC, the actual code for the runtime usage you provided 
will be like below.

UINT64 SkuId;
VOID *Resource;

SkuId = LibPcdGetSku ();

Resource = NULL;
while (!GetResourceForSkuId (SkuId, ) && SkuId != 0) {
  SkuId = PcdGetParentSkuId (SkuId);
}
If (Resource == NULL) {
  // error, no resource found.
}


Thanks,
Star
-Original Message-
From: Kinney, Michael D
Sent: Saturday, May 6, 2017 12:07 AM
To: Zeng, Star <star.z...@intel.com>; Tim Lewis <tim.le...@insyde.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Gao, Liming <liming@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Star,

I think Tim's feedback is a request for an additional feature on top of this 
RFC.  I do not see any requests for changes to the proposed syntax extensions.  
I agree that implementing these new feature in an edk2-staging branch makes a 
lot of sense.
 
Since Tim's request is about access to the SKU relationships from FW modules 
when the FW module executes, let's discuss this from an API perspective instead 
of detailed autogen.  We can figure out what autogen is required to support the 
API.

When a platform boots with multiple SKUs enabled in the FW image, typically a 
platform PEIM detects what SKU is present can calls the PcdLib function 
LibPcdSetSku() to set the active SKU.

Then, that same module or other modules may want to know how the current SKU is 
related to other SKUs.  Those other modules can start with LibPcdGetSku() to 
get the active SKU.

This RFC introduces the concept that one SKU may be a derivative of another 
SKU, and may be used to reduce the total number PCD statements in a DSC file.  
This derivative concept can be thought of as parent to child link between the 2 
SKUs.  We can draw this visually as a tree with parent child relationships 
between all the SKUs.

Now from a module that calls LibPcdGetSku(), the module may want to know who 
the parent SKU is.  The information we have about the parent SKU is the SKU ID 
value.

A new API that may be useful here is something like:

UINTN
GetParentSku (
  IN UINTN  SkuId
  );

The algorithm that Tim provided below uses autogen and a loop to retrieve the 
parent SKU.

So the request here is to extend the autogen to support a lookup of the parent 
SKU given any valid SKU ID value.

Thanks,

Mike
 
> -Original Message-
> From: Zeng, Star
> Sent: Friday, May 5, 2017 3:08 AM
> To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming@intel.com>; Zeng, Star 
> <star.z...@intel.com>
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Tim,
> 
> In your code base, there are other tools beyond BaseTools to parse the 
> [SkuIds] section and SKUID_IDENTIFIER in DSC, right?
> 
> The boot time usage (use the value in DEFAULT SKU instead if the value 
> in specified SKU is not configured) for other resources in your code base is 
> similar to PCD, right?
> This RFC has no change to this boot time behavior that "use the value 
> in DEFAULT SKU instead if the value in specified SKU is not configured".
> So I am still not so clear about the benefit of the macro like #define 
> SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0.
> 
> 
> The DSC syntax extension in this RFC is OPTIONAL, the backward 
> compatibility is expected to be kept, no current tools and code should be 
> impacted.
> As I know, there will be a staging branch proposed for the development 
> of PCD related RFCs (include Structure PCD, etc). Mike and Liming can help 
> confirm it.
> How about we have the development of this RFC to the staging branch 
> first, then you can help evaluate the syntax and provide feedback 
> further? :)
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Friday, May 5, 2017 12:36 AM
> To: Zeng, Star <star.z...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
&

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Star,

We would like to track the exact same defaulting as is used by PCDs. Otherwise 
it is confusing to users. If we were to say, "Use the this defaulting scheme 
for PCDs, but ignore it for all of the other runtime resource selection." That 
would be confusing to users. Of course, we can decide not to use this, but we 
actually like it.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, 
Star
Sent: Friday, May 05, 2017 3:08 AM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Zeng, Star <star.z...@intel.com>; Gao, Liming <liming@intel.com>
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

In your code base, there are other tools beyond BaseTools to parse the [SkuIds] 
section and SKUID_IDENTIFIER in DSC, right?

The boot time usage (use the value in DEFAULT SKU instead if the value in 
specified SKU is not configured) for other resources in your code base is 
similar to PCD, right?
This RFC has no change to this boot time behavior that "use the value in 
DEFAULT SKU instead if the value in specified SKU is not configured".
So I am still not so clear about the benefit of the macro like #define 
SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0.


The DSC syntax extension in this RFC is OPTIONAL, the backward compatibility is 
expected to be kept, no current tools and code should be impacted.
As I know, there will be a staging branch proposed for the development of PCD 
related RFCs (include Structure PCD, etc). Mike and Liming can help confirm it.
How about we have the development of this RFC to the staging branch first, then 
you can help evaluate the syntax and provide feedback further? :)


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Friday, May 5, 2017 12:36 AM
To: Zeng, Star <star.z...@intel.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

Star --

I understand your use case. We use the same behavior for other resources 
besides PCD. 

All we are asking is that this data that is used by the build tools is also 
available in some form at runtime. 

Thanks,

Tim
 


-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Thursday, May 04, 2017 6:42 AM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

To avoid misunderstanding, I think I need to clarify more about this RFC. :)

This RFC is NOT to propose building real relationship (like parent-child) 
between non-DEFAULT SKUs, it seems easy to bring confusion from the proposed 
syntax " SkuValue|SkuName[|ParentSkuName]", especially the word 'Parent', sorry 
for any confusion.
The syntax extension proposed by this RFC is just to simplify the PCDs 
configuring for multiple SKUs in DSC, I want to emphasize it is in DSC, it is 
to cover the case that some non-DEFAULT SKU has much PCD values equal with 
another non-DEFAULT SKU, but less PCD values equal with DEFAULT SKU.
This RFC has no any change to boot time behavior and does not break the rule 
that DEFAULT SKU PCD value will be returned if the specified SKU PCD value is 
not configured in DSC, the code logic is below.

PcdPeim Service.c:
  //
  // Find the current system's SKU ID entry in SKU ID table.
  //
  FoundSku = FALSE;
  for (Index = 0; Index < SkuIdTable[0]; Index++) {
if (PeiPcdDb->SystemSkuId == SkuIdTable[Index + 1]) {
  FoundSku = TRUE;
  break;
}
  }

  //
  // Find the default SKU ID entry in SKU ID table.
  //
  if(!FoundSku) {
for (Index = 0; Index < SkuIdTable[0]; Index++) {
  if (0 == SkuIdTable[Index + 1]) {
break;
  }
}
  }


The usage case you provided for other resources beyond PCD could be like below?

CurrentSkuId = PcdGetSkuId();

Resource = NULL;
if (!GetResourceForSkuId(CurrentSkuId, ) {
  // try DEFAULT SKU
  GetResourceForSkuId(0, );
}
If (Resource == NULL) {
  // error, no resource found for any of the SKU IDs }



Thanks,
Star
-----Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Thursday, May 4, 2017 2:55 AM
To: Zeng, Star <star.z...@intel.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

We use SKU IDs for working with 15 different key resources in our product. Some 
are related to code execution, but most are related to selection of

Re: [edk2] [RFC 0/3] Structure PCD value assignment in DEC/DSC

[Tim Lewis]

Mike --

Sorry for the delay. We have reviewed this RFC internally and we believe it is 
a useful change. 

Thanks,

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
Liming
Sent: Tuesday, April 11, 2017 8:17 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [RFC 0/3] Structure PCD value assignment in DEC/DSC

Requirment: Map VOID* PCD to C structure 1. When PCD is configured as 
DynamicHii, it will be map to one EFI variable. If PCD is VOID*, it can map to 
the whole EFI variable. Most EFI variable data are defined as C structure.
2. Some PCDs are designed as C style structure, such as 
gEfiMdeModulePkgTokenSpaceGuid.PcdPciSerialParameters.

Current limitation:
1. VOID* PCD Value must be byte array. Its value is hard to be specified.
2. If single PCD is defined to map one field in structure, its offset and width 
will be required when this PCD is configured as DynamicHii or DynamicVpd. If 
the structure is big, it will require lots of PCDs to map its each field. If 
the structure has the bit field, its bit field can't match PCD.

Proposal:
Enhance EDKII Build system to support VOID* PCD be mapped to C structure in DEC 
or DSC. PCD value can be specified by structure field as C language style in 
DEC and DSC. Then, its value will be converted to byte array and assigned to 
VOID* PCD. This is a pure build enhancement, and no change in PCD driver.
1. New syntax in DEC and DSC defines PCD with C structure.
  a. PCD Data type will be C structure name.
  b. C structure header file and the dependent packages are required to be 
listed.
  c. Example in DEC [PcdsFixedAtBuild] section:
gStructuredPcdPkgTokenSpaceGuid.PcdTest|{0xFF}|TEST|0x00010080 {

  Guid/Test.h

  MdePkg/MdePkg.dec
  MdeModulePkg/MdeModulePkg.dec
}
2. Set the value to the structure fields like normal PCD in DEC/DSC/FDF.
  a. If the field value is not specified, its default value will be zero.
  b. Example in DEC/DSC [PcdsFixedAtBuild] section:
gStructuredPcdPkgTokenSpaceGuid.PcdTest.Bool|TRUE
gStructuredPcdPkgTokenSpaceGuid.PcdTest.Array[1].Foo|"ABC"
gStructuredPcdPkgTokenSpaceGuid.PcdTest.C|0xFEDC
gStructuredPcdPkgTokenSpaceGuid.PcdTest.D|
3. Pre AutoGen phase, Build tool will prepare the value for structure PCD.
  a. Generate C file (name as pcdc file) and its Makefile to include PCD value 
initialization.
i. Parse PCD field values in DEC/DSC/FDF to generate pcdc file.
ii. Developer provides their pcdc files to customize PCD value in one 
module INF.
  b. Compile C file to the executable tool like BaseTools C tools.
  c. Run the executable file to output the byte array PCD value.
  d. Build tool gets the byte array PCD value and generate AutoGen code, 
continue to normal edk2 build process.
4. Pcdc file will include the different functions to initialize the different 
PCD value on the different SKU
  a. BaseTools CommonLib adds the generic APIs to parse Args, Get/Set PCD value.
  b. Pcdc file is compiled and run by Build tool, user doesn't need aware it.
5. Report
  a. Error report will point to the specified value in DEC or DSC when the 
value can't be assigned to structure field.
  b. Build Report will print Structure PCD value with byte array and field 
value both.
6. C Structure requirement
  a. Structure field data type can't be VOID* or UINTN. its size must be same 
at the crossing ARCHs.
  b. Structure field can be bits, union, nest structure, structure array, enum, 
pack, unpack.
  c. Structure field value can be MACRO, Enum or constant value.

Patch:
This patches add TestPkg to show StructurePcd Value Assignment usage in DEC and 
DSC.

Python StructuredPcdValueGenerator.py is added to show structure PCD usage. Its 
logic will be integrated into BaseTools later. This script bases on Package dec 
and Package dsc to convert structure PCD value to byte array. It depends on 
BaseTools C source CommonLib.
Before run this script, BaseTools are required to be compiled first. This 
script will generate $(WORKSPACE)\Build\PcdValueInit\PcdValueInit.c with the 
structure PCD field value, and generate 
$(WORKSPACE)\Build\PcdValueInit\Makefile to compile it to the executable file.
It also generates $(WORKSPACE)\Build\PcdValueInit\Input.txt to include the 
initial PCD value from its declartion in dec file. Last, run the generated 
executable file with Input.txt, and output the final PCD value in 
$(WORKSPACE)\Build\PcdValueInit\Output.txt.

In Windows:
1. enter into edk2
2. type edksetup.bat --nt32
3. nmake -f BaseTools\Makefile
4. C:\Python27\python.exe TestPkg\StructuredPcdValueGenerator.py -p 
TestPkg\TestPkg.dec -d TestPkg\TestPkg.dsc

In Linux:
1. enter into edk2
2. . edksetup.sh BaseTools
3. cd BaseTools
4. make
5. cd edk2
6. python TestPkg/StructuredPcdValueGenerator.py -p TestPkg/TestPkg.dec -d 
TestPkg/TestPkg.dsc

After run StructuredPcdValueGenerator.py, Structure PCD value will output as 
byte array.

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Star --

I understand your use case. We use the same behavior for other resources 
besides PCD. 

All we are asking is that this data that is used by the build tools is also 
available in some form at runtime. 

Thanks,

Tim
 


-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com] 
Sent: Thursday, May 04, 2017 6:42 AM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

To avoid misunderstanding, I think I need to clarify more about this RFC. :)

This RFC is NOT to propose building real relationship (like parent-child) 
between non-DEFAULT SKUs, it seems easy to bring confusion from the proposed 
syntax " SkuValue|SkuName[|ParentSkuName]", especially the word 'Parent', sorry 
for any confusion.
The syntax extension proposed by this RFC is just to simplify the PCDs 
configuring for multiple SKUs in DSC, I want to emphasize it is in DSC, it is 
to cover the case that some non-DEFAULT SKU has much PCD values equal with 
another non-DEFAULT SKU, but less PCD values equal with DEFAULT SKU.
This RFC has no any change to boot time behavior and does not break the rule 
that DEFAULT SKU PCD value will be returned if the specified SKU PCD value is 
not configured in DSC, the code logic is below.

PcdPeim Service.c:
  //
  // Find the current system's SKU ID entry in SKU ID table.
  //
  FoundSku = FALSE;
  for (Index = 0; Index < SkuIdTable[0]; Index++) {
if (PeiPcdDb->SystemSkuId == SkuIdTable[Index + 1]) {
  FoundSku = TRUE;
  break;
}
  }

  //
  // Find the default SKU ID entry in SKU ID table.
  //
  if(!FoundSku) {
for (Index = 0; Index < SkuIdTable[0]; Index++) {
  if (0 == SkuIdTable[Index + 1]) {
break;
  }
}
  }


The usage case you provided for other resources beyond PCD could be like below?

CurrentSkuId = PcdGetSkuId();

Resource = NULL;
if (!GetResourceForSkuId(CurrentSkuId, ) {
  // try DEFAULT SKU
  GetResourceForSkuId(0, );
}
If (Resource == NULL) {
  // error, no resource found for any of the SKU IDs }



Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Thursday, May 4, 2017 2:55 AM
To: Zeng, Star <star.z...@intel.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

We use SKU IDs for working with 15 different key resources in our product. Some 
are related to code execution, but most are related to selection of resources. 
I mentioned logo components and HII strings already.

I am asking that the information about SKU relationships be output in some form 
so that it can be used at runtime, by whatever component. Today, there is an 
implied relationship between a SKU X and the SKU DEFAULT for PCDs. We use this 
rule in many places, because it expresses a useful relationship.

So, in the Project's .dsc file (forgive my syntax, which may not match yours 
exactly)

// Select which SKUs
SKUID_IDENTIFIER = Sku2 Sku1 DEFAULT

[SkuIds]
  0|DEFAULT
  1|Sku1
  2|Sku2 Sku1
  3|Sku3

In (proposed) AutoGen.h. This gives enough data for runtime usage. For other 
build tools to use, maybe something else is required.

// Output as an array initializer. DEFAULT is always last.
// Only output for SKUs listed in SKUID_IDENTIFIER // 2->1->0 // 1->0 // 0 
#define SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0

// In actual code:

UINT32 SkuIdDefaults[] = {SKUID_IDENTIFIER_DEFAULT};
UINT32 *SkuId;
UINT32 CurrentSkuId;
BOOLEAN Found;
VOID *Resource;

CurrentSkuId = PcdGetSkuId();

SkuId = SkuIdDefaults;
Found = (CurrentSkuId == 0); // so that DEFAULT will also return TRUE; while 
(*SkuId != 0) {
  if (*SkuId == CurrentSkuId) {
Found = TRUE;
Break;
  }
  while (*SkuId != 0) {
 SkuId++;
  }
  SkuId++;
}
if (!Found) {
  //error, because SKU ID was not found in array }

Resource = NULL;
while (!GetResourceForSkuId(*SkuId, ) && *SkuId == 0) {
  *SkuId++;
}
If (Resource == NULL) {
  // error, no resource found for any of the SKU IDs }






From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Wednesday, May 03, 2017 7:03 AM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

Could you help share and explain the use cases in your code base that is using 
[SkuIds] section and SKUID_IDENTIFIER for others beyond PCD?
Then we can consider more in [RFC] PCD: Extended SKU support. Or do you have 
detailed propose in this RFC or new RFC about your use cases?

Thanks,

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

We use SKU IDs for working with 15 different key resources in our product. Some 
are related to code execution, but most are related to selection of resources. 
I mentioned logo components and HII strings already.

I am asking that the information about SKU relationships be output in some form 
so that it can be used at runtime, by whatever component. Today, there is an 
implied relationship between a SKU X and the SKU DEFAULT for PCDs. We use this 
rule in many places, because it expresses a useful relationship.

So, in the Project's .dsc file (forgive my syntax, which may not match yours 
exactly)

// Select which SKUs
SKUID_IDENTIFIER = Sku2 Sku1 DEFAULT

[SkuIds]
  0|DEFAULT
  1|Sku1
  2|Sku2 Sku1
  3|Sku3

In (proposed) AutoGen.h. This gives enough data for runtime usage. For other 
build tools to use, maybe something else is required.

// Output as an array initializer. DEFAULT is always last.
// Only output for SKUs listed in SKUID_IDENTIFIER
// 2->1->0
// 1->0
// 0
#define SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0

// In actual code:

UINT32 SkuIdDefaults[] = {SKUID_IDENTIFIER_DEFAULT};
UINT32 *SkuId;
UINT32 CurrentSkuId;
BOOLEAN Found;
VOID *Resource;

CurrentSkuId = PcdGetSkuId();

SkuId = SkuIdDefaults;
Found = (CurrentSkuId == 0); // so that DEFAULT will also return TRUE;
while (*SkuId != 0) {
  if (*SkuId == CurrentSkuId) {
Found = TRUE;
Break;
  }
  while (*SkuId != 0) {
 SkuId++;
  }
  SkuId++;
}
if (!Found) {
  //error, because SKU ID was not found in array
}

Resource = NULL;
while (!GetResourceForSkuId(*SkuId, ) && *SkuId == 0) {
  *SkuId++;
}
If (Resource == NULL) {
  // error, no resource found for any of the SKU IDs
}






From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Wednesday, May 03, 2017 7:03 AM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

Could you help share and explain the use cases in your code base that is using 
[SkuIds] section and SKUID_IDENTIFIER for others beyond PCD?
Then we can consider more in [RFC] PCD: Extended SKU support. Or do you have 
detailed propose in this RFC or new RFC about your use cases?

Thanks,
Star
From: Kinney, Michael D
Sent: Friday, April 28, 2017 11:26 AM
To: Tim Lewis <tim.le...@insyde.com<mailto:tim.le...@insyde.com>>; Zeng, Star 
<star.z...@intel.com<mailto:star.z...@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
Cc: Gao, Liming <liming@intel.com<mailto:liming@intel.com>>; Zeng, Star 
<star.z...@intel.com<mailto:star.z...@intel.com>>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Hi Star,

The 2nd RFC for SKUs add some autogen to support setting the SKU from a 
platform PEIM.

We should consider additional autogen that allows a module to determine the 
relationships between SKUs.  This additional autogen is not required for the 
PCD part of the proposal, but could be used by other components.

Mike

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Thursday, April 27, 2017 7:09 PM
To: Zeng, Star <star.z...@intel.com<mailto:star.z...@intel.com>>; Kinney, 
Michael D <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming@intel.com<mailto:liming@intel.com>>; Zeng, Star 
<star.z...@intel.com<mailto:star.z...@intel.com>>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance


Start,



The RFC adds a new mechanism for expressing a relationship between SKUs. The 
[SkuIds] section is not tied to PCDs.



The RFC wants to use this relationship to simplify PCD definitions in the DSC 
file. Fine. But SkuId relationships are not exclusive to PCDs. There are other 
places where such information can be used. Therefore, publishing this 
information so that it can be used by other runtime agents besides the. PCD 
driver makes sense. Many of these have nothing to do with EDK, but have to do 
with OEM designs.



Thanks,



Tim



Sent from my Windows 10 phone



From: Zeng, Star<mailto:star.z...@intel.com>
Sent: Thursday, April 27, 2017 6:53 PM
To: Tim Lewis<mailto:tim.le...@insyde.com>; Kinney, Michael 
D<mailto:michael.d.kin...@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming<mailto:liming@intel.com>; Zeng, 
Star<mailto:star.z...@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance


Tim,

So, you mean SKU in other scope?

The title of this RFC is about PCD. Should they be discussed together? :)

That relationship between PCD SKUs proposed by this

Re: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to be UTF-8 without a BOM

[Tim Lewis]

Mike --

After an internal review, we have found that there are fewer files than 
previously thought affected by this change. 

So we have no objections to updating the UNI Spec to match the current EDK2 
tool behavior?

Thanks,

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Wednesday, April 26, 2017 5:27 PM
To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
<kevin.w.s...@intel.com>
Subject: Re: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to 
be UTF-8 without a BOM

Mike --

No, the meta-data (in this case, file extension .uni) was used by tools to 
determine the format of the file contents, as described in section 2.6. 
Little-endian, UCS-2 was assumed.

"When a higher-level protocol supplies mechanisms for handling the endianness 
of integral data types, it is not necessary to use Unicode encoding schemes or 
the byte order mark. In those cases Unicode text is simply a sequence of 
integral data types."

Of course, the tools had to be updated to accommodate different build systems, 
and even alternate encodings. But this doesn't remove the previous behavior.
 
Tim



-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Wednesday, April 26, 2017 5:02 PM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael 
D <michael.d.kin...@intel.com>
Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
<kevin.w.s...@intel.com>
Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to 
be UTF-8 without a BOM

Hi Tim,

For UTF-16 files on disk with no BOM, do you follow the big-endian assumption 
as documented in the Unicode Specification Section 3.10, D98?

http://www.unicode.org/versions/Unicode9.0.0/ch03.pdf

Mike

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, April 26, 2017 4:13 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; 
> edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> <kevin.w.s...@intel.com>
> Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on 
> disk to be
> UTF-8 without a BOM
> 
> Mike --
> 
> I would prefer to update the docs to match actual industry practice. 
> EDK2 is not the universe.
> 
> Insyde has been using UNI files well before my time here (> 5 years). 
> The fact that recent specifications or EDK2 tools (2 years) added BOM 
> support it does not remove the backward compatibility issue.
> 
> The Unicode specification usage of "not recommended" is referring 
> specifically to its usage for byte-order. The full sentence (from 2.6) 
> is: "Use of a BOM is neither required nor recommended [for byte order 
> determination] for UTF-8, but may be encountered in contexts where 
> UTF-8 data is converted from other encoding forms that use a BOM or 
> where the BOM is used as a UTF-8 signature" Editorial comment mine. In this 
> case, the BOM marker would appear as a UTF-8 signature.
> This would distinguish it from ASCII or any of the multi-byte encoding 
> schemes used.
> 
> Tim
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, April 26, 2017 3:47 PM
> To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, 
> Michael D <michael.d.kin...@intel.com>
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> <kevin.w.s...@intel.com>
> Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on 
> disk to be
> UTF-8 without a BOM
> 
> Hi Tim,
> 
> The recommendation for UTF-8 usage is to not use a BOM, which is why 
> no BOM for
> UTF-8 was selected for EDK II.
> 
> The current task is to update docs to match the current tool behavior.
> 
> The EDK II repos on GitHub have .uni files in UTF-8 format without a 
> BOM to support easier patch review.
> 
> There are ways to use GIT features to auto-convert .uni files when 
> pulling content from EDK II repos and pushing commits.
> That may or may not help with the specific issue you are raising.
> 
> If you have ideas on a tool change request to EDK II that would 
> provide compatibility with current EDK II tool behavior and support 
> UTF-16LE without a BOM, then let's work that through in a Bugzilla 
> feature request.  If we find a solution, we can update the docs and tools 
> again.
> 
> Do you have any objections to updating the UNI Spec to match the 
> current tool behavior?
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Tim

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Start,



The RFC adds a new mechanism for expressing a relationship between SKUs. The 
[SkuIds] section is not tied to PCDs.



The RFC wants to use this relationship to simplify PCD definitions in the DSC 
file. Fine. But SkuId relationships are not exclusive to PCDs. There are other 
places where such information can be used. Therefore, publishing this 
information so that it can be used by other runtime agents besides the. PCD 
driver makes sense. Many of these have nothing to do with EDK, but have to do 
with OEM designs.



Thanks,



Tim



Sent from my Windows 10 phone



From: Zeng, Star<mailto:star.z...@intel.com>
Sent: Thursday, April 27, 2017 6:53 PM
To: Tim Lewis<mailto:tim.le...@insyde.com>; Kinney, Michael 
D<mailto:michael.d.kin...@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming<mailto:liming@intel.com>; Zeng, 
Star<mailto:star.z...@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance



Tim,

So, you mean SKU in other scope?

The title of this RFC is about PCD. Should they be discussed together? :)

That relationship between PCD SKUs proposed by this RFC is just used to 
*simplify the PCDs configuring for multiple SKUs in DSC*.
How the relationship between PCD SKUs impact other things?


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Friday, April 28, 2017 9:43 AM
To: Zeng, Star <star.z...@intel.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

Star --

Simply to say: We use SKUs for many more things than PCDs. While EDK2's build 
system may only use SKU IDs in relation with PCDs, our BIOS uses it for many 
other things.

So understanding the relationship between SKUs has an impact (for us) beyond 
what can be decided by the PCD database.

Tim

-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Thursday, April 27, 2017 6:00 PM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

Could you share more information about the case Hii string packages?

Like Mike replied with below explanation, the purpose of this RFC is simple to 
extend SKU inheritance in DSC.

"With this proposal, a relationship between SKUs can be declared in the DSC 
file, so SKUs can inherit PCD values from other SKUs.  This inheritance is 
limited to the scope of the DSC file.  This RFC has no impact to the PCD 
database or behavior of PCD services."

Thanks,
Star
-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, April 28, 2017 12:28 AM
To: Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star 
<star.z...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Mike --

For the one-logo case, yes, that would work. But this is the simplest case. 
Consider HII string packages.

Tim

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, April 26, 2017 5:28 PM
To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star <star.z...@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Gao, Liming <liming@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

Could you use a PCD (for example a GUID value of an FFS file) for the Logo, and 
you could use PcdGet() after SetSku() and the GUID value of the FFS file with 
the logo would be returned for the lookup.

That way, the need for the relationship information at runtime is removed and 
you would get the behavior you describe below.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Tim Lewis
> Sent: Wednesday, April 26, 2017 4:06 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star
> <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming@intel.com>
> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
>
> Mike --
>
> We select logos for SKU C (which is listed as having SKU A and
> DEFAULT) as its antecedents. If SKU C does not have a logo, then the
> SKU from SKU A is used. And if not from SKU A, then from DEFAULT.
>
> Tim
>
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, April 26, 2017 3:57 PM
> To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star
> <star.z...@intel.com&g

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Star --

Simply to say: We use SKUs for many more things than PCDs. While EDK2's build 
system may only use SKU IDs in relation with PCDs, our BIOS uses it for many 
other things.

So understanding the relationship between SKUs has an impact (for us) beyond 
what can be decided by the PCD database.

Tim

-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com] 
Sent: Thursday, April 27, 2017 6:00 PM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

Could you share more information about the case Hii string packages?

Like Mike replied with below explanation, the purpose of this RFC is simple to 
extend SKU inheritance in DSC.

"With this proposal, a relationship between SKUs can be declared in the DSC 
file, so SKUs can inherit PCD values from other SKUs.  This inheritance is 
limited to the scope of the DSC file.  This RFC has no impact to the PCD 
database or behavior of PCD services."

Thanks,
Star
-----Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com] 
Sent: Friday, April 28, 2017 12:28 AM
To: Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star 
<star.z...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Mike --

For the one-logo case, yes, that would work. But this is the simplest case. 
Consider HII string packages.

Tim 

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, April 26, 2017 5:28 PM
To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star <star.z...@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Gao, Liming <liming@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

Could you use a PCD (for example a GUID value of an FFS file) for the Logo, and 
you could use PcdGet() after SetSku() and the GUID value of the FFS file with 
the logo would be returned for the lookup.

That way, the need for the relationship information at runtime is removed and 
you would get the behavior you describe below.

Mike

> -Original Message-----
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Wednesday, April 26, 2017 4:06 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star 
> <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming@intel.com>
> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Mike --
> 
> We select logos for SKU C (which is listed as having SKU A and
> DEFAULT) as its antecedents. If SKU C does not have a logo, then the 
> SKU from SKU A is used. And if not from SKU A, then from DEFAULT.
> 
> Tim
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, April 26, 2017 3:57 PM
> To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star 
> <star.z...@intel.com>; edk2- de...@lists.01.org; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Cc: Gao, Liming <liming@intel.com>
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Hi Tim,
> 
> How would this relationship information be used in a module?
> Do you have an example use case where this relationship information 
> could be used from the selected SKU?  Maybe there is a different 
> method to solve the same problem?
> 
> Please also review the 2nd SKU related RFC titled:
> 
>   [RFC 0/2] PCD: Extended SKU support 2 - sub SKU
> 
> This 2nd RFC builds on the first SKU RFC.  The SKU inheritance 
> relationships are not as straight forward when you add the concept of 
> generating all possible combinations of SKUs from multiple subsystems.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Tim Lewis
> > Sent: Wednesday, April 26, 2017 12:59 PM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star 
> > <star.z...@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming@intel.com>
> > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> >
> > Mike --
> >
> > So your use case for SetSku() is also what we've used.
> >
> > Generating a simple table that describes the default relationships 
> > between SKUs is helpful:
> >
> > DEFAULT
> > A DEFAULT
> > B A DEFAULT
> >
> > This could be a #define in the form of a

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Mike --

For the one-logo case, yes, that would work. But this is the simplest case. 
Consider HII string packages.

Tim 

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Wednesday, April 26, 2017 5:28 PM
To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star <star.z...@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Gao, Liming <liming@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

Could you use a PCD (for example a GUID value of an FFS file) for the Logo, and 
you could use PcdGet() after SetSku() and the GUID value of the FFS file with 
the logo would be returned for the lookup.

That way, the need for the relationship information at runtime is removed and 
you would get the behavior you describe below.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Wednesday, April 26, 2017 4:06 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star 
> <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming@intel.com>
> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Mike --
> 
> We select logos for SKU C (which is listed as having SKU A and 
> DEFAULT) as its antecedents. If SKU C does not have a logo, then the 
> SKU from SKU A is used. And if not from SKU A, then from DEFAULT.
> 
> Tim
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, April 26, 2017 3:57 PM
> To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star 
> <star.z...@intel.com>; edk2- de...@lists.01.org; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Cc: Gao, Liming <liming@intel.com>
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Hi Tim,
> 
> How would this relationship information be used in a module?
> Do you have an example use case where this relationship information 
> could be used from the selected SKU?  Maybe there is a different 
> method to solve the same problem?
> 
> Please also review the 2nd SKU related RFC titled:
> 
>   [RFC 0/2] PCD: Extended SKU support 2 - sub SKU
> 
> This 2nd RFC builds on the first SKU RFC.  The SKU inheritance 
> relationships are not as straight forward when you add the concept of 
> generating all possible combinations of SKUs from multiple subsystems.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Tim Lewis
> > Sent: Wednesday, April 26, 2017 12:59 PM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star 
> > <star.z...@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming@intel.com>
> > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> >
> > Mike --
> >
> > So your use case for SetSku() is also what we've used.
> >
> > Generating a simple table that describes the default relationships 
> > between SKUs is helpful:
> >
> > DEFAULT
> > A DEFAULT
> > B A DEFAULT
> >
> > This could be a #define in the form of a C UINT32 structure initializer:
> >
> > #define SKUID_DEFAULT_ORDER 0,1,0,2,1,0
> >
> > I think that this should be a part of this RFC.
> >
> > -
> > Having said that, we've used multi-SKU for a long time and there are 
> > common error cases that could be aided by some tool support.
> >
> > 1) When an image is designed to support SKUs A, B, C (out of a 
> > possible set of SKU A-H), but the SKU detected is: G. This is an 
> > error condition that is difficult to detect. SetSku() can't do it, 
> > because there is no guarantee (today) that the PCD driver knows all 
> > possible SKUs, only those that have PCDs associated with them.
> >
> > 2) When C code is designed to run for SKUs A, B, D, H, the image was 
> > built for A,B,C and the SKU detected during POST was D. By having a 
> > macro that returns whether board X is supported, code which is not 
> > used for the current build can be eliminated from the build. For 
> > example. #define SKU_NAME_SUPPORTED(sku-
> > identifier) can return FALSE if the SKU associated with 
> > sku-identifier is not in the build.  Also useful for ASL and VFR.
> >
> > 3) We have also found it useful to extend the build.exe command-line 
> > to allow multiple instances of -x to correctly populate the 
> > SKUID_IDENTIFIER.
> >
> > These might be the subject for additional RFCs.
&g

Re: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to be UTF-8 without a BOM

[Tim Lewis]

Mike --

No, the meta-data (in this case, file extension .uni) was used by tools to 
determine the format of the file contents, as described in section 2.6. 
Little-endian, UCS-2 was assumed.

"When a higher-level protocol supplies mechanisms for handling the endianness 
of integral data types, it is not necessary to use Unicode encoding schemes or 
the byte order mark. In those cases Unicode text is simply a sequence of 
integral data types."

Of course, the tools had to be updated to accommodate different build systems, 
and even alternate encodings. But this doesn't remove the previous behavior.
 
Tim



-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Wednesday, April 26, 2017 5:02 PM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael 
D <michael.d.kin...@intel.com>
Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
<kevin.w.s...@intel.com>
Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to 
be UTF-8 without a BOM

Hi Tim,

For UTF-16 files on disk with no BOM, do you follow the big-endian assumption 
as documented in the Unicode Specification Section 3.10, D98?

http://www.unicode.org/versions/Unicode9.0.0/ch03.pdf

Mike

> -----Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, April 26, 2017 4:13 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; 
> edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> <kevin.w.s...@intel.com>
> Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on 
> disk to be
> UTF-8 without a BOM
> 
> Mike --
> 
> I would prefer to update the docs to match actual industry practice. 
> EDK2 is not the universe.
> 
> Insyde has been using UNI files well before my time here (> 5 years). 
> The fact that recent specifications or EDK2 tools (2 years) added BOM 
> support it does not remove the backward compatibility issue.
> 
> The Unicode specification usage of "not recommended" is referring 
> specifically to its usage for byte-order. The full sentence (from 2.6) 
> is: "Use of a BOM is neither required nor recommended [for byte order 
> determination] for UTF-8, but may be encountered in contexts where 
> UTF-8 data is converted from other encoding forms that use a BOM or 
> where the BOM is used as a UTF-8 signature" Editorial comment mine. In this 
> case, the BOM marker would appear as a UTF-8 signature.
> This would distinguish it from ASCII or any of the multi-byte encoding 
> schemes used.
> 
> Tim
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, April 26, 2017 3:47 PM
> To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, 
> Michael D <michael.d.kin...@intel.com>
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> <kevin.w.s...@intel.com>
> Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on 
> disk to be
> UTF-8 without a BOM
> 
> Hi Tim,
> 
> The recommendation for UTF-8 usage is to not use a BOM, which is why 
> no BOM for
> UTF-8 was selected for EDK II.
> 
> The current task is to update docs to match the current tool behavior.
> 
> The EDK II repos on GitHub have .uni files in UTF-8 format without a 
> BOM to support easier patch review.
> 
> There are ways to use GIT features to auto-convert .uni files when 
> pulling content from EDK II repos and pushing commits.
> That may or may not help with the specific issue you are raising.
> 
> If you have ideas on a tool change request to EDK II that would 
> provide compatibility with current EDK II tool behavior and support 
> UTF-16LE without a BOM, then let's work that through in a Bugzilla 
> feature request.  If we find a solution, we can update the docs and tools 
> again.
> 
> Do you have any objections to updating the UNI Spec to match the 
> current tool behavior?
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > Sent: Wednesday, April 26, 2017 11:54 AM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>; 
> > edk2-devel@lists.01.org
> > Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> > <kevin.w.s...@intel.com>
> > Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files 
> > on disk to be
> > UTF-8 without a BOM
> >
> > Mike --
> >
> > This is not about files in the EDK II repository. This is about 
> > files created based on the spec, and created with other sets of 
> > tools. Go back to early 

Re: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to be UTF-8 without a BOM

[Tim Lewis]

Mike --

I would prefer to update the docs to match actual industry practice. EDK2 is 
not the universe. 

Insyde has been using UNI files well before my time here (> 5 years). The fact 
that recent specifications or EDK2 tools (2 years) added BOM support it does 
not remove the backward compatibility issue.

The Unicode specification usage of "not recommended" is referring specifically 
to its usage for byte-order. The full sentence (from 2.6) is: "Use of a BOM is 
neither required nor recommended [for byte order determination] for UTF-8, but 
may be encountered in contexts where UTF-8 data is converted from other 
encoding forms that use a BOM or where the BOM is used as a UTF-8 signature" 
Editorial comment mine. In this case, the BOM marker would appear as a UTF-8 
signature. This would distinguish it from ASCII or any of the multi-byte 
encoding schemes used.

Tim 

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Wednesday, April 26, 2017 3:47 PM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael 
D <michael.d.kin...@intel.com>
Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
<kevin.w.s...@intel.com>
Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to 
be UTF-8 without a BOM

Hi Tim,

The recommendation for UTF-8 usage is to not use a BOM, which is why no BOM for 
UTF-8 was selected for EDK II.

The current task is to update docs to match the current tool behavior.

The EDK II repos on GitHub have .uni files in UTF-8 format without a BOM to 
support easier patch review.

There are ways to use GIT features to auto-convert .uni files when pulling 
content from EDK II repos and pushing commits.  
That may or may not help with the specific issue you are raising.

If you have ideas on a tool change request to EDK II that would provide 
compatibility with current EDK II tool behavior and support UTF-16LE without a 
BOM, then let's work that through in a Bugzilla feature request.  If we find a 
solution, we can update the docs and tools again.

Do you have any objections to updating the UNI Spec to match the current tool 
behavior?

Thanks,

Mike

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, April 26, 2017 11:54 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; 
> edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> <kevin.w.s...@intel.com>
> Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on 
> disk to be
> UTF-8 without a BOM
> 
> Mike --
> 
> This is not about files in the EDK II repository. This is about files 
> created based on the spec, and created with other sets of tools. Go 
> back to early 2015, to the Build spec (1.22, etc.), Appendix G, which 
> is where the UNI stuff used to live.
> 
> The point is: files which worked before, and, at worst, generated a 
> warning before, now are interpreted incorrectly even though they have correct 
> data.
> 
> Making ASCII (or UTF-8) the default without a BOM is the breaking change.
> 
> Tim
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, April 26, 2017 11:47 AM
> To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, 
> Michael D <michael.d.kin...@intel.com>
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> <kevin.w.s...@intel.com>
> Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on 
> disk to be
> UTF-8 without a BOM
> 
> Tim,
> 
> If you look at the entire file history of the EDK II, you will see 
> that the BOM has always been present in the UTF-16LE formatted files.
> 
> The build tools were updated in 2015 to *add* support for UTF-8 file.
> The .uni files in the EDK II project were then converted from UTF-16LE 
> with a BOM to UTF-8 without a BOM.  This provided an easier developer 
> experience when using GIT to do email patch review of .uni files.
> 
> It is possible I am missing something here.  Can you please provide a 
> pointer to the EDK II commit(s) where BOMs were added to UTF-16LE .uni files.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > Sent: Wednesday, April 26, 2017 11:34 AM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>; 
> > edk2-devel@lists.01.org
> > Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> > <kevin.w.s...@intel.com>
> > Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files 
> > on disk to be
> > UTF-8 without a BOM
> >
> > Mike --
> >
> > I understand 

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Mike --

We select logos for SKU C (which is listed as having SKU A and DEFAULT) as its 
antecedents. If SKU C does not have a logo, then the SKU from SKU A is used. 
And if not from SKU A, then from DEFAULT.

Tim

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Wednesday, April 26, 2017 3:57 PM
To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star <star.z...@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Gao, Liming <liming@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Hi Tim,

How would this relationship information be used in a module?
Do you have an example use case where this relationship information could be 
used from the selected SKU?  Maybe there is a different method to solve the 
same problem?

Please also review the 2nd SKU related RFC titled:

[RFC 0/2] PCD: Extended SKU support 2 - sub SKU

This 2nd RFC builds on the first SKU RFC.  The SKU inheritance relationships 
are not as straight forward when you add the concept of generating all possible 
combinations of SKUs from multiple subsystems.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Wednesday, April 26, 2017 12:59 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star 
> <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming@intel.com>
> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Mike --
> 
> So your use case for SetSku() is also what we've used.
> 
> Generating a simple table that describes the default relationships 
> between SKUs is helpful:
> 
> DEFAULT
> A DEFAULT
> B A DEFAULT
> 
> This could be a #define in the form of a C UINT32 structure initializer:
> 
> #define SKUID_DEFAULT_ORDER 0,1,0,2,1,0
> 
> I think that this should be a part of this RFC.
> 
> -
> Having said that, we've used multi-SKU for a long time and there are 
> common error cases that could be aided by some tool support.
> 
> 1) When an image is designed to support SKUs A, B, C (out of a 
> possible set of SKU A-H), but the SKU detected is: G. This is an error 
> condition that is difficult to detect. SetSku() can't do it, because 
> there is no guarantee (today) that the PCD driver knows all possible 
> SKUs, only those that have PCDs associated with them.
> 
> 2) When C code is designed to run for SKUs A, B, D, H, the image was 
> built for A,B,C and the SKU detected during POST was D. By having a 
> macro that returns whether board X is supported, code which is not 
> used for the current build can be eliminated from the build. For 
> example. #define SKU_NAME_SUPPORTED(sku-
> identifier) can return FALSE if the SKU associated with sku-identifier 
> is not in the build.  Also useful for ASL and VFR.
> 
> 3) We have also found it useful to extend the build.exe command-line 
> to allow multiple instances of -x to correctly populate the SKUID_IDENTIFIER.
> 
> These might be the subject for additional RFCs.
> 
> Tim
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, April 26, 2017 12:04 PM
> To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star 
> <star.z...@intel.com>; edk2- de...@lists.01.org; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Cc: Gao, Liming <liming@intel.com>
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Hi Tim,
> 
> If multiple SKUs are present in a FW image, in most cases A platform 
> specific PEIM detects what SKU is present and calls SetSku() for the 
> detected SKU.  The detection mechanism is typically very HW specific 
> and may involve checking straps, GPIOs, or reading ID values from registers.
> 
> Before the SKU is set, PCD services access values from the DEFAULT SKU 
> (SKU ID 0).  After SetSku() is called, the PCD services access values 
> for that specific SKU.
> 
> What would be the runtime use case for being able to lookup the 
> relationships between SKUs if in a single boot only the DEFAULT SKU 
> and the one SKU passed to
> SetSku() are involved?
> 
> What additions do you suggest to this RFC or to another RFC that 
> builds on top of this RFC?
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Tim Lewis
> > Sent: Wednesday, April 26, 2017 11:46 AM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star 
> > <star.z...@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming@intel.co

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Mike --

So your use case for SetSku() is also what we've used. 

Generating a simple table that describes the default relationships between SKUs 
is helpful:

DEFAULT
A DEFAULT
B A DEFAULT

This could be a #define in the form of a C UINT32 structure initializer:

#define SKUID_DEFAULT_ORDER 0,1,0,2,1,0

I think that this should be a part of this RFC.

-
Having said that, we've used multi-SKU for a long time and there are common 
error cases that could be aided by some tool support.

1) When an image is designed to support SKUs A, B, C (out of a possible set of 
SKU A-H), but the SKU detected is: G. This is an error condition that is 
difficult to detect. SetSku() can't do it, because there is no guarantee 
(today) that the PCD driver knows all possible SKUs, only those that have PCDs 
associated with them.

2) When C code is designed to run for SKUs A, B, D, H, the image was built for 
A,B,C and the SKU detected during POST was D. By having a macro that returns 
whether board X is supported, code which is not used for the current build can 
be eliminated from the build. For example. #define 
SKU_NAME_SUPPORTED(sku-identifier) can return FALSE if the SKU associated with 
sku-identifier is not in the build.  Also useful for ASL and VFR.

3) We have also found it useful to extend the build.exe command-line to allow 
multiple instances of -x to correctly populate the SKUID_IDENTIFIER.

These might be the subject for additional RFCs.

Tim

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Wednesday, April 26, 2017 12:04 PM
To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star <star.z...@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Gao, Liming <liming@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Hi Tim,

If multiple SKUs are present in a FW image, in most cases A platform specific 
PEIM detects what SKU is present and calls SetSku() for the detected SKU.  The 
detection mechanism is typically very HW specific and may involve checking 
straps, GPIOs, or reading ID values from registers.

Before the SKU is set, PCD services access values from the DEFAULT SKU (SKU ID 
0).  After SetSku() is called, the PCD services access values for that specific 
SKU.
 
What would be the runtime use case for being able to lookup the relationships 
between SKUs if in a single boot only the DEFAULT SKU and the one SKU passed to 
SetSku() are involved?

What additions do you suggest to this RFC or to another RFC that builds on top 
of this RFC?

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Wednesday, April 26, 2017 11:46 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star 
> <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming@intel.com>
> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Mike --
> 
> I am saying that creating a relationship between SKUs that cannot be 
> determined at runtime is a confusing thing to add to the DSC.
> 
> Tim
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, April 26, 2017 11:40 AM
> To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star 
> <star.z...@intel.com>; edk2- de...@lists.01.org; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Cc: Gao, Liming <liming@intel.com>
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Tim,
> 
> This RFC does not change the DEFAULT behavior. If a PCD value override 
> is not provided in a SKU, then the DEFAULT value is used. If this is 
> not how you interpret the RFC, then please provide some clarifications 
> for the next revision of this RFC.
> 
> This RFC is about reducing the number of PCD statements in a DSC file 
> if there are multiple SKUs and if there is a relationship between SKUs 
> that can be used to support that reduction.  It is an optional new 
> feature.  You do not have to use it.
> 
> I consider the optimization of the PCD database from a size and 
> performance perspective a separate topic.  The implementation of this 
> RFC does not require any changes to the PCD database format or the way 
> PCD value lookup algorithm in the PCD drivers.
> 
> We do recognize that if a large number of SKUs with close 
> relationships are present in a single FW build, there may be more 
> optimal ways to store the data and more efficient ways to access the 
> data.  But we would like to consider any work in this area as a 
> separate work item.  Please feel free to add a Bugzilla feature 
> request if you have specific ideas on how to reduce size and/or improve 
> performance.
> 
> Given 

Re: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to be UTF-8 without a BOM

[Tim Lewis]

Mike --

This is not about files in the EDK II repository. This is about files created 
based on the spec, and created with other sets of tools. Go back to early 2015, 
to the Build spec (1.22, etc.), Appendix G, which is where the UNI stuff used 
to live.

The point is: files which worked before, and, at worst, generated a warning 
before, now are interpreted incorrectly even though they have correct data.

Making ASCII (or UTF-8) the default without a BOM is the breaking change.

Tim 

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Wednesday, April 26, 2017 11:47 AM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael 
D <michael.d.kin...@intel.com>
Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
<kevin.w.s...@intel.com>
Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to 
be UTF-8 without a BOM

Tim,

If you look at the entire file history of the EDK II, you will see that the BOM 
has always been present in the UTF-16LE formatted files.

The build tools were updated in 2015 to *add* support for UTF-8 file.
The .uni files in the EDK II project were then converted from UTF-16LE with a 
BOM to UTF-8 without a BOM.  This provided an easier developer experience when 
using GIT to do email patch review of .uni files.

It is possible I am missing something here.  Can you please provide a pointer 
to the EDK II commit(s) where BOMs were added to UTF-16LE .uni files.

Thanks,

Mike

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, April 26, 2017 11:34 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; 
> edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> <kevin.w.s...@intel.com>
> Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on 
> disk to be
> UTF-8 without a BOM
> 
> Mike --
> 
> I understand that EDK2 has decided to add BOM markers two years ago. 
> Adding a BOM didn't change the default. The problem is (a) there are 
> still hundreds of files extant in our codebase which were created 
> prior to the 2015 changes and still in use, and (b) this change is not 
> backward compatible for these files.
> 
> Tim
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, April 26, 2017 11:11 AM
> To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, 
> Michael D <michael.d.kin...@intel.com>
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> <kevin.w.s...@intel.com>
> Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on 
> disk to be
> UTF-8 without a BOM
> 
> Hi Tim,
> 
> This is not a request for a new change.  Instead, the intent of this 
> document change is to update the document to reflect the implemented 
> behavior of the EDK II tools.  The EDK II tool updates to add UTF-8 
> file support were completed with the patches listed below.  Notice 
> that the main one for normal build support was checked in almost 2 years ago.
> 
> BaseTools - UniClassObject - 6/23/2015
> *
> https://github.com/tianocore/edk2/commit/d80e451b187c9d33cbd771253fbd5
> 119670f75c6
> *
> https://github.com/tianocore/edk2/commit/be264422c95c781a345978f17b7e8
> 0b91f816eda
> 
> BaseTools - ECC - 12/29/2015
> *
> https://github.com/tianocore/edk2/commit/975889279df2eb3d3338cb88afb3f
> aa71ddde4d6
> 
> BaseTools - UPT - 4/25/2016
> *
> https://github.com/tianocore/edk2/commit/4a21fb3b67a0ef1655b43e9368b6b
> 697bbf327af
> 
> This was intended to be a 100% backwards compatible change.
> 
> All .uni files in the EDK II project in UTF-16LE format have always use a BOM.
> Please checkout UDK2015 or older UDKs and you will see all .uni files 
> start with 0xff 0xfe.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > Sent: Wednesday, April 26, 2017 9:15 AM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>; 
> > edk2-devel@lists.01.org
> > Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> > <kevin.w.s...@intel.com>
> > Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files 
> > on disk to be
> > UTF-8 without a BOM
> >
> > Mike --
> >
> > This breaks our existing build tools, which assume that a file 
> > without a BOM is UTF-16.
> >
> > Tim
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Michael Kinney
> > Sent: Tuesday, April 25, 2017 6:07 PM
> > To

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Mike --

I am saying that creating a relationship between SKUs that cannot be determined 
at runtime is a confusing thing to add to the DSC.

Tim

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Wednesday, April 26, 2017 11:40 AM
To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star <star.z...@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Gao, Liming <liming@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

This RFC does not change the DEFAULT behavior. If a PCD value override is not 
provided in a SKU, then the DEFAULT value is used. If this is not how you 
interpret the RFC, then please provide some clarifications for the next 
revision of this RFC.

This RFC is about reducing the number of PCD statements in a DSC file if there 
are multiple SKUs and if there is a relationship between SKUs that can be used 
to support that reduction.  It is an optional new feature.  You do not have to 
use it.

I consider the optimization of the PCD database from a size and performance 
perspective a separate topic.  The implementation of this RFC does not require 
any changes to the PCD database format or the way PCD value lookup algorithm in 
the PCD drivers.

We do recognize that if a large number of SKUs with close relationships are 
present in a single FW build, there may be more optimal ways to store the data 
and more efficient ways to access the data.  But we would like to consider any 
work in this area as a separate work item.  Please feel free to add a Bugzilla 
feature request if you have specific ideas on how to reduce size and/or improve 
performance.

Given that this RFC is only about a more efficient DSC file implementation.
Can you please describe your concerns with SKUs as they are currently 
documented in the EDK II specifications? If you have additional feature 
requests for the EDK II SKU behavior, then I look forward to seeing your 
detailed proposals.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Wednesday, April 26, 2017 11:24 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star 
> <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming@intel.com>
> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> 
> I understand the purpose. Today there is an assumption that IF not SKU 
> x, then use SKU DEFAULT. This assumption is used (by us) for many 
> purposes other than the PCD database.
> 
> I'm confused by your statement that "This RFC has no impact to the PCD 
> database or behavior of PCD services." Currently, as I recall, there 
> is an optimization that says: only the differences between SKU A/SKU B 
> and SKU DEFAULT must exist in the PCD database (SKU A and SKU B are 
> sparsely encoded). Are you saying that this proposed change will not, 
> in fact, optimize the PCD database for SKU B (that it will have the 
> full set of values that differ from SKU DEFAULT?) If so, it is a pity.
> 
> My other concern is that, we use the defaulting assumption for many other 
> items.
> For example: logos. Leaving it as a build-time construct only prevents 
> other components from taking advantage of this knowledge.
> 
> Tim
> 
> On a separate, but related topic, the term "SKU" has a broad 
> connotation, and we use it for many other items board-specific at build-time 
> and run-time (ie.
> Logos). Leaving the defaulting relationship as a build-time construct 
> prevents usage at runtime. This is similar run-time problem to the 
> case when (a) there are
> 10 SKUs listed in [SkuIds] but (b) 3 are listed in SKUID_IDENTIFIERS 
> for this particular build. How, at runtime, does C code pick up that 
> SkuA is supported in the current build?
> 
> 
> 
> 
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, April 26, 2017 11:05 AM
> To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star 
> <star.z...@intel.com>; edk2- de...@lists.01.org; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Cc: Gao, Liming <liming@intel.com>
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Tim,
> 
> Can you please provide more details on your specific concerns along 
> with some use cases?
> 
> This RFC does not change the SKU feature in EDK II.  This RFC simply 
> provides a more efficient way for a developer to provide PCD values 
> for different SKUs with fewer PCD statements in a DSC file.
> 
> Today, every SKU is a based on the DEFAULT SKU and if a PCD requires a 
> different value than the DEFAULT SKU value, then a SKU spe

Re: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to be UTF-8 without a BOM

[Tim Lewis]

Mike --

I understand that EDK2 has decided to add BOM markers two years ago. Adding a 
BOM didn't change the default. The problem is (a) there are still hundreds of 
files extant in our codebase which were created prior to the 2015 changes and 
still in use, and (b) this change is not backward compatible for these files. 

Tim

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Wednesday, April 26, 2017 11:11 AM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael 
D <michael.d.kin...@intel.com>
Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
<kevin.w.s...@intel.com>
Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to 
be UTF-8 without a BOM

Hi Tim,

This is not a request for a new change.  Instead, the intent of this document 
change is to update the document to reflect the implemented behavior of the EDK 
II tools.  The EDK II tool updates to add UTF-8 file support were completed 
with the patches listed below.  Notice that the main one for normal build 
support was checked in almost 2 years ago. 

BaseTools - UniClassObject - 6/23/2015
* 
https://github.com/tianocore/edk2/commit/d80e451b187c9d33cbd771253fbd5119670f75c6
* 
https://github.com/tianocore/edk2/commit/be264422c95c781a345978f17b7e80b91f816eda

BaseTools - ECC - 12/29/2015
* 
https://github.com/tianocore/edk2/commit/975889279df2eb3d3338cb88afb3faa71ddde4d6

BaseTools - UPT - 4/25/2016
* 
https://github.com/tianocore/edk2/commit/4a21fb3b67a0ef1655b43e9368b6b697bbf327af

This was intended to be a 100% backwards compatible change.

All .uni files in the EDK II project in UTF-16LE format have always use a BOM.
Please checkout UDK2015 or older UDKs and you will see all .uni files start 
with 0xff 0xfe.

Thanks,

Mike

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, April 26, 2017 9:15 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; 
> edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> <kevin.w.s...@intel.com>
> Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on 
> disk to be
> UTF-8 without a BOM
> 
> Mike --
> 
> This breaks our existing build tools, which assume that a file without 
> a BOM is UTF-16.
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Michael Kinney
> Sent: Tuesday, April 25, 2017 6:07 PM
> To: edk2-devel@lists.01.org
> Cc: Jaben Carsey <jaben.car...@intel.com>; Kevin W Shaw 
> <kevin.w.s...@intel.com>
> Subject: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk 
> to be UTF-
> 8 without a BOM
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=507
> 
> Cc: Jaben Carsey <jaben.car...@intel.com>
> Cc: Yonghong Zhu <yonghong@intel.com>
> Cc: Kevin W Shaw <kevin.w.s...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
> ---
>  2_unicode_strings_file_format.md |  9 ++---
>  README.md| 27 ++-
>  2 files changed, 20 insertions(+), 16 deletions(-)
> 
> diff --git a/2_unicode_strings_file_format.md 
> b/2_unicode_strings_file_format.md
> index 0150c85..7a4a019 100644
> --- a/2_unicode_strings_file_format.md
> +++ b/2_unicode_strings_file_format.md
> @@ -33,7 +33,8 @@
> 
>  EDK II Unicode files are used for mapping token names to localized 
> strings that are identified by an RFC4646 language code. The format 
> for storing EDK II - Unicode files is UTF-16LE. The character content must be 
> UCS-2.
> +Unicode files on disk is UTF-8 (without a BOM character) or UTF-16LE 
> +(with a BOM character). The character content must be UCS-2.
> 
>  Strings ends are determined by the first of the following items found:
> 
> @@ -44,11 +45,13 @@ Strings ends are determined by the first of the 
> following items found:
> 
>  Comments may appear anywhere within the string file.
> 
> -All the files must begin with a Unicode BOM character.
> +All UTF-16LE files must begin with a Unicode BOM character.
> +All UTF-8 files must not begin with a Unicode BOM character.
> 
>  **
>  **NOTE:** Please make sure you select an editor that supports UCS-2 
> characters - that can be stored in a UTF-16LE file.
> +that can be stored in either a UTF-8 (without a BOM character) or a 
> +UTF-16LE file (with a BOM character).
>  **
> 
>  ## 2.1 Common EBNF
> diff --git a/README.md b/README.md
> index 63842a1..015aef1 100644
> --- a/README.md
> +++ b/README.md
> @@ -77,16 +77,17 @@ Copyright (c) 2016-2017, Intel Corporat

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

I understand the purpose. Today there is an assumption that IF not SKU x, then 
use SKU DEFAULT. This assumption is used (by us) for many purposes other than 
the PCD database.

I'm confused by your statement that "This RFC has no impact to the PCD database 
or behavior of PCD services." Currently, as I recall, there is an optimization 
that says: only the differences between SKU A/SKU B and SKU DEFAULT must exist 
in the PCD database (SKU A and SKU B are sparsely encoded). Are you saying that 
this proposed change will not, in fact, optimize the PCD database for SKU B 
(that it will have the full set of values that differ from SKU DEFAULT?) If so, 
it is a pity.

My other concern is that, we use the defaulting assumption for many other 
items. For example: logos. Leaving it as a build-time construct only prevents 
other components from taking advantage of this knowledge.

Tim

On a separate, but related topic, the term "SKU" has a broad connotation, and 
we use it for many other items board-specific at build-time and run-time (ie. 
Logos). Leaving the defaulting relationship as a build-time construct prevents 
usage at runtime. This is similar run-time problem to the case when (a) there 
are 10 SKUs listed in [SkuIds] but (b) 3 are listed in SKUID_IDENTIFIERS for 
this particular build. How, at runtime, does C code pick up that SkuA is 
supported in the current build?





-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Wednesday, April 26, 2017 11:05 AM
To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star <star.z...@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Gao, Liming <liming@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

Can you please provide more details on your specific concerns along with some 
use cases?

This RFC does not change the SKU feature in EDK II.  This RFC simply provides a 
more efficient way for a developer to provide PCD values for different SKUs 
with fewer PCD statements in a DSC file.

Today, every SKU is a based on the DEFAULT SKU and if a PCD requires a 
different value than the DEFAULT SKU value, then a SKU specific PCD statement 
is required. 

With this proposal, a relationship between SKUs can be declared in the DSC 
file, so SKUs can inherit PCD values from other SKUs.  This inheritance is 
limited to the scope of the DSC file.  This RFC has no impact to the PCD 
database or behavior of PCD services.

The example Star provides at the end shows the equivalent set of PCD settings 
using the current EDK II syntax and with this RFC's backwards compatible syntax 
extensions.

One way to think about this RFC is that a DSC file using the syntax in this RFC 
can be converted to a DSC file without the RFC syntax.  In fact, that is what 
the implementation of this RFC would do to build the set of PCD values for each 
SKU.
 
Thanks,

Mike



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Wednesday, April 26, 2017 9:21 AM
> To: Zeng, Star <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming 
> <liming@intel.com>
> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Star --
> 
> This assumes that the SKU ID is only used for PCDs, which is not the 
> case. The SKU ID may be used by other components, and other components 
> may use the
> 0|DEFAULT rule as well.
> 
> 1) There is no way to read this defaulting rule at runtime. The 
> information is buried in the PCD database, but not available externally.
> 2) There is no way to read the contents of SKUID_IDENTIFIER when 
> multiple SKUs are specified. While more than one SKU can be specified 
> (separated by spaces), there is no way to pass multiple values into 
> build.exe today, nor is there any way to identify which SKUs (out of 
> the total list of SKUs) is supported on one build at runtime.
> 
> Tim
> 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Zeng, Star
> Sent: Tuesday, April 25, 2017 5:40 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star 
> <star.z...@intel.com>; Gao, Liming <liming@intel.com>
> Subject: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> 
> - Requirement
> Simplify the PCDs configuring for multiple SKUs in DSC.
> 
> 
> - Current limitation
> Non-DEFAULT SKU could only derive from DEFAULT SKU, but could not 
> derive from another non-DEFAULT SKU.
> For example below, SkuA and SkuB could only derive from DEFAULT, but 
> SkuB could not derive from SkuA.
> 
> [SkuIds]
>   0 | DEFAULT
>   

Re: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to be UTF-8 without a BOM

[Tim Lewis]

The original UNI specifications (for example, the Multi-String .UNI File Format 
Specification, February 2014, Revision 1.0) did not require it, and the fact is 
that tools accept files without the BOM happily today.

I believe that requiring the BOM is a good step forward, but assuming UTF-8 
when one is not present won't help the vast quantities of existing UNI files 
out there.

Tim

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com] 
Sent: Wednesday, April 26, 2017 10:45 AM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Shaw, Kevin W <kevin.w.s...@intel.com>
Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk to 
be UTF-8 without a BOM

Tim, 

Doesn't that assumption/behavior violate the current spec?
"All the files must begin with a Unicode BOM character."

-Jaben

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, April 26, 2017 9:15 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2- 
> de...@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W 
> <kevin.w.s...@intel.com>
> Subject: RE: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on 
> disk to be UTF-8 without a BOM
> Importance: High
> 
> Mike --
> 
> This breaks our existing build tools, which assume that a file without 
> a BOM is UTF-16.
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Michael Kinney
> Sent: Tuesday, April 25, 2017 6:07 PM
> To: edk2-devel@lists.01.org
> Cc: Jaben Carsey <jaben.car...@intel.com>; Kevin W Shaw 
> <kevin.w.s...@intel.com>
> Subject: [edk2] [edk2-UniSpecification PATCH] Allow .uni files on disk 
> to be
> UTF-8 without a BOM
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=507
> 
> Cc: Jaben Carsey <jaben.car...@intel.com>
> Cc: Yonghong Zhu <yonghong@intel.com>
> Cc: Kevin W Shaw <kevin.w.s...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
> ---
>  2_unicode_strings_file_format.md |  9 ++---
>  README.md| 27 ++-
>  2 files changed, 20 insertions(+), 16 deletions(-)
> 
> diff --git a/2_unicode_strings_file_format.md
> b/2_unicode_strings_file_format.md
> index 0150c85..7a4a019 100644
> --- a/2_unicode_strings_file_format.md
> +++ b/2_unicode_strings_file_format.md
> @@ -33,7 +33,8 @@
> 
>  EDK II Unicode files are used for mapping token names to localized 
> strings that  are identified by an RFC4646 language code. The format 
> for storing EDK II -Unicode files is UTF-16LE. The character content must be 
> UCS-2.
> +Unicode files on disk is UTF-8 (without a BOM character) or UTF-16LE 
> +(with a BOM character). The character content must be UCS-2.
> 
>  Strings ends are determined by the first of the following items found:
> 
> @@ -44,11 +45,13 @@ Strings ends are determined by the first of the 
> following items found:
> 
>  Comments may appear anywhere within the string file.
> 
> -All the files must begin with a Unicode BOM character.
> +All UTF-16LE files must begin with a Unicode BOM character.
> +All UTF-8 files must not begin with a Unicode BOM character.
> 
>  **
>  **NOTE:** Please make sure you select an editor that supports UCS-2 
> characters -that can be stored in a UTF-16LE file.
> +that can be stored in either a UTF-8 (without a BOM character) or a 
> +UTF-16LE file (with a BOM character).
>  **
> 
>  ## 2.1 Common EBNF
> diff --git a/README.md b/README.md
> index 63842a1..015aef1 100644
> --- a/README.md
> +++ b/README.md
> @@ -77,16 +77,17 @@ Copyright (c) 2016-2017, Intel Corporation. All 
> rights reserved.
> 
>  ### Revision History
> 
> -| Revision  | Description
>   | Date
> |
> -| - | 
> -| ---
> -| 
> - | --- |
> -| 1.0   | Initial Release.   
>   | February
> 2014   |
> -| 1.1   | Updated EBNF to follow syntax specified in EBNF by the 
> ANTLR
> project.| August 2014 |
> -|   | Added content related to EDK II Meta-Data Unicode 
> files.
> | |
> -|   | Restructured document. 
>   

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Star --

This assumes that the SKU ID is only used for PCDs, which is not the case. The 
SKU ID may be used by other components, and other components may use the 
0|DEFAULT rule as well. 

1) There is no way to read this defaulting rule at runtime. The information is 
buried in the PCD database, but not available externally.
2) There is no way to read the contents of SKUID_IDENTIFIER when multiple SKUs 
are specified. While more than one SKU can be specified (separated by spaces), 
there is no way to pass multiple values into build.exe today, nor is there any 
way to identify which SKUs (out of the total list of SKUs) is supported on one 
build at runtime.

Tim


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, 
Star
Sent: Tuesday, April 25, 2017 5:40 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Zeng, Star 
; Gao, Liming 
Subject: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

- Requirement
Simplify the PCDs configuring for multiple SKUs in DSC.


- Current limitation
Non-DEFAULT SKU could only derive from DEFAULT SKU, but could not derive from 
another non-DEFAULT SKU.
For example below, SkuA and SkuB could only derive from DEFAULT, but SkuB could 
not derive from SkuA.

[SkuIds]
  0 | DEFAULT
  1 | SkuA
  2 | SkuB


- Proposal: One non-DEFAULT SKU could be a derivative of another non-DEFAULT 
SKU.
This proposal only extends DSC [SkuIds] section syntax and the extension is 
optional.
This proposal keeps the backward compatibility with current SKU usage.
BaseTools update is needed to support the syntax extension, and no any change 
in PCD database and driver is required.

DSC syntax:
  [SkuIds]
SkuValue|SkuName[|ParentSkuName]
  SkuValue: integer, 0 is reserved for DEFAULT SKU.
  SkuName: string
  ParentSkuName: string, optional, it is new introduced in this proposal 
and defines which SKU the PCD value will derive from for this SKU. The PCD 
value will derive from DEFAULT SKU for this SKU if the ParentSkuName is absent.


- Example: SkuB is a derivative of SkuA, but not a derivative of DEFAULT.

  [SkuIds]
0 | DEFAULT
1 | SkuA
2 | SkuB | SkuA

  [PcdsDynamicDefault.Common.DEFAULT]
gXXXPkgTokenSpaceGuid.PcdXXXSignature|"DEFAULT"
gXXXPkgTokenSpaceGuid.PcdXXXConfig1|FALSE
gXXXPkgTokenSpaceGuid.PcdXXXConfig2|FALSE
gXXXPkgTokenSpaceGuid.PcdXXXConfig3|FALSE

  [PcdsDynamicDefault.Common.SkuA]
gXXXPkgTokenSpaceGuid.PcdXXXSignature|"SkuA"
gXXXPkgTokenSpaceGuid.PcdXXXConfig1|TRUE
gXXXPkgTokenSpaceGuid.PcdXXXConfig2|TRUE
# No need statement for PcdXXXConfig3 whose value will derive from DEFAULT 
SKU and be FLASE.
 
  [PcdsDynamicDefault.Common.SkuB]
gXXXPkgTokenSpaceGuid.PcdXXXSignature|" SkuB"
# No need statement for PcdXXXConfig1 and PcdXXXConfig2 whose values will 
derive from SkuA SKU and be TRUE.
gXXXPkgTokenSpaceGuid.PcdXXXConfig3|TRUE
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol

[Tim Lewis]

There are "load options" that are passed to drivers (as a part of the 
EFI_LOADED_IMAGE_PROTOCOL), but there is no guarantee as to their format 
(binary data or ASCII string or UCS-2 string). It is possible for "load" to be 
modified to create this data and populate it between the calls to LoadImage() 
and StartImage() as the shell does, but that isn't spec.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
jim.dai...@dell.com
Sent: Wednesday, April 05, 2017 8:21 AM
To: jaben.car...@intel.com; ruiyu...@intel.com
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol

Thanks, Jaben. That makes sense.

Now I see the real issue is with the "app" I ran across.  It is a driver, and 
it was trying to access command line args.  The driver crashed when it tried to 
access the command line, but it had been loaded in memory via the "load" 
command.

So, it seems "load" has no mechanism to pass command line arguments to a 
driver, and as a result, it apparently doesn't load the shell parameters 
protocol on the driver's handle, which caused the crash.

Regards,
Jim

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Wednesday, April 5, 2017 10:08 AM
To: Dailey, Jim ; Ni, Ruiyu 
Cc: edk2-devel@lists.01.org
Subject: RE: UEFI Shell Lib Constructor and Shell Parameters Protocol

Jim,

That protocol must be installed on your applications own image handle for it to 
be valid.  Locating the protocol on some other image would result with finding 
the other image's command line parameters and the like...

-Jaben


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> jim.dai...@dell.com
> Sent: Wednesday, April 05, 2017 7:07 AM
> To: Carsey, Jaben ; Ni, Ruiyu 
> 
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] UEFI Shell Lib Constructor and Shell Parameters 
> Protocol
> Importance: High
> 
> 
> A question or two for all shell experts:
> 
> In the UEFI Shell Lib constructor code, if the Shell protocol cannot 
> be opened, then an attempt is made to locate it before "giving up".
> 
> However, if the Shell parameters protocol cannot be opened, no attempt 
> is made to locate it---the code simply leaves the parameters protocol 
> pointer set to NULL. Can anyone explain why this is?
> 
> I came across an app that crashes because of this behavior, but if I 
> add code to try and locate the parameters protocol, then the app works 
> as designed WRT accessing command line parameters.  Is there some 
> lurking issue if an attempt to locate the parameters protocol is made 
> and is successful?
> 
> Thanks,
> Jim
> 
> ---
> Here is the relevant code:
> 
> EFI_STATUS
> ShellLibConstructorWorker (
>   IN EFI_HANDLEImageHandle,
>   IN EFI_SYSTEM_TABLE  *SystemTable
>   )
> {
>   EFI_STATUS  Status;
> 
>   //
>   // UEFI 2.0 shell interfaces (used preferentially)
>   //
>   Status = gBS->OpenProtocol(
> ImageHandle,
> ,
> (VOID **),
> ImageHandle,
> NULL,
> EFI_OPEN_PROTOCOL_GET_PROTOCOL
>);
>   if (EFI_ERROR(Status)) {
> //
> // Search for the shell protocol
> //
> Status = gBS->LocateProtocol(
>   ,
>   NULL,
>   (VOID **)
>  );
> if (EFI_ERROR(Status)) {
>   gEfiShellProtocol = NULL;
> }
>   }
>   Status = gBS->OpenProtocol(
> ImageHandle,
> ,
> (VOID **),
> ImageHandle,
> NULL,
> EFI_OPEN_PROTOCOL_GET_PROTOCOL
>);
>   if (EFI_ERROR(Status)) {
> #if 1 // _Dell_ : Search for the parameters protocol too!
> //
> // Search for the shell parameters protocol
> //
> Status = gBS->LocateProtocol(
>   ,
>   NULL,
>   (VOID **)
>  );
> if (EFI_ERROR(Status)) {
>   gEfiShellParametersProtocol = NULL;
> }
> #else
> gEfiShellParametersProtocol = NULL; #endif
>   }
> ...
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Print from DXE_DRIVER

[Tim Lewis]

Also, on many systems, the output will be invisible, since boot screen output 
is a platform policy. In general, using DEBUG() is better, since it can either 
be redirected to StdErr() or through the serial port.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Rebecca 
Cran
Sent: Wednesday, February 08, 2017 6:56 PM
To: Andrew Fish 
Cc: edk2-de...@ml01.01.org; David A. Van Arnem 
Subject: Re: [edk2] Print from DXE_DRIVER


> On Feb 8, 2017, at 5:43 PM, Andrew Fish  wrote:
> 
> If  you want to write directly to the UEFI Console you can try this. Place it 
> in the entry point of your driver in case you have some bug that is 
> preventing your from registering the Driver Binding Protocol. 
> 
> gST->ConOut->OutputString (gST->ConOut, L"Hello World\n\r");

Note that on some systems, at some times gST->ConOut may be NULL, so it might 
be worth checking before calling it (unless you know otherwise on your dev 
system).

-- 
Rebecca
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS spec 3.1.1

[Tim Lewis]

In our case, the main firmware is multi-lingual, but the shell is mono-lingual, 
and they are built together. The reason is: setup users require more 
user-friendly than shell users in our experience.

Tim

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com] 
Sent: Monday, January 23, 2017 1:59 PM
To: Tim Lewis <tim.le...@insyde.com>; Ni, Ruiyu <ruiyu...@intel.com>; Zeng, 
Star <star.z...@intel.com>; edk2-devel@lists.01.org
Cc: Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS spec 3.1.1

I was wondering if some replaced version of HiiLib could use the StrDefs.h 
differently and save the overhead if only one language is present...

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Monday, January 23, 2017 1:57 PM
> To: Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu 
> <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>; 
> edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 3/3] ShellPkg SmbiosView: Add decoding of 
> SMBIOS spec 3.1.1
> Importance: High
> 
> We have not found a good solution for handling this automatically, 
> although we have toyed with alternate ways to process the .uni file to 
> create string literals with the StrDefs.h #defines and alternate 
> versions of the ShellLib functions that use them.
> 
> Tim
> 
> -Original Message-
> From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> Sent: Monday, January 23, 2017 1:48 PM
> To: Tim Lewis <tim.le...@insyde.com>; Ni, Ruiyu <ruiyu...@intel.com>; 
> Zeng, Star <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>
> Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS 
> spec
> 3.1.1
> 
> Tim,
> 
> I meant some customers do localize the shell and we don't want to 
> arbitrarily restrict that.
> 
> Do you have any ideas on how to remove the overhead when localization 
> is not required?
> 
> -Jaben
> 
> > -Original Message-
> > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > Sent: Monday, January 23, 2017 1:25 PM
> > To: Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu 
> > <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>; 
> > edk2-devel@lists.01.org
> > Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS 
> > spec
> > 3.1.1
> > Importance: High
> >
> > Jaben --
> >
> > I don't know exactly what you mean by each "compiler of the shell". 
> > I do know that HII strings and HII string handling add the largest 
> > discretionary, non-spec- required overhead to the Shell executable 
> > (based on our production mini- shell vs. the EDK2 shell) even 
> > without any second language.  I understand it as a design goal of 
> > the EDK2 shell to allow localization (although it does not actually 
> > do any itself). I also understand that it is easier to enforce the 
> > strings- in-uni rule as an absolute. But it does come with a cost 
> > for those who want
> to use a fully functional shell in a much more restricted environment.
> >
> >
> > Tim
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Carsey, Jaben
> > Sent: Monday, January 23, 2017 1:15 PM
> > To: Tim Lewis <tim.le...@insyde.com>; Ni, Ruiyu 
> > <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>; 
> > edk2-devel@lists.01.org
> > Cc: Carsey, Jaben <jaben.car...@intel.com>
> > Subject: Re: [edk2] [PATCH 3/3] ShellPkg SmbiosView: Add decoding of 
> > SMBIOS spec 3.1.1
> >
> > Tim,
> >
> > I agree that some strings are directly from SMBIOS or UEFI 
> > specifications and are not needed to be localized.
> >
> > Is there a disadvantage to allowing each compiler of the shell to 
> > make that an individual decision?
> >
> > In either case, it might be worthwhile to verify that all of the 
> > embedded strings meet that criterion.
> >
> > -Jaben
> >
> > > -Original Message-
> > > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > > Sent: Monday, January 23, 2017 12:52 PM
> > > To: Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu 
> > > <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>; edk2- 
> > > de...@lists.01.org
> > > Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of 
> > > SMBIOS spec 3.1.1
> > > Importance: Hig

Re: [edk2] [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS spec 3.1.1

[Tim Lewis]

We have not found a good solution for handling this automatically, although we 
have toyed with alternate ways to process the .uni file to create string 
literals with the StrDefs.h #defines and alternate versions of the ShellLib 
functions that use them. 

Tim

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com] 
Sent: Monday, January 23, 2017 1:48 PM
To: Tim Lewis <tim.le...@insyde.com>; Ni, Ruiyu <ruiyu...@intel.com>; Zeng, 
Star <star.z...@intel.com>; edk2-devel@lists.01.org
Cc: Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS spec 3.1.1

Tim,

I meant some customers do localize the shell and we don't want to arbitrarily 
restrict that.

Do you have any ideas on how to remove the overhead when localization is not 
required?

-Jaben

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Monday, January 23, 2017 1:25 PM
> To: Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu 
> <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>; 
> edk2-devel@lists.01.org
> Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS 
> spec
> 3.1.1
> Importance: High
> 
> Jaben --
> 
> I don't know exactly what you mean by each "compiler of the shell". I 
> do know that HII strings and HII string handling add the largest 
> discretionary, non-spec- required overhead to the Shell executable 
> (based on our production mini- shell vs. the EDK2 shell) even without 
> any second language.  I understand it as a design goal of the EDK2 
> shell to allow localization (although it does not actually do any 
> itself). I also understand that it is easier to enforce the strings- 
> in-uni rule as an absolute. But it does come with a cost for those who want 
> to use a fully functional shell in a much more restricted environment.
> 
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Carsey, Jaben
> Sent: Monday, January 23, 2017 1:15 PM
> To: Tim Lewis <tim.le...@insyde.com>; Ni, Ruiyu <ruiyu...@intel.com>; 
> Zeng, Star <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>
> Subject: Re: [edk2] [PATCH 3/3] ShellPkg SmbiosView: Add decoding of 
> SMBIOS spec 3.1.1
> 
> Tim,
> 
> I agree that some strings are directly from SMBIOS or UEFI 
> specifications and are not needed to be localized.
> 
> Is there a disadvantage to allowing each compiler of the shell to make 
> that an individual decision?
> 
> In either case, it might be worthwhile to verify that all of the 
> embedded strings meet that criterion.
> 
> -Jaben
> 
> > -Original Message-
> > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > Sent: Monday, January 23, 2017 12:52 PM
> > To: Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu 
> > <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>; edk2- 
> > de...@lists.01.org
> > Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS 
> > spec 3.1.1
> > Importance: High
> >
> > Also, in some cases, the text is taken directly from the specification.
> > Introducing HII strings in order to make these translatable when the 
> > source material is normative doesn't help, IMO.
> >
> > Tim
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Carsey, Jaben
> > Sent: Monday, January 23, 2017 9:41 AM
> > To: Ni, Ruiyu <ruiyu...@intel.com>; Zeng, Star 
> > <star.z...@intel.com>;
> > edk2- de...@lists.01.org
> > Cc: Carsey, Jaben <jaben.car...@intel.com>
> > Subject: Re: [edk2] [PATCH 3/3] ShellPkg SmbiosView: Add decoding of 
> > SMBIOS spec 3.1.1
> >
> > Reviewed-by: Jaben Carsey <jaben.car...@intel.com>
> >
> > I think that string mixed use existed in the EDK version of the 
> > command and was just never removed.
> >
> > -Jaben
> >
> > > -Original Message-
> > > From: Ni, Ruiyu
> > > Sent: Sunday, January 22, 2017 1:49 AM
> > > To: Zeng, Star <star.z...@intel.com>; edk2-devel@lists.01.org
> > > Cc: Carsey, Jaben <jaben.car...@intel.com>
> > > Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of 
> > > SMBIOS spec 3.1.1
> > > Importance: High
> > >
> > > Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>
> > >
> > > Thanks/Ray
> > >
> > > > -Original Message-
> > > > From: Zeng, Star
> &g

Re: [edk2] [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS spec 3.1.1

[Tim Lewis]

Jaben --

I don't know exactly what you mean by each "compiler of the shell". I do know 
that HII strings and HII string handling add the largest discretionary, 
non-spec-required overhead to the Shell executable (based on our production 
mini-shell vs. the EDK2 shell) even without any second language.  I understand 
it as a design goal of the EDK2 shell to allow localization (although it does 
not actually do any itself). I also understand that it is easier to enforce the 
strings-in-uni rule as an absolute. But it does come with a cost for those who 
want to use a fully functional shell in a much more restricted environment.


Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Monday, January 23, 2017 1:15 PM
To: Tim Lewis <tim.le...@insyde.com>; Ni, Ruiyu <ruiyu...@intel.com>; Zeng, 
Star <star.z...@intel.com>; edk2-devel@lists.01.org
Cc: Carsey, Jaben <jaben.car...@intel.com>
Subject: Re: [edk2] [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS 
spec 3.1.1

Tim,

I agree that some strings are directly from SMBIOS or UEFI specifications and 
are not needed to be localized.  

Is there a disadvantage to allowing each compiler of the shell to make that an 
individual decision?

In either case, it might be worthwhile to verify that all of the embedded 
strings meet that criterion.

-Jaben

> -----Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Monday, January 23, 2017 12:52 PM
> To: Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu 
> <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>; edk2- 
> de...@lists.01.org
> Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS 
> spec 3.1.1
> Importance: High
> 
> Also, in some cases, the text is taken directly from the specification.
> Introducing HII strings in order to make these translatable when the 
> source material is normative doesn't help, IMO.
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Carsey, Jaben
> Sent: Monday, January 23, 2017 9:41 AM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>; 
> edk2- de...@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>
> Subject: Re: [edk2] [PATCH 3/3] ShellPkg SmbiosView: Add decoding of 
> SMBIOS spec 3.1.1
> 
> Reviewed-by: Jaben Carsey <jaben.car...@intel.com>
> 
> I think that string mixed use existed in the EDK version of the 
> command and was just never removed.
> 
> -Jaben
> 
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Sunday, January 22, 2017 1:49 AM
> > To: Zeng, Star <star.z...@intel.com>; edk2-devel@lists.01.org
> > Cc: Carsey, Jaben <jaben.car...@intel.com>
> > Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS 
> > spec 3.1.1
> > Importance: High
> >
> > Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>
> >
> > Thanks/Ray
> >
> > > -Original Message-
> > > From: Zeng, Star
> > > Sent: Sunday, January 22, 2017 5:25 PM
> > > To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> > > Cc: Carsey, Jaben <jaben.car...@intel.com>; Zeng, Star 
> > > <star.z...@intel.com>
> > > Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of 
> > > SMBIOS spec 3.1.1
> > >
> > > Ray & Jaben,
> > >
> > > I am not so sure about the rule.
> > > The mixed using of strings in c code and strings in uni file has 
> > > been there since it was created.
> > >
> > >
> > > Thanks,
> > > Star
> > > -Original Message-
> > > From: Ni, Ruiyu
> > > Sent: Sunday, January 22, 2017 4:56 PM
> > > To: Zeng, Star <star.z...@intel.com>; edk2-devel@lists.01.org
> > > Cc: Carsey, Jaben <jaben.car...@intel.com>
> > > Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of 
> > > SMBIOS spec 3.1.1
> > >
> > > Star,
> > > Why some strings are hardcoded in C file while some are defined in 
> > > UNI
> > file?
> > > What's the rule?
> > >
> > > Thanks/Ray
> > >
> > > > -Original Message-
> > > > From: Zeng, Star
> > > > Sent: Sunday, January 22, 2017 4:18 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Zeng, Star <star.z...@intel.com>; Ni, Ruiyu 
> > > > <ruiyu...@intel.com>; Carsey, Jaben <jaben.car...@intel.com>
> > > > Subject: [PATCH 3/3] ShellPkg 

Re: [edk2] [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS spec 3.1.1

[Tim Lewis]

Also, in some cases, the text is taken directly from the specification. 
Introducing HII strings in order to make these translatable when the source 
material is normative doesn't help, IMO.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Monday, January 23, 2017 9:41 AM
To: Ni, Ruiyu ; Zeng, Star ; 
edk2-devel@lists.01.org
Cc: Carsey, Jaben 
Subject: Re: [edk2] [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS 
spec 3.1.1

Reviewed-by: Jaben Carsey 

I think that string mixed use existed in the EDK version of the command and was 
just never removed.

-Jaben

> -Original Message-
> From: Ni, Ruiyu
> Sent: Sunday, January 22, 2017 1:49 AM
> To: Zeng, Star ; edk2-devel@lists.01.org
> Cc: Carsey, Jaben 
> Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS 
> spec 3.1.1
> Importance: High
> 
> Reviewed-by: Ruiyu Ni 
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Sunday, January 22, 2017 5:25 PM
> > To: Ni, Ruiyu ; edk2-devel@lists.01.org
> > Cc: Carsey, Jaben ; Zeng, Star 
> > 
> > Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS 
> > spec 3.1.1
> >
> > Ray & Jaben,
> >
> > I am not so sure about the rule.
> > The mixed using of strings in c code and strings in uni file has 
> > been there since it was created.
> >
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Sunday, January 22, 2017 4:56 PM
> > To: Zeng, Star ; edk2-devel@lists.01.org
> > Cc: Carsey, Jaben 
> > Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS 
> > spec 3.1.1
> >
> > Star,
> > Why some strings are hardcoded in C file while some are defined in 
> > UNI
> file?
> > What's the rule?
> >
> > Thanks/Ray
> >
> > > -Original Message-
> > > From: Zeng, Star
> > > Sent: Sunday, January 22, 2017 4:18 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Zeng, Star ; Ni, Ruiyu 
> > > ; Carsey, Jaben 
> > > Subject: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS
> spec
> > > 3.1.1
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=349
> > >
> > > Cc: Ruiyu Ni 
> > > Cc: Jaben Carsey 
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Star Zeng 
> > > ---
> > >  .../SmbiosView/PrintInfo.c |  6 +++-
> > >  .../SmbiosView/QueryTable.c| 37
> ++
> > >  .../SmbiosView/QueryTable.h| 14 +++-
> > >  .../SmbiosView/SmbiosViewStrings.uni   |  3 +-
> > >  4 files changed, 57 insertions(+), 3 deletions(-)
> > >
> > > diff --git
> > >
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> > >
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> > > index ecb8e2492453..1d6002b92593 100644
> > > ---
> > >
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> > > +++
> > >
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> > > @@ -1106,7 +1106,7 @@ SmbiosPrintStructure (
> > >// Management Controller Host Interface (Type 42)
> > >//
> > >case 42:
> > > -PRINT_STRUCT_VALUE_H (Struct, Type42, InterfaceType);
> > > +DisplayMCHostInterfaceType (Struct->Type42->InterfaceType, 
> > > + Option);
> > >  break;
> > >
> > >//
> > > @@ -1818,6 +1818,10 @@ DisplayProcessorFamily (
> > >  Print (L"AMD Opteron(TM) X3000 Series APU\n");
> > >  break;
> > >
> > > +  case 0x6B:
> > > +Print (L"AMD Zen Processor Family\n");
> > > +break;
> > > +
> > >case 0x70:
> > >  ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN
> > > (STR_SMBIOSVIEW_PRINTINFO_HOBBIT_FAMILY),
> gShellDebug1HiiHandle);
> > >  break;
> > > diff --git
> > >
> >
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> > > c
> > >
> >
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> > > c
> > > index 4a06c12e3b2b..282ba584c8c9 100644
> > > ---
> > >
> >
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> > > c
> > > +++
> > >
> >
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> > > +++ c
> > > @@ -575,6 +575,10 @@ TABLE_ITEM  ProcessorUpgradeTable[] = {
> > >{
> > >  0x37,
> > >  L"Socket SP3"
> > > +  },
> > > +  {
> > > +0x38,
> > > +L"Socket SP3r2"
> > >}
> > >  };
> > >
> > > @@ -3156,6 +3160,22 @@ TABLE_ITEM  IPMIDIBMCInterfaceTypeTable[]
> =
> > {
> > >},
> > >  };
> > >
> > > +TABLE_ITEM  MCHostInterfaceTypeTable[] 

Re: [edk2] [shell] Pipe causes pool failure in Shell.c

[Tim Lewis]

Jaben --

I'm not sure. In the debugger, it clearly showed the memory as having already 
been freed at the pointer. But I didn't track down who had done it.

Tim

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com] 
Sent: Friday, December 02, 2016 8:39 AM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [shell] Pipe causes pool failure in Shell.c

Does that leak memory?  It looks like that memory was allocated at 1720, then 
moved from Out to In at 1729-1735.

Did the pointer possibly get mangled at 1724 or somewhere in between?

Ray,  Have you seen this?

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Thursday, December 01, 2016 11:45 PM
> To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org
> Subject: [edk2] [shell] Pipe causes pool failure in Shell.c
> Importance: High
> 
> After looking further, it appears that the FreePool() call on line 
> 1756 is unnecessary, and just causes a breakpoint.
> 
> Removing it allows the functionality to work correctly.
> 
> //FreePool (Split->SplitStdIn);
> 
> 
> Tim
> -Original Message-----
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Thursday, December 01, 2016 5:48 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Pipe causes pool failure in Shell.c
> 
> Using the latest Shell build, try:
> 
> ls -sfo | parse FileInfo 2
> 
> This ends up with a breakpoint when FreePool is called on Shell.c, line 1756.
> 
> I'm still debugging, but I wondered if anyone else has seen this?
> 
> Also:
> 
> ls -sfo > tmp
> parse FileInfo 2 < tmp
> 
> prints nothing, but
> 
> parse tmp FileInfo 2
> 
> works fine.
> 
> Tim
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [shell] shift generates errors with no command-line options

[Tim Lewis]

In a script that looks like this:

:start
if not %1 == "" then
  echo %1
  shift
  goto start
endif

'shift' will generate an error message. The spec doesn't describe any behavior 
like this and it is annoying to write scripts that must avoid it.

Of course you can work around it...

Tim
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [shell] @ does not work before if, endif, for and many other command.

[Tim Lewis]

Try this:

:start
@if %1 == ""  then
  @goto Done
@endif
  @echo Parameter: %1
  @shift
  goto start
:Done

Per Chapter 4

Also, additional '@' before a command in a script file can prevent the current 
command from being echoed.


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [shell] Redirected Environment Variables Are Not Saved Correctly

[Tim Lewis]

Test by doing this, immediately after booting:

Notice that echo has created a new environment variable _key to the value 4, 
But this variable does not show up when running "set"

Why? It is because the FileHandleWrappers does not use SetEnvironmentVariable. 
Instead, it tries to read and write the UEFI variable directly. But this method 
does not update the internal list of environment variables maintained by the 
Shell Protocol API.

This causes a lot of issues, because the results of any console redirection to 
an environment variable is not immediately visible.

Tim

[cid:image001.png@01D24C37.475327F0]
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Root Cause of Parse Failure With Redirected Input

[Tim Lewis]

  if (StrStr (TempLine, L"ShellCommand,") == TempLine) {
LoopVariable++;
  }

This line fails because, with redirected input, the file has the UCS-2 byte 
order mark, so the string "ShellCommand," is not at the beginning of the line. 
With the file, the byte order mark is not present.

Why?

 if (StreamingUnicode) {
   TempLine = ParseReturnStdInLine (FileHandle);
 } else {
   TempLine = ShellFileHandleReturnLine (FileHandle, );
 }

The Shell library function ShellFileHandleReturnLine will strip off the byte 
order mark. But the ParseReturnStdInLine does not. So the first character on 
the line is not 'S', it is the byte order mark.

Tim
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Pipe causes pool failure in Shell.c

[Tim Lewis]

Using the latest Shell build, try:

ls -sfo | parse FileInfo 2

This ends up with a breakpoint when FreePool is called on Shell.c, line 1756.

I'm still debugging, but I wondered if anyone else has seen this?

Also:

ls -sfo > tmp
parse FileInfo 2 < tmp

prints nothing, but

parse tmp FileInfo 2

works fine.

Tim
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [shell] Redirection to environment variable used on command-line not working.

[Tim Lewis]

I have a command like this:

X %_key% >v _key

and

X %_key% _key

These two commands should do, essentially the same thing, since the command 'X' 
calls ShellSetEnvironmentVariable() if the 2nd parameter is present.

Any thoughts?

Tim

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [shell] AliasLower never used in InternalSetAlias

[Tim Lewis]

Sure. I think we should adjust the specification in this case. My problem has 
been when someone says "but the EDK2 version does X"

Tim

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com] 
Sent: Friday, October 28, 2016 9:59 AM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org
Cc: Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [shell] AliasLower never used in InternalSetAlias

I agree with the goal of being more closely matched to the spec.

I think that some things we need to adjust the spec, others we adjust the code, 
and others may go beyond the spec.  We have no prohibition that an 
implementation cannot have additional features as long as they do not violate 
the requirements of the spec.

The unused code for #2 is a simple bug I think (as is any unused code I would 
argue).

-Jaben

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Friday, October 28, 2016 9:49 AM
> To: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel@lists.01.org
> Subject: RE: [shell] AliasLower never used in InternalSetAlias
> Importance: High
> 
> Jaben --
> 
> 1) I'm not talking about desired behavior, I'm talking about spec 
> behavior. As an external user of GetAlias() and SetAlias() (and a 
> non-EDK2 shell implementer), I have become aware of a number of places 
> where the EDK2 shell makes assumptions.  The spec requirement is that 
> commands are case- insensitive, but does not place this requirement on 
> Alias. The way in which the command-line uses aliases is not relevant 
> to how the API responds. The fact is: there might be entries for both 
> Dir and dir, and the command-line usage in this case is 
> non-deterministic as the specification sits now. Obviously the spec 
> needs an update to deal with what is currently a behavior which can lead to 
> unexpected API failures.
> 2) As I pointed out separately, the current code doesn't work as you 
> (or I) describe. It does not use AliasLower (the lower case version of 
> the input
> string) for the variable name in SetAlias, but does use AliasLower in 
> GetAlias.
> 3) The specification also states that aliases are identifiers, but the 
> internal usage for "cd.." and "cd\" do not follow this rule. Neither 
> the command or the API enforce this rule.
> 
> BTW, another place I have found is in the mapping API, where the "cd"
> command currently relies on the fact that the 2nd parameter can have a 
> mapping name in it (while leaving the first parameter as a NULL). This 
> is unexpected behavior on the API part.
> 
> Tim
> -Original Message-
> From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> Sent: Friday, October 28, 2016 8:20 AM
> To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>
> Subject: RE: [shell] AliasLower never used in InternalSetAlias
> 
> Tim,
> 
> Given that all commands are case insensitive, I couldn't imagine why 
> we would want case-sensitive alias.
> 
> Do we really want "Dir" to fail, while "dir" works fine?  Remember 
> that the real command is case insensitive "ls" in either case.
> 
> -Jaben
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Tim Lewis
> > Sent: Thursday, October 27, 2016 2:29 PM
> > To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org
> > Subject: Re: [edk2] [shell] AliasLower never used in 
> > InternalSetAlias
> > Importance: High
> >
> > I would also note that GetAlias() has similar logic, but does, in 
> > fact use the AliasLower. As far as I can tell, the specification 
> > does not say anything about case-insensitive, so I believe this to be in 
> > error.
> >
> > Tim
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Tim Lewis
> > Sent: Thursday, October 27, 2016 2:11 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] [shell] AliasLower never used in InternalSetAlias
> >
> > In the function InternalSetAlias, it appears that AliasLower is 
> > duplicated (fromAlias), converted to lower case and freed ,but never 
> > actually used. Am I missing something?
> >
> >   // Convert to lowercase to make aliases case-insensitive
> >   if (Alias != NULL) {
> > AliasLower = AllocateCopyPool (StrSize (Alias), Alias);
> > if (AliasLower == NULL) {
> >   return EFI_OUT_OF_RESOURCES;
> > }
> > ToLower (AliasLower);
> >   } else {
> > AliasLower = NULL;
> >

Re: [edk2] [shell] AliasLower never used in InternalSetAlias

[Tim Lewis]

Jaben --

1) I'm not talking about desired behavior, I'm talking about spec behavior. As 
an external user of GetAlias() and SetAlias() (and a non-EDK2 shell 
implementer), I have become aware of a number of places where the EDK2 shell 
makes assumptions.  The spec requirement is that commands are case-insensitive, 
but does not place this requirement on Alias. The way in which the command-line 
uses aliases is not relevant to how the API responds. The fact is: there might 
be entries for both Dir and dir, and the command-line usage in this case is 
non-deterministic as the specification sits now. Obviously the spec needs an 
update to deal with what is currently a behavior which can lead to unexpected 
API failures.
2) As I pointed out separately, the current code doesn't work as you (or I) 
describe. It does not use AliasLower (the lower case version of the input 
string) for the variable name in SetAlias, but does use AliasLower in GetAlias. 
3) The specification also states that aliases are identifiers, but the internal 
usage for "cd.." and "cd\" do not follow this rule. Neither the command or the 
API enforce this rule.

BTW, another place I have found is in the mapping API, where the "cd" command 
currently relies on the fact that the 2nd parameter can have a mapping name in 
it (while leaving the first parameter as a NULL). This is unexpected behavior 
on the API part.

Tim
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com] 
Sent: Friday, October 28, 2016 8:20 AM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org
Cc: Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [shell] AliasLower never used in InternalSetAlias

Tim,

Given that all commands are case insensitive, I couldn't imagine why we would 
want case-sensitive alias.

Do we really want "Dir" to fail, while "dir" works fine?  Remember that the 
real command is case insensitive "ls" in either case.

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Thursday, October 27, 2016 2:29 PM
> To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] [shell] AliasLower never used in InternalSetAlias
> Importance: High
> 
> I would also note that GetAlias() has similar logic, but does, in fact 
> use the AliasLower. As far as I can tell, the specification does not 
> say anything about case-insensitive, so I believe this to be in error.
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Thursday, October 27, 2016 2:11 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [shell] AliasLower never used in InternalSetAlias
> 
> In the function InternalSetAlias, it appears that AliasLower is 
> duplicated (fromAlias), converted to lower case and freed ,but never 
> actually used. Am I missing something?
> 
>   // Convert to lowercase to make aliases case-insensitive
>   if (Alias != NULL) {
> AliasLower = AllocateCopyPool (StrSize (Alias), Alias);
> if (AliasLower == NULL) {
>   return EFI_OUT_OF_RESOURCES;
> }
> ToLower (AliasLower);
>   } else {
> AliasLower = NULL;
>   }
> 
>   //
>   // We must be trying to remove one if Alias is NULL
>   //
>   if (Alias == NULL) {
> //
> // remove an alias (but passed in COMMAND parameter)
> //
> Status = (gRT->SetVariable((CHAR16*)Command, , 0, 
> 0, NULL));
>   } else {
> //
> // Add and replace are the same
> //
> 
> // We dont check the error return on purpose since the variable 
> may not exist.
> gRT->SetVariable((CHAR16*)Command, , 0, 0, NULL);
> 
> Status = (gRT->SetVariable((CHAR16*)Alias, , 
> EFI_VARIABLE_BOOTSERVICE_ACCESS|(Volatile?0:EFI_VARIABLE_NON_VOL
> ATILE), StrSize(Command), (VOID*)Command));
>   }
> 
>   if (Alias != NULL) {
> FreePool (AliasLower);
>   }
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [shell] AliasLower never used in InternalSetAlias

[Tim Lewis]

I would also note that GetAlias() has similar logic, but does, in fact use the 
AliasLower. As far as I can tell, the specification does not say anything about 
case-insensitive, so I believe this to be in error.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Thursday, October 27, 2016 2:11 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [shell] AliasLower never used in InternalSetAlias

In the function InternalSetAlias, it appears that AliasLower is duplicated 
(fromAlias), converted to lower case and freed ,but never actually used. Am I 
missing something?

  // Convert to lowercase to make aliases case-insensitive
  if (Alias != NULL) {
AliasLower = AllocateCopyPool (StrSize (Alias), Alias);
if (AliasLower == NULL) {
  return EFI_OUT_OF_RESOURCES;
}
ToLower (AliasLower);
  } else {
AliasLower = NULL;
  }

  //
  // We must be trying to remove one if Alias is NULL
  //
  if (Alias == NULL) {
//
// remove an alias (but passed in COMMAND parameter)
//
Status = (gRT->SetVariable((CHAR16*)Command, , 0, 0, NULL));
  } else {
//
// Add and replace are the same
//

// We dont check the error return on purpose since the variable may not 
exist.
gRT->SetVariable((CHAR16*)Command, , 0, 0, NULL);

Status = (gRT->SetVariable((CHAR16*)Alias, , 
EFI_VARIABLE_BOOTSERVICE_ACCESS|(Volatile?0:EFI_VARIABLE_NON_VOLATILE), 
StrSize(Command), (VOID*)Command));
  }

  if (Alias != NULL) {
FreePool (AliasLower);
  }
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [shell]cd.. and cd\ are not valid alias

[Tim Lewis]

But the EDK2 registers them as a part of Level 2 supported command 
initialization.

  ShellCommandRegisterAlias(L"cd ..", L"cd..");
  ShellCommandRegisterAlias(L"cd \\", L"cd\\");

According to the SetAlias() description:

An alias is a C-style identifier

The same language is repeated in 3.6.4.


Tim
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [shell] AliasLower never used in InternalSetAlias

[Tim Lewis]

In the function InternalSetAlias, it appears that AliasLower is duplicated 
(fromAlias), converted to lower case and freed ,but never actually used. Am I 
missing something?

  // Convert to lowercase to make aliases case-insensitive
  if (Alias != NULL) {
AliasLower = AllocateCopyPool (StrSize (Alias), Alias);
if (AliasLower == NULL) {
  return EFI_OUT_OF_RESOURCES;
}
ToLower (AliasLower);
  } else {
AliasLower = NULL;
  }

  //
  // We must be trying to remove one if Alias is NULL
  //
  if (Alias == NULL) {
//
// remove an alias (but passed in COMMAND parameter)
//
Status = (gRT->SetVariable((CHAR16*)Command, , 0, 0, NULL));
  } else {
//
// Add and replace are the same
//

// We dont check the error return on purpose since the variable may not 
exist.
gRT->SetVariable((CHAR16*)Command, , 0, 0, NULL);

Status = (gRT->SetVariable((CHAR16*)Alias, , 
EFI_VARIABLE_BOOTSERVICE_ACCESS|(Volatile?0:EFI_VARIABLE_NON_VOLATILE), 
StrSize(Command), (VOID*)Command));
  }

  if (Alias != NULL) {
FreePool (AliasLower);
  }
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg/Shell: fix CopyGuid() arg order in EfiShellGetGuidFromName()

[Tim Lewis]

Reviewed-by: Tim Lewis <tim.le...@insyde.com>

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, October 18, 2016 4:07 AM
To: edk2-devel-01 <edk2-de...@ml01.01.org>
Cc: Jaben Carsey <jaben.car...@intel.com>; Ruiyu Ni <ruiyu...@intel.com>; Tim 
Lewis <tim.le...@insyde.com>
Subject: [PATCH] ShellPkg/Shell: fix CopyGuid() arg order in 
EfiShellGetGuidFromName()

The destination GUID comes first; from
"MdePkg/Include/Library/BaseMemoryLib.h":

> GUID *
> EFIAPI
> CopyGuid (
>   OUT GUID   *DestinationGuid,
>   IN CONST GUID  *SourceGuid
>   );

Here "NewGuid" is the GUID looked up by GetGuidFromStringName(), and "Guid" is 
where EfiShellGetGuidFromName() has to propagate that result to.

Cc: Jaben Carsey <jaben.car...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Cc: Tim Lewis <tim.le...@insyde.com>
Reported-by: Tim Lewis <tim.le...@insyde.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
---
 ShellPkg/Application/Shell/ShellProtocol.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/Application/Shell/ShellProtocol.c 
b/ShellPkg/Application/Shell/ShellProtocol.c
index 2bc0646b453d..04b66c5acaae 100644
--- a/ShellPkg/Application/Shell/ShellProtocol.c
+++ b/ShellPkg/Application/Shell/ShellProtocol.c
@@ -2207,7 +2207,7 @@ EfiShellGetGuidFromName(
   Status = GetGuidFromStringName(GuidName, NULL, );
 
   if (!EFI_ERROR(Status)) {
-CopyGuid(NewGuid, Guid);
+CopyGuid(Guid, NewGuid);
   }
 
   return (Status);
--
2.9.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] FW: [shell] Problems in EfiShellGetGuidFromName

[Tim Lewis]

Did anyone have a chance to look at this EFI_SHELL_PROTOCOL bug in the EDK2 
implementation?

Thanks,

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Thursday, October 13, 2016 11:16 AM
To: edk2-devel-01 <edk2-devel@lists.01.org>
Subject: [edk2] [shell] Problems in EfiShellGetGuidFromName

In EfiShellGetGuidFromName (ShellProtocol.c), we see:

EfiShellGetGuidFromName(
  IN  CONST CHAR16   *GuidName,
  OUT   EFI_GUID *Guid
  )
{
  EFI_GUID*NewGuid;
  EFI_STATUS  Status;

  if (Guid == NULL || GuidName == NULL) {
return (EFI_INVALID_PARAMETER);
  }

  Status = GetGuidFromStringName(GuidName, NULL, );
  if (!EFI_ERROR(Status)) {
CopyGuid(NewGuid, Guid);
  }
  return (Status);

However, this doesn't work. Notice that CopyGuid places the output parameter as 
the 2nd parameter. But according to BaseMemoryLib:

GUID *
EFIAPI
CopyGuid (
  OUT GUID   *DestinationGuid,
  IN CONST GUID  *SourceGuid
  );

The destination should be the 1st parameter (not the second).



___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/5] ShellPkg: Move SHELL_FREE_NON_NULL from ShellBase.h to ShellLib.h

[Tim Lewis]

Glad to see this is finally being done!

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Friday, October 14, 2016 2:44 AM
To: edk2-devel@lists.01.org
Cc: Jaben Carsey ; Michael D Kinney 
; Jiewen Yao 
Subject: [edk2] [PATCH 1/5] ShellPkg: Move SHELL_FREE_NON_NULL from ShellBase.h 
to ShellLib.h

The more proper place for macro SHELL_FREE_NON_NULL is ShellLib.h instead of 
ShellBase.h.

Modify Compress.c to resolve build failure due to this change.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
Cc: Jiewen Yao 
Cc: Michael D Kinney 
---
 ShellPkg/Include/Library/ShellLib.h| 10 +-
 ShellPkg/Include/ShellBase.h   | 10 +-
 ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c |  8 
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/ShellPkg/Include/Library/ShellLib.h 
b/ShellPkg/Include/Library/ShellLib.h
index fe4b9cf..fafa041 100644
--- a/ShellPkg/Include/Library/ShellLib.h
+++ b/ShellPkg/Include/Library/ShellLib.h
@@ -1,7 +1,7 @@
 /** @file
   Provides interface to shell functionality for shell commands and 
applications.
 
-  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2016, Intel Corporation. All rights 
+ reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at @@ -24,6 +24,14 @@  #include   #include 

 
+#define SHELL_FREE_NON_NULL(Pointer)  \
+  do {\
+if ((Pointer) != NULL) {  \
+  FreePool((Pointer));\
+  (Pointer) = NULL;   \
+} \
+  } while(FALSE)
+
 // (20 * (6+5+2))+1) unicode characters from EFI FAT spec (doubled for bytes)  
#define MAX_FILE_NAME_LEN 512
 
diff --git a/ShellPkg/Include/ShellBase.h b/ShellPkg/Include/ShellBase.h index 
09f87b4..4b7a3d1 100644
--- a/ShellPkg/Include/ShellBase.h
+++ b/ShellPkg/Include/ShellBase.h
@@ -1,7 +1,7 @@
 /** @file
   Root include file for Shell Package modules that utilize the SHELL_RETURN 
type
 
-  Copyright (c) 2009 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2016, Intel Corporation. All rights 
+ reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at @@ -17,14 +17,6 @@
 
 typedef VOID *SHELL_FILE_HANDLE;
 
-#define SHELL_FREE_NON_NULL(Pointer)  \
-  do {\
-if ((Pointer) != NULL) {  \
-  FreePool((Pointer));\
-  (Pointer) = NULL;   \
-} \
-  } while(FALSE)
-
 typedef enum {
 ///
 /// The operation completed successfully.
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c
index dda2fed..da8e647 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c
@@ -7,7 +7,7 @@
   This sequence is further divided into Blocks and Huffman codings
   are applied to each Block.
 
-  Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2007 - 2016, Intel Corporation. All rights 
+ reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at @@ -17,12 +17,12 @@
   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
 **/
-
+#include 
+#include 
 #include   #include   
#include  -#include  -#include 
+#include 
 
 //
 // Macro Definitions
--
2.9.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

[Tim Lewis]

I prefer the renamed .h file, even though I have substantial investment in the 
current infrastructure.

Why? Because engineers don't have time to remember "how does protocol X 
translate to header file Y" It should be a consistent rule. How many times have 
I needed to grep the header file name just because I got a build error because 
the rule wasn't predictable.

1) remove the EFI_ prefix and the _PROTOCOL  suffix (EFI_BLOCK_IO_PROTOCOL -> 
BLOCK_IO
2) Convert to upper-and-lower case, BLOCK_IO -> Block_Io 
3) Remove the _ (Block_Io -> BlockIo)
4)  add a .h BlockIo -> BlockIo.h

Most protocol and PPI header files already follow this rule. The current header 
files for shell are among the few exceptions, because they don't follow this.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Friday, October 14, 2016 6:14 AM
To: Yao, Jiewen ; Ni, Ruiyu ; 
edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

Or if you really think we should give a better name.

My recommendation is:

1)  We add content in MdePkg.

2)  We can keep the old protocol file in ShellPkg, but let .h in shellPkg 
include the .h in MdePkg.

Then we can avoid duplicated code and make it a compatible solution to avoid 
other module update.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Friday, October 14, 2016 9:09 PM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

Hi
I think the requests is just to *move*.

There is no request to *rename*.

Can we just move to avoid other update?


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Ruiyu Ni
> Sent: Friday, October 14, 2016 5:44 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg
>
> The patches moves Shell spec defined protocol definitions to MdePkg 
> and updates all references.
> Content of ShellBase.h is moved to Protocol/Shell.h and ShellBase.h is 
> removed.
>
> Ruiyu Ni (5):
>   ShellPkg: Move SHELL_FREE_NON_NULL from ShellBase.h to ShellLib.h
>   MdePkg: Include Shell/ShellDynamicCommand/ShellParameters
> definitions
>   ArmPkg/LinuxLoader: Reference Shell protocols in MdePkg
>   EmbeddedPkg/FdtPlatformDxe: Reference Shell protocols in MdePkg
>   ShellPkg: Remove Shell/ShellDynamicCommand/ShellParameter
> definitions
>
>  ArmPkg/Application/LinuxLoader/LinuxLoader.h   |   4 +-
>  EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h   |   4 +-
>  .../EfiShell.h => MdePkg/Include/Protocol/Shell.h  | 134
> +-
>  .../Include/Protocol/ShellDynamicCommand.h |   7 +-
>  .../Include/Protocol/ShellParameters.h |   4 +-
>  MdePkg/MdePkg.dec  |  15 ++
>  ShellPkg/Application/Shell/Shell.h |   5 +-
>  ShellPkg/Include/Library/ShellCommandLib.h |   5 +-
>  ShellPkg/Include/Library/ShellLib.h|  14 +-
>  ShellPkg/Include/ShellBase.h   | 157
> -
>  ShellPkg/Library/UefiDpLib/Dp.h|   3 +-
>  ShellPkg/Library/UefiDpLib/UefiDpLib.h |   7 +-
>  .../UefiHandleParsingLib/UefiHandleParsingLib.h|   8 +-
>  .../UefiShellBcfgCommandLib.c  |   5 +-
>  .../UefiShellCEntryLib/UefiShellCEntryLib.c|   6 +-
>  .../UefiShellCommandLib/UefiShellCommandLib.h  |   7 +-
>  .../Library/UefiShellDebug1CommandsLib/Compress.c  |   7 +-
>  .../UefiShellDebug1CommandsLib.h   |   7 +-
>  .../UefiShellDriver1CommandsLib.h  |   7 +-
>  .../UefiShellLevel1CommandsLib.h   |   7 +-
>  .../UefiShellLevel2CommandsLib.h   |   7 +-
>  ShellPkg/Library/UefiShellLevel3CommandsLib/Help.c |   2 +-
>  .../UefiShellLevel3CommandsLib.h   |   7 +-
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c   |   1 -
>  ShellPkg/Library/UefiShellLib/UefiShellLib.h   |   6 +-
>  .../UefiShellNetwork1CommandsLib.h |   3 +-
>  .../UefiShellTftpCommandLib.h  |   3 +-
>  ShellPkg/ShellPkg.dec  |   3 -
>  ShellPkg/ShellPkg.dsc  |   2 +
>  29 files changed, 213 insertions(+), 234 deletions(-)  rename 
> ShellPkg/Include/Protocol/EfiShell.h => 
> MdePkg/Include/Protocol/Shell.h (92%)  rename 
> ShellPkg/Include/Protocol/EfiShellDynamicCommand.h => 
> MdePkg/Include/Protocol/ShellDynamicCommand.h (92%)  rename 
> ShellPkg/Include/Protocol/EfiShellParameters.h => 
> MdePkg/Include/Protocol/ShellParameters.h (92%)  delete mode 100644 
> ShellPkg/Include/ShellBase.h
>
> --
> 2.9.0.windows.1
>
> 

Re: [edk2] AsciiPrint behavior with \n linefeed characters.

[Tim Lewis]

Liming --

And I agree that this should be the behavior. I was surprised by the lack of 
translation for the other string printed via %s.

Tim

-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Thursday, October 13, 2016 6:24 PM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel-01 <edk2-devel@lists.01.org>
Subject: RE: AsciiPrint behavior with \n linefeed characters.

Tim:
  The first parameter in AsciiPrint() is the Format string. Per PrintLib.h 
definition, \n will be changed to \r\n in the format string. 

The following end of line(EOL) translations must be performed on the contents 
of the format string:
 - '\\r' is translated to '\\r'
 - '\\r\\n' is translated to '\\r\\n'
 - '\\n' is translated to '\\r\\n' 
 - '\\n\\r' is translated to '\\r\\n'

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Friday, October 14, 2016 5:29 AM
To: edk2-devel-01 <edk2-devel@lists.01.org>
Subject: [edk2] AsciiPrint behavior with \n linefeed characters.

In using AsciiPrint (I'm presuming the behavior is also in Print, but I haven't 
tested), I found an interesting behavior for linefeed characters embedded in 
strings that are parameters. I post it here just so people who are mystified by 
their output can understand it.

Consider this example:

CONST CHAR16 *XyzStr = "HI\nBYE";

AsciiPrint(XyzStr);
AsciiPrint("Offset\n%s\n", XyzStr);

Output looks like this:

HI
BYE
Offset
HI
   BYE

It turns out that \n characters in the format string are converted to \r\n, but 
\n characters in strings that are embedded (as in the second example) are not 
converted. So only the linefeed character is interpreted, leading to "BYE" 
being suspended one character to the right and one row lower than "HI"
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] AsciiPrint behavior with \n linefeed characters.

[Tim Lewis]

In using AsciiPrint (I'm presuming the behavior is also in Print, but I haven't 
tested), I found an interesting behavior for linefeed characters embedded in 
strings that are parameters. I post it here just so people who are mystified by 
their output can understand it.

Consider this example:

CONST CHAR16 *XyzStr = "HI\nBYE";

AsciiPrint(XyzStr);
AsciiPrint("Offset\n%s\n", XyzStr);

Output looks like this:

HI
BYE
Offset
HI
   BYE

It turns out that \n characters in the format string are converted to \r\n, but 
\n characters in strings that are embedded (as in the second example) are not 
converted. So only the linefeed character is interpreted, leading to "BYE" 
being suspended one character to the right and one row lower than "HI"
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [shell] Problems in EfiShellGetGuidFromName

[Tim Lewis]

In EfiShellGetGuidFromName (ShellProtocol.c), we see:

EfiShellGetGuidFromName(
  IN  CONST CHAR16   *GuidName,
  OUT   EFI_GUID *Guid
  )
{
  EFI_GUID*NewGuid;
  EFI_STATUS  Status;

  if (Guid == NULL || GuidName == NULL) {
return (EFI_INVALID_PARAMETER);
  }

  Status = GetGuidFromStringName(GuidName, NULL, );
  if (!EFI_ERROR(Status)) {
CopyGuid(NewGuid, Guid);
  }
  return (Status);

However, this doesn't work. Notice that CopyGuid places the output parameter as 
the 2nd parameter. But according to BaseMemoryLib:

GUID *
EFIAPI
CopyGuid (
  OUT GUID   *DestinationGuid,
  IN CONST GUID  *SourceGuid
  );

The destination should be the 1st parameter (not the second).



___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] SetCurDir() doesn't allow '\\' in Dir?

[Tim Lewis]

I did a  simple break apart of a path into map-name and directory.

fs0:\MdeModulePkg

So FileSystem was "fs0:" and Dir was "\MdeModulePkg" and the resulting working 
directory was: "fs0:MdeModulePkg" (with escape characters)..

It seems the culprit is in EfiShellSetCurDir:

if (DirectoryName != NULL) {
  //
  // change current dir on that file system
  //

  if (MapListItem->CurrentDirectoryPath != NULL) {
FreePool(MapListItem->CurrentDirectoryPath);
DEBUG_CODE(MapListItem->CurrentDirectoryPath = NULL;);
  }
//  ASSERT((MapListItem->CurrentDirectoryPath == NULL && Size == 0) || 
(MapListItem->CurrentDirectoryPath != NULL));
//  MapListItem->CurrentDirectoryPath = 
StrnCatGrow(>CurrentDirectoryPath, , FileSystem, 0);
  ASSERT((MapListItem->CurrentDirectoryPath == NULL && Size == 0) || 
(MapListItem->CurrentDirectoryPath != NULL));
  MapListItem->CurrentDirectoryPath = 
StrnCatGrow(>CurrentDirectoryPath, , L"\\", 0);
  ASSERT((MapListItem->CurrentDirectoryPath == NULL && Size == 0) || 
(MapListItem->CurrentDirectoryPath != NULL));
  MapListItem->CurrentDirectoryPath = 
StrnCatGrow(>CurrentDirectoryPath, , DirectoryName, 0);
  if (MapListItem->CurrentDirectoryPath != NULL && 
MapListItem->CurrentDirectoryPath[StrLen(MapListItem->CurrentDirectoryPath)-1] 
== L'\\') {
ASSERT((MapListItem->CurrentDirectoryPath == NULL && Size == 0) || 
(MapListItem->CurrentDirectoryPath != NULL));

MapListItem->CurrentDirectoryPath[StrLen(MapListItem->CurrentDirectoryPath)-1] 
= CHAR_NULL;
  }
}
  }

I checked with the Shell Specification and it doesn't mention this sort of 
pre-pending behavior. It also doesn't allow relative paths, so I would expect 
that all directory names passed in must be in the form \. The only exception to 
this rule seems to be FS0:\

I'm not sure what to do here, because I don't think the current behavior makes 
sense.

Tim



___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform

[Tim Lewis]

Jaben --

Here is the relevant piece of code. There is *no way* for Unicode Collation to 
execute without the Shell Protocol existing! There is no way for the Shell 
Protocol to exist without (at least) Unicode Collation or Unicode Collation 2 
from existing.

So adding a check to the function does not help it, because in every case that 
counts (where shell protocol is produced by some sort of standard shell), 
Unicode Collation already exists.

Status = gEfiShellProtocol->OpenFileByName(FileName,
   FileHandle,
   OpenMode);
if ((mUnicodeCollationProtocol->StriColl (mUnicodeCollationProtocol, 
(CHAR16*)FileName, L"NUL") != 0) &&
(mUnicodeCollationProtocol->StriColl (mUnicodeCollationProtocol, 
(CHAR16*)FileName, L"NULL") != 0) &&
 !EFI_ERROR(Status) && ((OpenMode & EFI_FILE_MODE_CREATE) != 0)){
  FileInfo = FileFunctionMap.GetFileInfo(*FileHandle); << WITHOUT A SHELL 
IT WILL FAIL HERE
  ASSERT(FileInfo != NULL);
  FileInfo->Attribute = Attributes;
  Status2 = FileFunctionMap.SetFileInfo(*FileHandle, FileInfo);
  FreePool(FileInfo);
  if (EFI_ERROR (Status2)) {
gEfiShellProtocol->CloseFile(*FileHandle);
  }
  Status = Status2;
}



-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com] 
Sent: Wednesday, October 05, 2016 2:17 PM
To: Tim Lewis <tim.le...@insyde.com>; af...@apple.com; Laszlo Ersek 
<ler...@redhat.com>
Cc: edk2-devel-01 <edk2-de...@ml01.01.org>; Leif Lindholm 
<leif.lindh...@arm.com>; Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the 
Reference Platform

That is not enough.  That gets called by the constructor.  We need to not check 
in either constructor or the constructor worker.

That difference only matters for the shell binary itself.

-Jaben

> -----Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Wednesday, October 05, 2016 2:07 PM
> To: af...@apple.com; Laszlo Ersek <ler...@redhat.com>
> Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel-01  de...@ml01.01.org>; Leif Lindholm <leif.lindh...@arm.com>
> Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 
> source on the Reference Platform
> Importance: High
> 
> If he has a DXE driver that consumes the shell lib (a valid case), 
> then my original suggestion stands: move it to 
> ShellLibConstructorWorker. This is where the ShellLib's internal pointers to 
> the Shell protocol are initialized.
> 
> Tim
> 
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Wednesday, October 05, 2016 1:59 PM
> To: Laszlo Ersek <ler...@redhat.com>
> Cc: Tim Lewis <tim.le...@insyde.com>; Carsey, Jaben 
> <jaben.car...@intel.com>; Shah, Tapan <tapands...@hpe.com>; Daniil 
> Egranov <daniil.egra...@arm.com>; edk2-devel-01  de...@ml01.01.org>; Leif Lindholm <leif.lindh...@arm.com>
> Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 
> source on the Reference Platform
> 
> 
> > On Oct 5, 2016, at 1:58 PM, Laszlo Ersek <ler...@redhat.com> wrote:
> >
> > On 10/05/16 22:44, Tim Lewis wrote:
> >> Jaben --
> >>
> >> In which cases would you have the Shell protocol present and not 
> >> have
> the Unicode Collation protocol?
> >
> > That's exactly the question!
> >
> > According to the spec, at least if the system cannot boot from a 
> > disk device, then the collation protocol need not be present.
> >
> >> By my count, the Shell itself cannot function without it (see
> ProcessCommandLine()).
> >
> > In which case though I don't understand why Daniil experiences this 
> > change (= commit 583448b441650) as a regression on Juno. If the 
> > shell couldn't function without the collation protocol even before 
> > commit 583448b441650, then the shell must never have run on Juno -- 
> > because it appears to lack collation -- and then this change cannot be a 
> > regression.
> >
> 
> Looks like he has a DXE Driver that consume the ShellLib.
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thanks
> > Laszlo
> >
> >
> >>
> >> Tim
> >>
> >>
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> >> Of Carsey, Jaben
> >> Sent: Wednesday, October 05, 2016 1:35 PM
> >> To: Shah, Tapan <tapands...@hpe.com>; Laszlo Ersek 
>

Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform

[Tim Lewis]

If he has a DXE driver that consumes the shell lib (a valid case), then my 
original suggestion stands: move it to ShellLibConstructorWorker. This is where 
the ShellLib's internal pointers to the Shell protocol are initialized.

Tim

-Original Message-
From: af...@apple.com [mailto:af...@apple.com] 
Sent: Wednesday, October 05, 2016 1:59 PM
To: Laszlo Ersek <ler...@redhat.com>
Cc: Tim Lewis <tim.le...@insyde.com>; Carsey, Jaben <jaben.car...@intel.com>; 
Shah, Tapan <tapands...@hpe.com>; Daniil Egranov <daniil.egra...@arm.com>; 
edk2-devel-01 <edk2-de...@ml01.01.org>; Leif Lindholm <leif.lindh...@arm.com>
Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the 
Reference Platform


> On Oct 5, 2016, at 1:58 PM, Laszlo Ersek <ler...@redhat.com> wrote:
> 
> On 10/05/16 22:44, Tim Lewis wrote:
>> Jaben --
>> 
>> In which cases would you have the Shell protocol present and not have the 
>> Unicode Collation protocol?
> 
> That's exactly the question!
> 
> According to the spec, at least if the system cannot boot from a disk 
> device, then the collation protocol need not be present.
> 
>> By my count, the Shell itself cannot function without it (see 
>> ProcessCommandLine()). 
> 
> In which case though I don't understand why Daniil experiences this 
> change (= commit 583448b441650) as a regression on Juno. If the shell 
> couldn't function without the collation protocol even before commit 
> 583448b441650, then the shell must never have run on Juno -- because 
> it appears to lack collation -- and then this change cannot be a regression.
> 

Looks like he has a DXE Driver that consume the ShellLib. 

Thanks,

Andrew Fish

> Thanks
> Laszlo
> 
> 
>> 
>> Tim
>> 
>> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> Of Carsey, Jaben
>> Sent: Wednesday, October 05, 2016 1:35 PM
>> To: Shah, Tapan <tapands...@hpe.com>; Laszlo Ersek 
>> <ler...@redhat.com>; Andrew Fish <af...@apple.com>; Daniil Egranov 
>> <daniil.egra...@arm.com>
>> Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel-01 
>> <edk2-de...@ml01.01.org>; Leif Lindholm <leif.lindh...@arm.com>
>> Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 
>> source on the Reference Platform
>> 
>> That should work.  We also need to initialize the variable to NULL in the 
>> constructor.
>> 
>> Do we need to be case insensitive for this?  Can we use memcmp instead of 
>> the prototol?
>> 
>> -Jaben
>> 
>>> -Original Message-
>>> From: Shah, Tapan [mailto:tapands...@hpe.com]
>>> Sent: Wednesday, October 05, 2016 1:25 PM
>>> To: Laszlo Ersek <ler...@redhat.com>; Andrew Fish <af...@apple.com>; 
>>> Daniil Egranov <daniil.egra...@arm.com>
>>> Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel-01 >> de...@ml01.01.org>; Leif Lindholm <leif.lindh...@arm.com>
>>> Subject: RE: [edk2] Assert in ShellPkg with latest tianocore edk2 
>>> source on the Reference Platform
>>> Importance: High
>>> 
>>> How about moving protocol locate from constructor to the actual 
>>> function level and returning an error if it fails to locate (See attached 
>>> patch file).
>>> 
>>> Tapan
>>> 
>>> -Original Message-
>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Sent: Wednesday, October 05, 2016 3:18 PM
>>> To: Andrew Fish <af...@apple.com>; Daniil Egranov 
>>> <daniil.egra...@arm.com>
>>> Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel-01 >> de...@ml01.01.org>; Leif Lindholm <leif.lindh...@arm.com>; Shah, 
>>> Tapan <tapands...@hpe.com>
>>> Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 
>>> source on the Reference Platform
>>> 
>>> On 10/05/16 21:48, Andrew Fish wrote:
>>>> 
>>>>> On Oct 5, 2016, at 12:24 PM, Daniil Egranov 
>>>>> <daniil.egra...@arm.com>
>>> wrote:
>>>>> 
>>>>> I have the same ASSERT issue on Juno platform even the 
>>>>> EnglishDxe.inf is
>>> included to the platform build. If UefiShellLib has such dependency 
>>> on the protocol then according to EDKII Module Writer's Guide you 
>>> need to specify the dependency on protocol in the module .inf to 
>>> ensure the drivers proper load sequence.
>>>>> 
>>>>> 

Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform

[Tim Lewis]

Is it possible that Daniil has UnicodeCollation and not UnicodeCollation2? The 
shell itself can handle this case, but the ShellLib cannot.

Tim

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, October 05, 2016 1:58 PM
To: Tim Lewis <tim.le...@insyde.com>; Carsey, Jaben <jaben.car...@intel.com>; 
Shah, Tapan <tapands...@hpe.com>; Andrew Fish <af...@apple.com>; Daniil Egranov 
<daniil.egra...@arm.com>
Cc: edk2-devel-01 <edk2-de...@ml01.01.org>; Leif Lindholm 
<leif.lindh...@arm.com>
Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the 
Reference Platform

On 10/05/16 22:44, Tim Lewis wrote:
> Jaben --
> 
> In which cases would you have the Shell protocol present and not have the 
> Unicode Collation protocol?

That's exactly the question!

According to the spec, at least if the system cannot boot from a disk device, 
then the collation protocol need not be present.

> By my count, the Shell itself cannot function without it (see 
> ProcessCommandLine()). 

In which case though I don't understand why Daniil experiences this change (= 
commit 583448b441650) as a regression on Juno. If the shell couldn't function 
without the collation protocol even before commit 583448b441650, then the shell 
must never have run on Juno -- because it appears to lack collation -- and then 
this change cannot be a regression.

Thanks
Laszlo


> 
> Tim
> 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Carsey, Jaben
> Sent: Wednesday, October 05, 2016 1:35 PM
> To: Shah, Tapan <tapands...@hpe.com>; Laszlo Ersek 
> <ler...@redhat.com>; Andrew Fish <af...@apple.com>; Daniil Egranov 
> <daniil.egra...@arm.com>
> Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel-01 
> <edk2-de...@ml01.01.org>; Leif Lindholm <leif.lindh...@arm.com>
> Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 
> source on the Reference Platform
> 
> That should work.  We also need to initialize the variable to NULL in the 
> constructor.
> 
> Do we need to be case insensitive for this?  Can we use memcmp instead of the 
> prototol?
> 
> -Jaben
> 
>> -Original Message-
>> From: Shah, Tapan [mailto:tapands...@hpe.com]
>> Sent: Wednesday, October 05, 2016 1:25 PM
>> To: Laszlo Ersek <ler...@redhat.com>; Andrew Fish <af...@apple.com>; 
>> Daniil Egranov <daniil.egra...@arm.com>
>> Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel-01 > de...@ml01.01.org>; Leif Lindholm <leif.lindh...@arm.com>
>> Subject: RE: [edk2] Assert in ShellPkg with latest tianocore edk2 
>> source on the Reference Platform
>> Importance: High
>>
>> How about moving protocol locate from constructor to the actual 
>> function level and returning an error if it fails to locate (See attached 
>> patch file).
>>
>> Tapan
>>
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Wednesday, October 05, 2016 3:18 PM
>> To: Andrew Fish <af...@apple.com>; Daniil Egranov 
>> <daniil.egra...@arm.com>
>> Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel-01 > de...@ml01.01.org>; Leif Lindholm <leif.lindh...@arm.com>; Shah, 
>> Tapan <tapands...@hpe.com>
>> Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 
>> source on the Reference Platform
>>
>> On 10/05/16 21:48, Andrew Fish wrote:
>>>
>>>> On Oct 5, 2016, at 12:24 PM, Daniil Egranov 
>>>> <daniil.egra...@arm.com>
>> wrote:
>>>>
>>>> I have the same ASSERT issue on Juno platform even the 
>>>> EnglishDxe.inf is
>> included to the platform build. If UefiShellLib has such dependency 
>> on the protocol then according to EDKII Module Writer's Guide you 
>> need to specify the dependency on protocol in the module .inf to 
>> ensure the drivers proper load sequence.
>>>>
>>>> 8.6 Dependency Expressions
>>>> A dependency expression specifies the protocols that the DXE driver 
>>>> requires to execute. In EDK II, it is specified in the [Depex] 
>>>> section of INF
>> file.
>>>>
>>>
>>> The Dependency Expression is for DXE Drivers that are dispatched by 
>>> the
>> DXE Core. A UEFI Driver from an option ROM or an Application does not 
>> get dispatched by the dispatch and the Depex will not help. The Depex 
>> ends up being a section in the FV and it has nothing to do with the 
>> PE/COFF image of the an applicatio

Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform

[Tim Lewis]

Jaben --

In which cases would you have the Shell protocol present and not have the 
Unicode Collation protocol?

By my count, the Shell itself cannot function without it (see 
ProcessCommandLine()). 

Tim


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Wednesday, October 05, 2016 1:35 PM
To: Shah, Tapan ; Laszlo Ersek ; Andrew 
Fish ; Daniil Egranov 
Cc: Carsey, Jaben ; edk2-devel-01 
; Leif Lindholm 
Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the 
Reference Platform

That should work.  We also need to initialize the variable to NULL in the 
constructor.

Do we need to be case insensitive for this?  Can we use memcmp instead of the 
prototol?

-Jaben

> -Original Message-
> From: Shah, Tapan [mailto:tapands...@hpe.com]
> Sent: Wednesday, October 05, 2016 1:25 PM
> To: Laszlo Ersek ; Andrew Fish ; 
> Daniil Egranov 
> Cc: Carsey, Jaben ; edk2-devel-01  de...@ml01.01.org>; Leif Lindholm 
> Subject: RE: [edk2] Assert in ShellPkg with latest tianocore edk2 
> source on the Reference Platform
> Importance: High
> 
> How about moving protocol locate from constructor to the actual 
> function level and returning an error if it fails to locate (See attached 
> patch file).
> 
> Tapan
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, October 05, 2016 3:18 PM
> To: Andrew Fish ; Daniil Egranov 
> 
> Cc: Carsey, Jaben ; edk2-devel-01  de...@ml01.01.org>; Leif Lindholm ; Shah, Tapan 
> 
> Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 
> source on the Reference Platform
> 
> On 10/05/16 21:48, Andrew Fish wrote:
> >
> >> On Oct 5, 2016, at 12:24 PM, Daniil Egranov 
> >> 
> wrote:
> >>
> >> I have the same ASSERT issue on Juno platform even the 
> >> EnglishDxe.inf is
> included to the platform build. If UefiShellLib has such dependency on 
> the protocol then according to EDKII Module Writer's Guide you need to 
> specify the dependency on protocol in the module .inf to ensure the 
> drivers proper load sequence.
> >>
> >> 8.6 Dependency Expressions
> >> A dependency expression specifies the protocols that the DXE driver 
> >> requires to execute. In EDK II, it is specified in the [Depex] 
> >> section of INF
> file.
> >>
> >
> > The Dependency Expression is for DXE Drivers that are dispatched by 
> > the
> DXE Core. A UEFI Driver from an option ROM or an Application does not 
> get dispatched by the dispatch and the Depex will not help. The Depex 
> ends up being a section in the FV and it has nothing to do with the 
> PE/COFF image of the an application or option ROM.
> >
> > IMHO the shell should try as hard as possible to function and should 
> > not
> ASSERT if some newer Protocol is missing.
> 
> (Background: commit 583448b441650.)
> 
> In this specific case, the protocol dependency seems possible to eliminate:
> 
> - Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c
> includes the CharToUpper() function, which is minimal -- could even be 
> copied or moved over -- and can translate the ASCII subset of UCS-2,
> 
> - once the ASCII characters of the input string have been translated 
> to upper case, the result could be searched for / compared against L"NULL"
> using BaseLib.h APIs.
> 
> (Given that L"NULL" only contains characters from the ASCII subset, it 
> suffices to upper-case ASCII chars in the input string. No non-ASCII 
> character in the BMP can translate to ASCII N/U/L via upcasing, even 
> with the real collation protocol (I trust), and no other ASCII 
> characters than n/u/l will translate to N/U/L. This means that we 
> won't miss an instance of NULL because we didn't upcate it (because it 
> was non-ascii), and it also means we won't mistakenly match something 
> non-NULL as NULL.)
> 
> Just my two cents.
> 
> Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform

[Tim Lewis]

Daniil --

Per your point about modules: Adding a dependency expression to a library 
should NOT have any effect on an application, since applications do not have 
dependency expressions. 

So this would indicate that you are trying to link a driver against the 
UefiShellLib. Is this correct?

This is valid for drivers that produce the new Dynamic commands. That is why 
the UefiShellLib INF allows DXE_RUNTIME_DRIVER and DXE_DRIVER. 
DXE_RUNTIME_DRIVER and DXE_DRIVER should call ShellInitialize() (this is what 
the Shell does for commands). Unfortunately, the UnicodeCollation initializer 
is not a part of this.

Jaben --- I suggest that moving the UnicodeCollation initializer into 
ShellLibConstructorWorker would probably solve the problem for a 
well-constructed shell extension driver. 

Tim 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Daniil 
Egranov
Sent: Wednesday, October 05, 2016 12:24 PM
To: Shah, Tapan ; Carsey, Jaben ; 
Supreeth Venkatesh ; edk2-devel-01 

Cc: Leif Lindholm 
Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the 
Reference Platform

I have the same ASSERT issue on Juno platform even the EnglishDxe.inf is 
included to the platform build. If UefiShellLib has such dependency on the 
protocol then according to EDKII Module Writer's Guide you need to specify the 
dependency on protocol in the module .inf to ensure the drivers proper load 
sequence.

8.6 Dependency Expressions
A dependency expression specifies the protocols that the DXE driver requires to 
execute. In EDK II, it is specified in the [Depex] section of INF file.

The following dependency in UefiShellLib.inf fixes ASSERT problem:

[Depex]
   gEfiUnicodeCollation2ProtocolGuid


Thanks,

Daniil


On 10/05/2016 11:02 AM, Shah, Tapan wrote:
> It's possible. But I think gEfiUnicodeCollation2ProtocolGuid protocol is 
> necessary for even other Shell libraries other than UefiShellLib in order to 
> have Shell parser and other command line processing to work properly. That's 
> why I added ASSERT if UefiShellLib fails to locate the protocol.
>   
> Reference platform should have EnglishDxe module to have this protocol 
> installed properly.
>
>
> MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
>
> -Original Message-
> From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> Sent: Wednesday, October 05, 2016 10:41 AM
> To: Supreeth Venkatesh ; edk2-devel-01 
> ; Shah, Tapan 
> Cc: Leif Lindholm ; Carsey, Jaben 
> 
> Subject: RE: Assert in ShellPkg with latest tianocore edk2 source on 
> the Reference Platform
>
> Tapan,
>
> Could this be a side effect of your patch?  Should we allow the UefiShellLib 
> to continue without this protocol and then return an error only when the 
> OpenFile is called?
>
> Also, it looks like we never properly initialize mUnicodeCollationProtocol.  
> We check for NULL in Constructor, but nothing else...
>
> -Jaben
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> Of Supreeth Venkatesh
>> Sent: Tuesday, October 04, 2016 3:51 PM
>> To: edk2-devel-01 
>> Cc: Leif Lindholm 
>> Subject: [edk2] Assert in ShellPkg with latest tianocore edk2 source 
>> on the Reference Platform
>> Importance: High
>>
>> All,
>>
>> Recently, I updated to latest edk2 master (yesterday's) and I am 
>> actually encountering assert in 
>> ShellPkg/Library/UefiShellLib/UefiShellLib.c
>>
>> if (mUnicodeCollationProtocol == NULL) {
>>  Status = gBS->LocateProtocol 
>> (,
>> NULL, (VOID**));
>>  ASSERT_EFI_ERROR (Status);
>>}
>>
>> It was working few weeks back and has now stopped working.
>> It's probably because  the platform is unable to locate this protocol 
>> "UnicodeCollationProtocol".
>> Is Anyone else facing the same issue?
>> Does the new ShellPkg requires additional packages/infs to be 
>> included in the platform description file to work with latest changes  
>> to get past this error?
>>
>> Thanks,
>> Supreeth
>> IMPORTANT NOTICE: The contents of this email and any attachments are 
>> confidential and may also be privileged. If you are not the intended 
>> recipient, please notify the sender immediately and do not disclose 
>> the contents to any other person, use it for any purpose, or store or 
>> copy the information in any medium. Thank you.
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services

[Tim Lewis]

Eugene --

Since the standalone file type isn't yet in the EDK2 code, the build system 
will not be able to make this distinction in the library's INF file. 

Tim


-Original Message-
From: Cohen, Eugene [mailto:eug...@hp.com] 
Sent: Friday, September 30, 2016 9:51 AM
To: Tim Lewis <tim.le...@insyde.com>; Laszlo Ersek <ler...@redhat.com>; 
edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Kinney, Michael D 
<michael.d.kin...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Andrew Fish 
(af...@apple.com) <af...@apple.com>
Subject: RE: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle 
Services

Tim,

My focus at the moment is on standalone SMM drivers, but in order to support 
the dual-mode DXE_SMM_DRIVER modules we could have another instance that does 
the InSmm check at runtime.

Eugene

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Friday, September 30, 2016 10:41 AM
> To: Cohen, Eugene <eug...@hp.com>; Laszlo Ersek <ler...@redhat.com>; 
> edk2-devel@lists.01.org ; Kinney, Michael D 
> <michael.d.kin...@intel.com>; Yao, Jiewen <jiewen@intel.com>; 
> Andrew Fish (af...@apple.com) <af...@apple.com>
> Subject: RE: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol 
> and Handle Services
> 
> Eugene --
> 
> Since SMM drivers today are actually DXE drivers during the 
> initialization phase, are you going to (a) have your library check 
> InSmm? or (b) only work with pure SMM stand-alone drivers?
> 
> Thanks,
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Cohen, Eugene
> Sent: Friday, September 30, 2016 9:37 AM
> To: Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org 
> <edk2-de...@ml01.01.org>; Kinney, Michael D 
> <michael.d.kin...@intel.com>; Yao, Jiewen <jiewen@intel.com>; 
> Andrew Fish (af...@apple.com) <af...@apple.com>
> Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol 
> and Handle Services
> 
> Laszlo,
> 
> > As far as I know:
> > - the DXE and SMM protocol databases are distinct,
> > - the same protocol GUID may or may not be installed (on one or
> more)
> > handle(s) in either,
> > - even if a protocol GUID exists uniquely in exactly one of those 
> > databases, the locator function would have to return which database 
> > the GUID was found.
> >
> > My point is that every wrapper function that returns a protocol 
> > interface (or several protocol interfaces), or handles, each such 
> > return value will likely have to be qualified with the database 
> > where
> it was found.
> 
> The intent here is to only search the UEFI DB from a DXE/UEFI driver 
> and the SMM DB from an SMM driver and not to cross between.  So which 
> protocol DB is searched is purely a function of the module type (i.e. 
> what instance of the ProtocolLib it was linked against).  This is 
> analogous to what is done with MemoryAllocationLib which either 
> allocates from the UEFI memory pools for UEFI/DXE modules 
> (UefiMemoryAllocationLib instance) or from the SMM memory pools for 
> SMM modules (SmmMemoryAllocationLib).
> 
> Sorry I wasn't more clear initially.
> 
> Eugene
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services

[Tim Lewis]

Eugene --

Since SMM drivers today are actually DXE drivers during the initialization 
phase, are you going to (a) have your library check InSmm? or (b) only work 
with pure SMM stand-alone drivers?

Thanks,

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
Eugene
Sent: Friday, September 30, 2016 9:37 AM
To: Laszlo Ersek ; edk2-devel@lists.01.org 
; Kinney, Michael D ; Yao, 
Jiewen ; Andrew Fish (af...@apple.com) 
Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle 
Services

Laszlo,

> As far as I know:
> - the DXE and SMM protocol databases are distinct,
> - the same protocol GUID may or may not be installed (on one or more)
> handle(s) in either,
> - even if a protocol GUID exists uniquely in exactly one of those 
> databases, the locator function would have to return which database 
> the GUID was found.
> 
> My point is that every wrapper function that returns a protocol 
> interface (or several protocol interfaces), or handles, each such 
> return value will likely have to be qualified with the database where it was 
> found.

The intent here is to only search the UEFI DB from a DXE/UEFI driver and the 
SMM DB from an SMM driver and not to cross between.  So which protocol DB is 
searched is purely a function of the module type (i.e. what instance of the 
ProtocolLib it was linked against).  This is analogous to what is done with 
MemoryAllocationLib which either allocates from the UEFI memory pools for 
UEFI/DXE modules (UefiMemoryAllocationLib instance) or from the SMM memory 
pools for SMM modules (SmmMemoryAllocationLib).

Sorry I wasn't more clear initially.

Eugene
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Protocol EFI_FORM_BROWSER_EXTENSION_PROTOCOL - included in UDK code but not part of the spec

[Tim Lewis]

Liming --

Could you change the protocol name, and then use a typedef with the old name 
for compatibility?

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
Liming
Sent: Tuesday, September 20, 2016 8:57 PM
To: Boaz Kahana ; edk2-devel@lists.01.org
Subject: Re: [edk2] Protocol EFI_FORM_BROWSER_EXTENSION_PROTOCOL - included in 
UDK code but not part of the spec

Boaz:
  This protocol is edk2 implement protocol. We have no plan to propose it to 
UEFI spec. Its EFI_ prefix is history reason. To avoid the incompatible change, 
we don't change its definition. But for any new introduced protocol, we will 
insist on this rule without EFI_ prefix. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Boaz Kahana
> Sent: Friday, September 16, 2016 8:25 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Protocol EFI_FORM_BROWSER_EXTENSION_PROTOCOL - 
> included in UDK code but not part of the spec
> 
> The protocol EFI_FORM_BROWSER_EXTENSION_PROTOCOL is defined in 
> MdeModulePkg\Include\Protocol\FormBrowserEx.h with EFI_ prefix 
> although it is not part of the UEFI spec.
> (It was added by Intel - Liming - in Sep 2011)
> 
> IMHO it should be added to the UEFI spec otherwise it should not use 
> the EFI_ prefix.
> 
> Boaz
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Shell version 2.2

[Tim Lewis]

Yes,  but they are the same numbers. So I think this is probably a 

The specification says (in the Shell protocol section's Related Defintiions):

#define EFI_SHELL_MAJOR_VERSION 2
#define EFI_SHELL_MINOR_VERSION 2

And, from ver.c:

ShellPrintHiiEx (
  0,
  gST->ConOut->Mode->CursorRow,
  NULL,
  STRING_TOKEN (STR_VER_OUTPUT_SIMPLE),
  gShellLevel3HiiHandle,
  gEfiShellProtocol->MajorVersion,
  gEfiShellProtocol->MinorVersion
 );

And the shell protocol instance comes from ShellProtocol.c (see below):

EFI_SHELL_PROTOCOL mShellProtocol = {
  EfiShellExecute,
  EfiShellGetEnv,
  EfiShellSetEnv,
  EfiShellGetAlias,
  EfiShellSetAlias,
  EfiShellGetHelpText,
  EfiShellGetDevicePathFromMap,
  EfiShellGetMapFromDevicePath,
  EfiShellGetDevicePathFromFilePath,
  EfiShellGetFilePathFromDevicePath,
  EfiShellSetMap,
  EfiShellGetCurDir,
  EfiShellSetCurDir,
  EfiShellOpenFileList,
  EfiShellFreeFileList,
  EfiShellRemoveDupInFileList,
  EfiShellBatchIsActive,
  EfiShellIsRootShell,
  EfiShellEnablePageBreak,
  EfiShellDisablePageBreak,
  EfiShellGetPageBreak,
  EfiShellGetDeviceName,
  (EFI_SHELL_GET_FILE_INFO)FileHandleGetInfo, //*
  (EFI_SHELL_SET_FILE_INFO)FileHandleSetInfo, //*
  EfiShellOpenFileByName,
  EfiShellClose,
  EfiShellCreateFile,
  (EFI_SHELL_READ_FILE)FileHandleRead,//*
  (EFI_SHELL_WRITE_FILE)FileHandleWrite,  //*
  (EFI_SHELL_DELETE_FILE)FileHandleDelete,//*
  EfiShellDeleteFileByName,
  (EFI_SHELL_GET_FILE_POSITION)FileHandleGetPosition, //*
  (EFI_SHELL_SET_FILE_POSITION)FileHandleSetPosition, //*
  (EFI_SHELL_FLUSH_FILE)FileHandleFlush,  //*
  EfiShellFindFiles,
  EfiShellFindFilesInDir,
  (EFI_SHELL_GET_FILE_SIZE)FileHandleGetSize, //*
  EfiShellOpenRoot,
  EfiShellOpenRootByHandle,
  NULL,
  SHELL_MAJOR_VERSION,
  SHELL_MINOR_VERSION,

  // New for UEFI Shell 2.1
  EfiShellRegisterGuidName,
  EfiShellGetGuidName,
  EfiShellGetGuidFromName,
  EfiShellGetEnvEx
};

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Friday, August 05, 2016 12:10 PM
To: Tim Lewis <tim.le...@insyde.com>; Meenakshi Aggarwal 
<meenakshi.aggar...@nxp.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org>
Cc: Carsey, Jaben <jaben.car...@intel.com>
Subject: Re: [edk2] Shell version 2.2

Tim,

Yes, ver command would output that the version of the shell is different.

The #define below is specifically the version of the Protocol, not the version 
of the spec.

It could have been a miss on the part of the committee, but that was hoe I 
interpreted the non-change to the protocol version.

-Jaben

> -----Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Friday, August 5, 2016 11:36 AM
> To: Carsey, Jaben <jaben.car...@intel.com>; Meenakshi Aggarwal 
> <meenakshi.aggar...@nxp.com>; edk2-devel@lists.01.org  de...@ml01.01.org>
> Subject: RE: Shell version 2.2
> Importance: High
> 
> Jaben --
> 
> Are there no shell commands where the standard command-line parameters 
> have changed?
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Carsey, Jaben
> Sent: Friday, August 05, 2016 10:26 AM
> To: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>; edk2- 
> de...@lists.01.org <edk2-de...@ml01.01.org>
> Cc: Carsey, Jaben <jaben.car...@intel.com>
> Subject: Re: [edk2] Shell version 2.2
> 
> I think that that version (2.1) is correct for the version of the 
> protocol.  The protocol API was not changed for the UEFI Shell 2.2.
> 
> That is the current version and should support the 2.2 spec.
> 
> -Jaben
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Meenakshi Aggarwal
> > Sent: Friday, August 5, 2016 2:20 AM
> > To: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>
> > Subject: [edk2] Shell version 2.2
> > Importance: High
> >
> > Hi,
> >
> >
> > I can see UEFI shell specification 2.2
> > (http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pd
> > f) is available, But on edk2 master branch current version of Shell 
> > is still showing
> 2.1.
> >
> > File:ShellPkg/Include/Protocol/EfiShell.h
> >
> > enum ShellVersion {
> >   SHELL_MAJOR_VERSION = 2,
> >   SHELL_MINOR_VERSION = 1
> > };
> >
> >
> >
> > Please tell if I am looking at correct file, actually I want to 
> > update my shell to 2.2, but it looks like edk2 master branch doesn't 
> > support shell
> specification 2.2.
> >
> > Is my

Re: [edk2] Shell version 2.2

[Tim Lewis]

Jaben --

Are there no shell commands where the standard command-line parameters have 
changed? 

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Friday, August 05, 2016 10:26 AM
To: Meenakshi Aggarwal ; edk2-devel@lists.01.org 

Cc: Carsey, Jaben 
Subject: Re: [edk2] Shell version 2.2

I think that that version (2.1) is correct for the version of the protocol.  
The protocol API was not changed for the UEFI Shell 2.2. 

That is the current version and should support the 2.2 spec.

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Meenakshi Aggarwal
> Sent: Friday, August 5, 2016 2:20 AM
> To: edk2-devel@lists.01.org 
> Subject: [edk2] Shell version 2.2
> Importance: High
> 
> Hi,
> 
> 
> I can see UEFI shell specification 2.2
> (http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) is
> available, But on edk2 master branch current version of Shell is still 
> showing 2.1.
> 
> File:ShellPkg/Include/Protocol/EfiShell.h
> 
> enum ShellVersion {
>   SHELL_MAJOR_VERSION = 2,
>   SHELL_MINOR_VERSION = 1
> };
> 
> 
> 
> Please tell if I am looking at correct file, actually I want to update my 
> shell to
> 2.2, but it looks like edk2 master branch doesn't support shell specification 
> 2.2.
> 
> Is my understanding correct?
> 
> 
> 
> Thanks & Regards,
> Meenakshi
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with .depex

[Tim Lewis]

Jordan --

As a company that delivers a lot of mixed binary/source builds, we see .depex 
as actually important for ease of maintenance. The .fdf syntax can work, as you 
mention, but it is actually requires an extra step for those of us maintaining 
binary modules. Why? Because .depex is derived from the .inf of the module 
*and* the .infs of all library instances which the module is linked against. 
While this can be tracked down using a build report, it is problematic and 
likely to introduce hard to track bugs. Since .depex is a normal product of the 
source build process, it is convenient.

As for the open-source, I would only note that it is used only in the exact 
same cases where the module itself is delivered as a binary. In fact, it could 
be checked in to the tree as a complete FFS file (no .efi at all).

Thanks,

Tim




-Original Message-
From: Jordan Justen [mailto:jordan.l.jus...@intel.com] 
Sent: Monday, August 01, 2016 12:03 AM
To: Kinney, Michael D <michael.d.kin...@intel.com>; Leif Lindholm 
<leif.lindh...@linaro.org>; Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org; Andrew Fish 
<af...@apple.com>
Subject: RE: [edk2] [PATCH] add top-level .gitattributes file, dealing with 
.depex

On 2016-07-31 16:52:23, Kinney, Michael D wrote:
> Jordan,
> 
> UEFI Drivers distributed as binaries do not need depex sections.
> 
> PI modules distributed as binaries do require a .depex binary.
> 

They may require a depex, but, as mentioned below, they can also add it 
directly in the .fdf. As it stands, apparently we have 1 .depex file in the 
tree, and it is unused.

Aside from this, under what conditions would we take such binaries into the EDK 
II tree? Today we have the ShellPkg and FatPkg binaries in the EDK II tree, but 
we recently discussed removing even those.

For an open source project, I think it is best to not have pre-built binaries, 
unless there is some very compelling reason. Previously there was some license 
funniness on FatPkg, but now that is gone. If it took an hour to build FatPkg, 
then that might also be something to discuss. :)

I don't think adding the .gitattributes is really a problem, aside from the 
fact that it implies that we might actually have a reason to add a .depex file 
to the source tree.

-Jordan

> So I would recommend .depex binary files be treated the same as binary 
> .efi files by GIT.  So it does sound like we need some minor updates 
> to GIT attributes.
> 
> If we have an example of a binary module that is providing more binary 
> leaf sections than are actually required and/or used, then yes, the 
> binary module should be cleaned up to remove the unused content.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Justen, Jordan L
> > Sent: Sunday, July 31, 2016 3:58 PM
> > To: Leif Lindholm <leif.lindh...@linaro.org>; Tim Lewis 
> > <tim.le...@insyde.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D 
> > <michael.d.kin...@intel.com>; edk2-de...@ml01.01.org 
> > <edk2-devel@lists.01.org>; Andrew Fish <af...@apple.com>
> > Subject: Re: [edk2] [PATCH] add top-level .gitattributes file, 
> > dealing with .depex
> > 
> > On 2016-07-30 11:33:43, Leif Lindholm wrote:
> > > Hi Tim,
> > >
> > > Thanks for the warning, and investigation.
> > >
> > > Does this mean that you think we should ban the inclusion of 
> > > .depex files in EDK2, including future platform trees?
> > 
> > I don't know about banning it, but at least we could wait for 
> > someone to make a reasonable argument why they are needed.
> > 
> > Even for binary only modules, it looks like the fdf method outlined 
> > below is preferable to a pre-built .depex.
> > 
> > If (at a future point) the reason for using a .depex is to support a 
> > binary only module in a supposedly open platform under EDK II, then 
> > I guess we can decide if that is a good idea at that point.
> > 
> > Should we delete this one unused .depex from the tree?
> > 
> > -Jordan
> > 
> > > (If not, this patch is
> > > still needed for git to work predictably with these files.)
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > > On Fri, Jul 29, 2016 at 05:12:49PM +, Tim Lewis wrote:
> > > > It appears that this file is not actually used. It is only 
> > > > referenced in the [Rule.Common.UEFI_DRIVER.NATIVE_BINARY] rule 
> > > > in PlatformPkg.fdf. A little further research shows that an 
> > > > alternate method was used for 

Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with .depex

[Tim Lewis]

It appears that this file is not actually used. It is only referenced in the 
[Rule.Common.UEFI_DRIVER.NATIVE_BINARY] rule in PlatformPkg.fdf. A little 
further research shows that an alternate method was used for the actual GOP 
binary (see below). A grep of the entire tree shows that no one uses this rule 
NATIVE_BINARY. So it looks like it can just be cut out.

BTW, the downside of the method used for the binary version of the GOP driver, 
is that those drivers cannot use PCDs, since the PCD database is created based 
on references in the .inf. GOP works because it is pure UEFI and (therefore) 
doesn't use PCDs.

Tim

FILE DRIVER = FF0C8745-3270-4439-B74F-3E45F8C77064 {
  SECTION DXE_DEPEX_EXP = {gPlatformGOPPolicyGuid}
  SECTION PE32 = 
Vlv2MiscBinariesPkg/GOP/7.2.1011/RELEASE_VS2008x86/$(DXE_ARCHITECTURE)/IntelGopDriver.efi
  SECTION UI = "IntelGopDriver"
}

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif 
Lindholm
Sent: Friday, July 29, 2016 9:45 AM
To: Laszlo Ersek 
Cc: michael.d.kin...@intel.com; Jordan Justen ; 
edk2-de...@ml01.01.org; Andrew Fish 
Subject: Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with 
.depex

On Thu, Jul 07, 2016 at 05:03:13PM +0200, Laszlo Ersek wrote:
> On 07/07/16 16:24, Leif Lindholm wrote:
> > Git tends to see .depex files as text, causing hideous patches being 
> > generated (and breaking PatchCheck.py).
> > 
> > Add a .gitattributes file instructing git to treat them as binary.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Leif Lindholm 
> > ---
> >  .gitattributes | 1 +
> >  1 file changed, 1 insertion(+)
> >  create mode 100644 .gitattributes
> > 
> > diff --git a/.gitattributes b/.gitattributes new file mode 100644 
> > index 000..2d8a45b
> > --- /dev/null
> > +++ b/.gitattributes
> > @@ -0,0 +1 @@
> > +*.depex binary
> > 
> 
> What generates .depex files? I've never seen any.
> 
> Also, unless you add .depex files with "git add" to the set of tracked 
> files, no patches / diffs should cover them. What am I missing? :)
> 
> ... Hm, after
> 
> $ find . -iname "*.depex"
> 
> I see .depex files in Build/ (which should be ignored altogether), and
> 
> ./Vlv2TbltDevicePkg/IntelGopDepex/IntelGopDriver.depex
> 
> Why does that file exist in the tree? Let me see... git log says nothing 
> relevant (the file dates back to commit 3cbfba02fef9, "Upload BSD-licensed 
> Vlv2TbltDevicePkg and Vlv2DeviceRefCodePkg to").
> 
> Grepping the tree for the filename itself leads to:
> 
> Vlv2TbltDevicePkg/PlatformPkg.fdf:DXE_DEPEX DXE_DEPEX Optional  
> $(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex
> Vlv2TbltDevicePkg/PlatformPkgGcc.fdf:DXE_DEPEX DXE_DEPEX Optional  
> $(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex
> 
> Do these rules exist to override the DEPEX sections of binary-only modules? 
> If so: that's horrible.
> 
> Anyway, given that edk2 contains at least one .depex file, and your patch is 
> correct according to 
> :
> 
> Reviewed-by: Laszlo Ersek 

Thanks!

I had hoped for comments from someone else on cc, since we don't have any 
Maintainers.txt entry for the top level directory :)

But if I don't hear anything before Monday, I'll push it then.

Regards,

Leif

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

[Tim Lewis]

Laszlo --

I hear what you are saying. However, I think this is a different case:

1) How many ARM-defined standards are in the MdePkg\Include\IndustryStandards.h 
file? By my count, none. This is by design. They are all in other packages. 
DMAR is there because it was grandfathered in from a generation of tianocore 
when only architectures provided by Intel were prevalent for UEFI.
 2) Now that there is an Intel package for Intel-silicon related header files 
and modules, now is the time to move it.
3) OS cases are a little different, since we don't usually produce Microsoft 
(or Redhat or Canonical or BSD) specific modules for UEFI. There are header 
files and a smattering of files that deal with these. If we created a 
MicrosoftOsPkg, I'd move the header files there as well. 

Tim

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, July 28, 2016 9:29 AM
To: Tim Lewis <tim.le...@insyde.com>; Giri P Mudusuru 
<giri.p.mudus...@intel.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org>
Cc: Michael Kinney <michael.d.kin...@intel.com>; Jiewen Yao 
<jiewen@intel.com>; Liming Gao <liming@intel.com>
Subject: Re: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

On 07/28/16 18:00, Tim Lewis wrote:
> Giri --
> 
> Is MdePkg the right place for this? This appears to be an 
> Intel-specific definition, right? I understand that it was in 
> IndustryStandard for EdkCompatibilityPkg, but it might do better now 
> in the IntelSiliconPkg.

DMAR is defined by a widely used industry standard / spec; I think it belongs 
to MdePkg.

Prior art (gathered with

  git log --reverse --stat=1000 --stat-graph-width=20 -- 
MdePkg/Include/IndustryStandard

and by searching for "Microsoft", case-insensitively):

(1)

commit 32df01ff685b9de50555bac040166b17a061ea9b
Author: Chao Zhang <chao.b.zh...@intel.com>
Date:   Wed May 13 08:27:04 2015 +

MdePkg: Add Microsoft UX capsule GUID & layout

Add Microsoft UX capsule GUID & layout into IndustryStandard

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang <chao.b.zh...@intel.com>
Reviewed-by: Gao Liming <liming@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17424 
6f19259b-4bc3-4df7-8a09-765794883524

 MdePkg/Include/IndustryStandard/WindowsUxCapsule.h | 46 
 1 file changed, 46 insertions(+)

(2)

commit c374aa43a199a5aab53218ef3cf99284ba19ae98
Author: Heyi Guo <heyi@linaro.org>
Date:   Fri Nov 13 03:27:54 2015 +

Update SPCR table definition per SPCR specification v1.03.

Document link:

http://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Heyi Guo" <heyi@linaro.org>
Reviewed-by: "Jiewen Yao" <jiewen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18782 
6f19259b-4bc3-4df7-8a09-765794883524

 MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h | 12 

 1 file changed, 8 insertions(+), 4 deletions(-)

(3) 

commit 31a9d3b419accbbc5463c71221b3b30a46f9ee73
Author: Yao, Jiewen <jiewen@intel.com>
Date:   Tue Jan 19 13:17:10 2016 +

MdePkg: Update MorLock comment to latest doc.

Microsoft updated secure MOR lock document with version 2.
So we update comment here.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen@intel.com>
Reviewed: "Zhang, Chao B" <chao.b.zh...@intel.com>


git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19687 
6f19259b-4bc3-4df7-8a09-765794883524

 MdePkg/Include/IndustryStandard/MemoryOverwriteRequestControlLock.h | 16 

 1 file changed, 8 insertions(+), 8 deletions(-)

(4)

commit a0606fc705f5bdfbe2366a7f3c6dd7491da74394
Author: Sami Mujawar <sami.muja...@arm.com>
Date:   Fri Mar 4 14:58:33 2016 +

MdePkg: Add ARM Serial Port Subtype definitions

The Serial Port Console Redirection Table specification Version 1.03 -
August 10, 2015 adds support for Serial Port Subtypes for ARM. These
Subtypes are described in the Table 3 of the Microsoft Debug Port Table
2 (DBG2) Specification - December 10, 2015.

This patch adds macro definitions for these.

Code at: 
https://github.com/EvanLloyd/tianocore/commit/79678a0f399e97883cfba09275e750861e24cd70

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
Reviewed-by: Yao Jiewen <jiewen@intel.com>
Reviewed-by: Liming Gao <liming@intel.com>

 MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h | 25 

Re: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

[Tim Lewis]

Giri --

Is MdePkg the right place for this? This appears to be an Intel-specific 
definition, right? I understand that it was in IndustryStandard for 
EdkCompatibilityPkg, but it might do better now in the IntelSiliconPkg.

Regards,

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Giri P 
Mudusuru
Sent: Wednesday, July 27, 2016 11:46 PM
To: edk2-devel@lists.01.org
Cc: Michael Kinney ; Jiewen Yao 
; Liming Gao 
Subject: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

DMA Remapping Reporting (DMAR) ACPI table definitions from Intel(R) 
Virtualization Technology for Directed I/O (VT-D) Architecture Specification 
v2.4 dated June 2016.

This replaces the DMARemappingReportingTable.h from 
EdkCompatibilityPkg\Foundation\Include\IndustryStandard

Cc: Michael Kinney 
Cc: Liming Gao 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru 
---
 .../IndustryStandard/DmaRemappingReportingTable.h  | 254 +
 1 file changed, 254 insertions(+)
 create mode 100644 MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h

diff --git a/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h 
b/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h
new file mode 100644
index 000..691aea0
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h
@@ -0,0 +1,254 @@
+/** @file
+  DMA Remapping Reporting (DMAR) ACPI table definition from Intel(R)
+  Virtualization Technology for Directed I/O (VT-D) Architecture Specification.
+
+  Copyright (c) 2016, Intel Corporation. All rights reserved.  This 
+ program and the accompanying materials  are licensed and made 
+ available under the terms and conditions of the BSD License  which 
+ accompanies this distribution.  The full text of the license may be 
+ found at  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,  
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+  @par Revision Reference:
+- Intel(R) Virtualization Technology for Directed I/O (VT-D) Architecture
+  Specification v2.4, Dated June 2016.
+  
+ http://www.intel.com/content/dam/www/public/us/en/documents/product-sp
+ ecifications/vt-directed-io-spec.pdf
+
+  @par Glossary:
+- HPET - High Precision Event Timer
+- NUMA - Non-uniform Memory Access
+**/
+#ifndef _DMA_REMAPPING_REPORTING_TABLE_H_ #define 
+_DMA_REMAPPING_REPORTING_TABLE_H_
+
+#pragma pack(1)
+
+///
+/// DMA Remapping Reporting Table Revision ///
+#define EFI_ACPI_DMAR_DESCRIPTION_TABLE_REVISION   0x01
+
+///
+/// DMA-Remapping Reporting ACPI Table definitions from section 8.1 
+///@{
+#define EFI_ACPI_DMAR_TABLE_FLAGS_INTR_REMAP_SETBIT0
+#define EFI_ACPI_DMAR_TABLE_FLAGS_X2APIC_OPT_OUT_SETBIT1
+///@}
+
+///
+/// Remapping Structure Types definitions from section 8.2 ///@{
+#define EFI_ACPI_DMAR_TYPE_DRHD   0x00
+#define EFI_ACPI_DMAR_TYPE_RMRR   0x01
+#define EFI_ACPI_DMAR_TYPE_ATSR   0x02
+#define EFI_ACPI_DMAR_TYPE_RHSA   0x03
+#define EFI_ACPI_DMAR_TYPE_ANDD   0x04
+///@}
+
+///
+/// Definition for DMA Remapping Structure Header /// typedef struct {
+  UINT16Type;
+  UINT16Length;
+} EFI_ACPI_DMAR_STRUCTURE_HEADER;
+
+///
+/// Definition for DMA-Remapping PCI Path /// typedef struct {
+  UINT8 Device;
+  UINT8 Function;
+} EFI_ACPI_DMAR_PCI_PATH;
+
+///
+/// DMA-Remapping Device Scope Entry Structure definitions from section 
+8.3.1 ///@{
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_PCI_ENDPOINT   0x01
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_PCI_BRIDGE 0x02
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_IOAPIC 0x03
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_MSI_CAPABLE_HPET   0x04
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_ACPI_NAMESPACE_DEVICE  0x05 
+///@}
+
+///
+/// Device Scope Structure is defined in section 8.3.1 /// typedef 
+struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT16Reserved2;
+  UINT8 EnumerationId;
+  UINT8 StartBusNumber;
+} EFI_ACPI_DMAR_DEVICE_SCOPE_STRUCTURE_HEADER;
+
+/**
+  DMA-remapping hardware unit definition (DRHD) structure is defined in
+  section 8.3. This uniquely represents a remapping hardware unit 
+present
+  in the platform. There must be at least one instance of this 
+structure
+  for each PCI segment in the platform.
+**/
+typedef struct {
+  EFI_ACPI_DMAR_STRUCTURE_HEADER  Header;
+  /**
+- Bit[0]: INCLUDE_PCI_ALL
+  - If Set, this remapping hardware unit has under its scope all
+PCI compatible devices in the specified Segment, except devices
+reported under the scope of other 

Re: [edk2] StdLib usage for drivers?

[Tim Lewis]

Jaben, thanks. 

I think we're on the same page as far as the pre-Shell limitations for paths.

The downside of using this strategy is the code size overhead for UEFI drivers.

BTW, we've extended the ShellLib to contain wrapper functions for nearly all  
Shell Protocol member functions. It makes smaller and cleaner shell 
applications.

Tim

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com] 
Sent: Wednesday, July 06, 2016 2:12 PM
To: Tim Lewis <tim.le...@insyde.com>; af...@apple.com
Cc: edk2-devel@lists.01.org; Michael Zimmermann <sigmaepsilo...@gmail.com>; 
Daryl McDaniel (edk2-li...@mc2research.org) <edk2-li...@mc2research.org>; 
Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [edk2] StdLib usage for drivers?

You are correct.

Device paths always work fine.  DevicePaths are what are in Boot and 
Driver variables.

The missing piece is the conversion from FSX to the starting node.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Wednesday, July 06, 2016 2:09 PM
> To: Carsey, Jaben <jaben.car...@intel.com>; af...@apple.com
> Cc: edk2-devel@lists.01.org; Michael Zimmermann 
> <sigmaepsilo...@gmail.com>; Daryl McDaniel 
> (edk2-li...@mc2research.org) <edk2-li...@mc2research.org>
> Subject: Re: [edk2] StdLib usage for drivers?
> Importance: High
> 
> Sure, the FSx: names are created by the shell. So before the shell 
> loads, there is no Shell protocol, so no mapping names. That means 
> that the StdLib implementation statically linked with a UEFI driver 
> will not find the Shell protocol and will not be able to match any 
> volume names (FSx or consistent mapping or any user-created mappings), 
> but the rest of the device path rules should apply. So, for example 
> \PciRoot(0)\Pci(0,31)\Usb(0,0)\Mbr()\BootX64.efi could work, right? 
> Those are the types of device paths that a UEFI driver might find in 
> the Boot variables and want to use.
> 
> Tim
> 
> -Original Message-----
> From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> Sent: Wednesday, July 06, 2016 2:02 PM
> To: Tim Lewis <tim.le...@insyde.com>; af...@apple.com
> Cc: edk2-devel@lists.01.org; Michael Zimmermann 
> <sigmaepsilo...@gmail.com>; Daryl McDaniel 
> (edk2-li...@mc2research.org) <edk2-li...@mc2research.org>; Carsey, 
> Jaben <jaben.car...@intel.com>
> Subject: RE: [edk2] StdLib usage for drivers?
> 
> Tim,
> 
> Good catch.  I did not consider HII stuff.
> 
> If you use a UEFI Shell Spec defined "consistent map name", it works 
> without the shell since that is a 1:1 conversion with DevicePath.
> 
> If you use a Shell map name, then it can try, but there is no 
> guarantee that enumerations are right.  Using FS0: based mapping in a 
> driver is very scary to me.
> 
> -Jaben
> 
> > -Original Message-
> > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > Sent: Wednesday, July 06, 2016 1:58 PM
> > To: Carsey, Jaben <jaben.car...@intel.com>; af...@apple.com
> > Cc: edk2-devel@lists.01.org; Michael Zimmermann 
> > <sigmaepsilo...@gmail.com>; Daryl McDaniel
> > (edk2-li...@mc2research.org) <edk2-li...@mc2research.org>
> > Subject: RE: [edk2] StdLib usage for drivers?
> > Importance: High
> >
> > Jaben --
> >
> > I can certainly recall instances where drivers that publish HII 
> > setup pages load things from the disk (such as when checking for 
> > specific file
> names).
> >
> > I also seem to recall that the original EDK shell library was 
> > designed to that volume names were simply ignored if the shell 
> > protocol was not present. This is essentially what the Shell APIs 
> > do, right? They just convert mapping names into device path snippets.
> >
> > Tim
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Carsey, Jaben
> > Sent: Wednesday, July 06, 2016 1:53 PM
> > To: af...@apple.com
> > Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel@lists.01.org; 
> > Michael Zimmermann <sigmaepsilo...@gmail.com>; Daryl McDaniel
> (edk2-
> > li...@mc2research.org) <edk2-li...@mc2research.org>
> > Subject: Re: [edk2] StdLib usage for drivers?
> >
> > The thing that I am trying to figure out is what LibC APIs is really 
> > needed by the driver?
> >
> > UEFI Drivers are not supposed to do things like FILE I/O, so who 
> > cares if they would fail if they were called…
> >
> > Sidenote: I think that daShell.c is only used when you ask LibC for 
> > things t

Re: [edk2] StdLib usage for drivers?

[Tim Lewis]

Sure, the FSx: names are created by the shell. So before the shell loads, there 
is no Shell protocol, so no mapping names. That means that the StdLib 
implementation statically linked with a UEFI driver will not find the Shell 
protocol and will not be able to match any volume names (FSx or consistent 
mapping or any user-created mappings), but the rest of the device path rules 
should apply. So, for example \PciRoot(0)\Pci(0,31)\Usb(0,0)\Mbr()\BootX64.efi 
could work, right? Those are the types of device paths that a UEFI driver might 
find in the Boot variables and want to use.

Tim

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com] 
Sent: Wednesday, July 06, 2016 2:02 PM
To: Tim Lewis <tim.le...@insyde.com>; af...@apple.com
Cc: edk2-devel@lists.01.org; Michael Zimmermann <sigmaepsilo...@gmail.com>; 
Daryl McDaniel (edk2-li...@mc2research.org) <edk2-li...@mc2research.org>; 
Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [edk2] StdLib usage for drivers?

Tim,

Good catch.  I did not consider HII stuff.

If you use a UEFI Shell Spec defined "consistent map name", it works without 
the shell since that is a 1:1 conversion with DevicePath.  

If you use a Shell map name, then it can try, but there is no guarantee that 
enumerations are right.  Using FS0: based mapping in a driver is very scary to 
me.

-Jaben

> -----Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, July 06, 2016 1:58 PM
> To: Carsey, Jaben <jaben.car...@intel.com>; af...@apple.com
> Cc: edk2-devel@lists.01.org; Michael Zimmermann 
> <sigmaepsilo...@gmail.com>; Daryl McDaniel 
> (edk2-li...@mc2research.org) <edk2-li...@mc2research.org>
> Subject: RE: [edk2] StdLib usage for drivers?
> Importance: High
> 
> Jaben --
> 
> I can certainly recall instances where drivers that publish HII setup 
> pages load things from the disk (such as when checking for specific file 
> names).
> 
> I also seem to recall that the original EDK shell library was designed 
> to that volume names were simply ignored if the shell protocol was not 
> present. This is essentially what the Shell APIs do, right? They just 
> convert mapping names into device path snippets.
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Carsey, Jaben
> Sent: Wednesday, July 06, 2016 1:53 PM
> To: af...@apple.com
> Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel@lists.01.org; 
> Michael Zimmermann <sigmaepsilo...@gmail.com>; Daryl McDaniel (edk2-
> li...@mc2research.org) <edk2-li...@mc2research.org>
> Subject: Re: [edk2] StdLib usage for drivers?
> 
> The thing that I am trying to figure out is what LibC APIs is really 
> needed by the driver?
> 
> UEFI Drivers are not supposed to do things like FILE I/O, so who cares 
> if they would fail if they were called…
> 
> Sidenote: I think that daShell.c is only used when you ask LibC for 
> things that come from the shell…
> 
> This snippet makes standard APIs point to shell specific ones…
> LibC/Uefi/Devices/UefiShell/daShell.c:814:  Stream->Abstraction.fo_close=
> _ShellClose;
> LibC/Uefi/Devices/UefiShell/daShell.c:815:  Stream->Abstraction.fo_read =
> _ShellRead;
> LibC/Uefi/Devices/UefiShell/daShell.c:816:  Stream->Abstraction.fo_write=
> _ShellWrite;
> LibC/Uefi/Devices/UefiShell/daShell.c:818:  Stream->Abstraction.fo_poll =
> _ShellPoll;
> LibC/Uefi/Devices/UefiShell/daShell.c:820:  Stream->Abstraction.fo_stat =
> _ShellStat;
> LibC/Uefi/Devices/UefiShell/daShell.c:821:  Stream->Abstraction.fo_ioctl=
> _ShellIoctl;
> LibC/Uefi/Devices/UefiShell/daShell.c:822:  
> Stream->Abstraction.fo_delete = _ShellDelete;
> LibC/Uefi/Devices/UefiShell/daShell.c:823:  
> Stream->Abstraction.fo_rmdir = _ShellRmdir;
> LibC/Uefi/Devices/UefiShell/daShell.c:824:  
> Stream->Abstraction.fo_mkdir = _ShellMkdir;
> LibC/Uefi/Devices/UefiShell/daShell.c:825:  
> Stream->Abstraction.fo_rename = _ShellRename;
> LibC/Uefi/Devices/UefiShell/daShell.c:826:  Stream->Abstraction.fo_lseek=
> _ShellSeek;
> 
> 
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Wednesday, July 06, 2016 1:48 PM
> To: Carsey, Jaben <jaben.car...@intel.com>
> Cc: Michael Zimmermann <sigmaepsilo...@gmail.com>; Marvin Häuser 
> <marvin.haeu...@outlook.com>; edk2-devel@lists.01.org; edk2- 
> li...@mc2research.org
> Subject: Re: [edk2] StdLib usage for drivers?
> Importance: High
> 
> 
> On Jul 6, 2016, at 1:39 PM, Carsey, Jaben 
> <jaben.car...@intel.com<mailto:jaben.car...@intel.com>> wrote:
> 
> It works for libs.  If you 

Re: [edk2] StdLib usage for drivers?

[Tim Lewis]

Jaben --

I can certainly recall instances where drivers that publish HII setup pages 
load things from the disk (such as when checking for specific file names).

I also seem to recall that the original EDK shell library was designed to that 
volume names were simply ignored if the shell protocol was not present. This is 
essentially what the Shell APIs do, right? They just convert mapping names into 
device path snippets. 

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Wednesday, July 06, 2016 1:53 PM
To: af...@apple.com
Cc: Carsey, Jaben ; edk2-devel@lists.01.org; Michael 
Zimmermann ; Daryl McDaniel 
(edk2-li...@mc2research.org) 
Subject: Re: [edk2] StdLib usage for drivers?

The thing that I am trying to figure out is what LibC APIs is really needed by 
the driver?

UEFI Drivers are not supposed to do things like FILE I/O, so who cares if they 
would fail if they were called…

Sidenote: I think that daShell.c is only used when you ask LibC for things that 
come from the shell…

This snippet makes standard APIs point to shell specific ones…
LibC/Uefi/Devices/UefiShell/daShell.c:814:  Stream->Abstraction.fo_close= 
_ShellClose;
LibC/Uefi/Devices/UefiShell/daShell.c:815:  Stream->Abstraction.fo_read = 
_ShellRead;
LibC/Uefi/Devices/UefiShell/daShell.c:816:  Stream->Abstraction.fo_write= 
_ShellWrite;
LibC/Uefi/Devices/UefiShell/daShell.c:818:  Stream->Abstraction.fo_poll = 
_ShellPoll;
LibC/Uefi/Devices/UefiShell/daShell.c:820:  Stream->Abstraction.fo_stat = 
_ShellStat;
LibC/Uefi/Devices/UefiShell/daShell.c:821:  Stream->Abstraction.fo_ioctl= 
_ShellIoctl;
LibC/Uefi/Devices/UefiShell/daShell.c:822:  Stream->Abstraction.fo_delete   = 
_ShellDelete;
LibC/Uefi/Devices/UefiShell/daShell.c:823:  Stream->Abstraction.fo_rmdir= 
_ShellRmdir;
LibC/Uefi/Devices/UefiShell/daShell.c:824:  Stream->Abstraction.fo_mkdir= 
_ShellMkdir;
LibC/Uefi/Devices/UefiShell/daShell.c:825:  Stream->Abstraction.fo_rename   = 
_ShellRename;
LibC/Uefi/Devices/UefiShell/daShell.c:826:  Stream->Abstraction.fo_lseek= 
_ShellSeek;


From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, July 06, 2016 1:48 PM
To: Carsey, Jaben 
Cc: Michael Zimmermann ; Marvin Häuser 
; edk2-devel@lists.01.org; 
edk2-li...@mc2research.org
Subject: Re: [edk2] StdLib usage for drivers?
Importance: High


On Jul 6, 2016, at 1:39 PM, Carsey, Jaben 
> wrote:

It works for libs.  If you specify a specific LibraryClass implementation, it 
will not add a second of that library class.

Side note: what if you turn off AutoInitialize PCD for the shell lib?  That 
would get rid of your main issue (the constructor ASSERT)…  then we can see 
what other issues you have.


This seems like the set of library APIs that would be needed (and one usage of  
gEfiShellProtocol->SetCurDir()).

~/work/src/edk2/StdLib(master)>git grep Shell -- *.c 
LibC/Main/Main.c:20:#include   
LibC/Main/Main.c:130:ShellAppMain ( LibC/StdLib/Environs.c:23:#include  

LibC/StdLib/Environs.c:155:  OpStat = ShellExecute( , gMD->UString, 
FALSE, NULL, );
LibC/StdLib/Environs.c:167:are determined by the underlying UEFI Shell 
implementation.
LibC/StdLib/Environs.c:181:  EfiEnv = ShellGetEnvironmentVariable(gMD->UString);
LibC/StdLib/Environs.c:248:HostName = ShellGetEnvironmentVariable ( UName );
LibC/StdLib/Environs.c:254:  Status = ShellSetEnvironmentVariable ( UName, 
UValue, TRUE );
LibC/StdLib/Environs.c:265:Status = ShellSetEnvironmentVariable ( 
UName, UValue, FALSE );
LibC/Uefi/Devices/UefiShell/daShell.c:2:  Abstract device driver for the UEFI 
Shell-hosted environment.
LibC/Uefi/Devices/UefiShell/daShell.c:4:  In a Shell-hosted environment, this 
is the driver that is called LibC/Uefi/Devices/UefiShell/daShell.c:21:#include  

LibC/Uefi/Devices/UefiShell/daShell.c:40:/** EFI Shell specific operations for 
close().
LibC/Uefi/Devices/UefiShell/daShell.c:50:da_ShellClose(
LibC/Uefi/Devices/UefiShell/daShell.c:54:  EFIerrno = ShellCloseFile( 
(SHELL_FILE_HANDLE *)>devdata);
LibC/Uefi/Devices/UefiShell/daShell.c:61:/** EFI Shell specific operations for 
deleting a file or directory.
LibC/Uefi/Devices/UefiShell/daShell.c:71:da_ShellDelete(
LibC/Uefi/Devices/UefiShell/daShell.c:77:  Status = ShellDeleteFile( 
(SHELL_FILE_HANDLE *)>devdata);
LibC/Uefi/Devices/UefiShell/daShell.c:86:/** EFI Shell specific operations for 
setting the position within a file.
LibC/Uefi/Devices/UefiShell/daShell.c:97:da_ShellSeek(
LibC/Uefi/Devices/UefiShell/daShell.c:113:  Status = ShellSetFilePosition( 
FileHandle, 0xULL);
LibC/Uefi/Devices/UefiShell/daShell.c:117:  Status = ShellGetFilePosition( 
FileHandle, (UINT64 *));

Re: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC files

[Tim Lewis]

Sure. BTW, it appears I was wrong about the null-terminator for strings. Both 
examples I found internally assume it.



Here is an example



gInsydeTokenSpaceGuid.H2ODevicePath0|{UINT32(LOAD_OPTION_ACTIVE), \  // 
Attributes

  UINT16(^1 - ^0), \ // 
FilePathListLength

  ^0\// tag 
beginning of description

  L"Boot Description",\  // 
Description

  ^1\   // tag 
ending of description

 DevicePath(uefi-device-path),\// 
DevicePathList

 0x55, 0x00\   // 
OptionalData

 }



gInsydeTokenSpaceGuid.PcdPeiKernelDebugCodeTable|{ \

GUID("4AA65902-3ED3-43b3-A52B-FC1D6C077AE4"), 0x13, 0x09, \   # AhciBusPei

GUID("B7A5041A-78BA-49e3-B73B-54C757811FB6"), 0x13, 0x0A, \   # AtapiPeim

GUID("31e147a6-d39a-4147-9da3-befd4d523243"), 0x1F, 0x03, \   # CdExpressPei

   ...

GUID("----"), 0x00, 0x00} # EndEntry



gInsydeTokenSpaceGuid.PcdIhisiRegisterTable|{ \

  # Register IHISI AH=00h (VATSRead)

  UINT8(0x00),  "S00Kn_VatsRead0",UINT8(0x80), \

  ...

  # Register IHISI AH=4Bh (FBTSCommonRead)

  UINT8(0x4B),  "S4BKn_ComDataRead00",UINT8(0x80)  }

  }



-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, June 14, 2016 6:56 PM
To: Tim Lewis <tim.le...@insyde.com>; Zhu, Yonghong <yonghong@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Subject: RE: [RFC] Add more flexible PCD value formats in DEC/DSC files



Tim,



I think I see what you are suggesting, but a small example would help clarify.  
Can you provide a small example that demonstrates the source syntax and what it 
would be converted to for the PCD value assignment?



Thanks,



Mike



> -Original Message-

> From: Tim Lewis [mailto:tim.le...@insyde.com]

> Sent: Tuesday, June 14, 2016 5:32 PM

> To: Kinney, Michael D 
> <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; Zhu, Yonghong

> <yonghong@intel.com<mailto:yonghong@intel.com>>; 
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>

> Subject: RE: [RFC] Add more flexible PCD value formats in DEC/DSC

> files

>

> Mike --

>

> Yes, L"" works without a null-terminator. That's why we use it in

> numerous places, along with the PCD size.

>

> We do support expression syntax, esp. for [Defines] and

> FixedAtBuild/FeatureFlag PCDs where we can determine the value at build time. 
> Very useful for struct initialization.

> Using the UINTx() forms means that we aren't changing the size. Of

> course, we can't do strings at the moment because of the ambiguity.

>

> We did this to avoid having to go to full struct-style initialization.

> We actually went down that pack, but we found that many of the data

> structures don't fall well into C style structs (like SMBIOS records

> and Load Options) and needed instead just to present the information

> in a clear-enough form that people could re-write it.  Add on top of

> that the ability to force all PCDs of a specific token space GUID into the 
> PCD database and you get around the need for mega-PCD structs.

>

> This strategy mitigated the downside of our choice, which was

> inability to change individual fields easily, since structs never got as 
> large.

>

> Tim

>

> -Original Message-

> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of

> Kinney, Michael D

> Sent: Tuesday, June 14, 2016 5:22 PM

> To: Tim Lewis <tim.le...@insyde.com<mailto:tim.le...@insyde.com>>; Zhu, 
> Yonghong

> <yonghong@intel.com<mailto:yonghong@intel.com>>; edk2- 
> de...@lists.01.org<mailto:de...@lists.01.org>; Kinney, Michael D

> <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>

> Subject: Re: [edk2] [RFC] Add more flexible PCD value formats in

> DEC/DSC files

>

> Tim,

>

> No problem.  Glad to see the feedback.

>

> Would the multi-char '' or L'' string work for a Load Option string

> without a null- terminator.

>

> I agree that GUID() operator help avoid ambiguity with registry format

> GUIDs and subtraction operations.  We do not support expressions in

> default value assignments today, which is why it did not look like

> GUID() was required.  Do we really need expression support?

>

> For

Re: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC files

[Tim Lewis]

Mike --

Yes, L"" works without a null-terminator. That's why we use it in numerous 
places, along with the PCD size.

We do support expression syntax, esp. for [Defines] and 
FixedAtBuild/FeatureFlag PCDs where we can determine the value at build time. 
Very useful for struct initialization. Using the UINTx() forms means that we 
aren't changing the size. Of course, we can't do strings at the moment because 
of the ambiguity.

We did this to avoid having to go to full struct-style initialization. We 
actually went down that pack, but we found that many of the data structures 
don't fall well into C style structs (like SMBIOS records and Load Options) and 
needed instead just to present the information in a clear-enough form that 
people could re-write it.  Add on top of that the ability to force all PCDs of 
a specific token space GUID into the PCD database and you get around the need 
for mega-PCD structs. 

This strategy mitigated the downside of our choice, which was inability to 
change individual fields easily, since structs never got as large.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney, 
Michael D
Sent: Tuesday, June 14, 2016 5:22 PM
To: Tim Lewis <tim.le...@insyde.com>; Zhu, Yonghong <yonghong@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Subject: Re: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC files

Tim,

No problem.  Glad to see the feedback.

Would the multi-char '' or L'' string work for a Load Option string without a 
null-terminator.

I agree that GUID() operator help avoid ambiguity with registry format GUIDs 
and subtraction operations.  We do not support expressions in default value 
assignments today, which is why it did not look like GUID() was required.  Do 
we really need expression support?

For more complex structure initialization, I am reviewing the feedback from 
Andrew Fish on the Structured PCD RFC.  He has proposed some ideas to support C 
code syntax in a separate source file (similar to .aslc files) to initialize 
complex C structures.  Maybe that direction would be better than extending the 
value syntax in the DEC/INF/DSC/FDF files much more and would also remove the 
need for UINTx() operators in VOID* PCD value assignment.

Thanks,

Mike

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Tuesday, June 14, 2016 5:02 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Zhu, Yonghong 
> <yonghong@intel.com>; edk2-devel@lists.01.org
> Subject: RE: [RFC] Add more flexible PCD value formats in DEC/DSC 
> files
> 
> Mike --
> 
> Sorry to keep spamming on this but another useful extension (for load 
> options, for
> example) we have done via pre-processor is $ to represent the current 
> offset within the current PCD value. Then, using a placeholder macro 
> (like ^0, ^1), you can perform some calculations $ - ^0 to handle data 
> structures where offsets or sizes are required to be embedded. Doesn't work 
> cross-PCDs, but does in more complicated data structures.
> 
> Tim
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Tuesday, June 14, 2016 4:50 PM
> To: Tim Lewis <tim.le...@insyde.com>; Zhu, Yonghong 
> <yonghong@intel.com>; edk2- de...@lists.01.org; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Subject: RE: [RFC] Add more flexible PCD value formats in DEC/DSC 
> files
> 
> Tim,
> 
> Good suggestions.
> 
> I like L'' for single a multi-character UCS16 characters without a null 
> terminator.
> 
> I prefer "" and L"" to always have a null terminator.
> 
> The GUID() syntax makes sense support both registry format and struct style 
> GUIDs.
> The FDF spec also support GUID C names to define some GUID values.  
> Since GUID values are always 128-bits, it only makes sense to allow this 
> syntax for VOID* PCDs.
> 
> The proposal here covers setting values for all PCD data types.  Not just 
> VOID*.
> 
> I want to make sure the parsing is unambiguous and minimize the 
> addition of new keywords.  I think we can get by with only one new keyword of 
> GUID().
> Though even this one new keyword may not be required since all 3 GUID 
> styles can be distinguished from all other value formats.
> 
> Here is a revised proposal and example PCD values for various PCD data types:
> ==
> === I would like to propose more flexible value formats for PCDs 
> in DEC/INF/DSC/FDF files and --pcd command line option.
> 
> This would include the following:
> 
> * ASCII character values using single quotes(e.g. 'A').
> * ASCII multi-charac

Re: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC files

[Tim Lewis]

Mike --

Sorry to keep spamming on this but another useful extension (for load options, 
for example) we have done via pre-processor is $ to represent the current 
offset within the current PCD value. Then, using a placeholder macro (like ^0, 
^1), you can perform some calculations $ - ^0 to handle data structures where 
offsets or sizes are required to be embedded. Doesn't work cross-PCDs, but does 
in more complicated data structures.

Tim

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Tuesday, June 14, 2016 4:50 PM
To: Tim Lewis <tim.le...@insyde.com>; Zhu, Yonghong <yonghong@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Subject: RE: [RFC] Add more flexible PCD value formats in DEC/DSC files

Tim,

Good suggestions.  

I like L'' for single a multi-character UCS16 characters without a null 
terminator.

I prefer "" and L"" to always have a null terminator.

The GUID() syntax makes sense support both registry format and struct style 
GUIDs.
The FDF spec also support GUID C names to define some GUID values.  Since GUID 
values 
are always 128-bits, it only makes sense to allow this syntax for VOID* PCDs.

The proposal here covers setting values for all PCD data types.  Not just VOID*.

I want to make sure the parsing is unambiguous and minimize the addition of 
new keywords.  I think we can get by with only one new keyword of GUID().
Though even this one new keyword may not be required since all 3 GUID 
styles can be distinguished from all other value formats.

Here is a revised proposal and example PCD values for various PCD data types:
=
I would like to propose more flexible value formats for PCDs
in DEC/INF/DSC/FDF files and --pcd command line option.  

This would include the following:

* ASCII character values using single quotes(e.g. 'A').
* ASCII multi-character values using single quotes(e.g. 'ABCD').
* UCS16 character values using L and single quotes(e.g. L'A').
* UCS16 multi-Character values using L and single quotes(e.g. L 'ABCD').
* Able to use TRUE/FALSE for UINT8/16/32/64 values
* Able to use TRUE/FALSE in VOID* byte array
* Able to use decimal values in VOID* byte array
* Able to use ASCII single quote character values in VOID* byte arrays
* Able to use byte arrays, ASCII string, Unicode String, 
  ASCII multi-character strings, UCS16 multi-character strings for 
  UINT8/16/32/64 values as long as they fit in the target type.
* Able to assign GUID values to a VOID* PCD using a GUID() operator
  that supports Registry format GUIDs, C struct style GUIDs, and 
  GUID C names.

Some examples of this additional flexibility are:
  BOOLEAN TRUE
  BOOLEAN FALSE
  BOOLEAN 0
  BOOLEAN 1
  BOOLEAN {0}
  BOOLEAN {1}
  UINT8   TRUE
  UINT8   FALSE
  UINT8   0x12
  UINT8   12
  UINT8   'A'
  UINT8   {TRUE}
  UINT8   {0x12}  
  UINT8   {'A'}
  UINT16  TRUE
  UINT16  0x1234
  UINT16  1234
  UINT16  'AB'
  UINT16  "A"
  UINT16  L'A'
  UINT16  {0x34, TRUE}  
  UINT16  {27, FALSE}
  UINT16  {'A', 'B'}
  UINT32  FALSE
  UINT32  0x12345678
  UINT32  12345678
  UINT32  "ABC"
  UINT32  L"A"
  UINT32  'ABCD'
  UINT32  L'AB'
  UINT32  {0x12, 27, TRUE, 'A'}
  UINT64  FALSE
  UINT64  0x1234567812345678
  UINT64  1234567812345678
  UINT64  "ABCDEFG"
  UINT64  L"ABC"
  UINT64  'ABCDEFGH'
  UINT64  L'ABCD'
  UINT64  {0x12, 27, TRUE, FALSE, 'A', 'B', 'C', 'D'}
  VOID*   {0x1, 0x2, 0x3}
  VOID*   {10, 11, 12, 13, 14}
  VOID*   {'X', 'Y', 'Z'}
  VOID*   {TRUE, FALSE, FALSE, TRUE}
  VOID*   {0x41, 0x42, 67, 68, 'E', 'F', TRUE, FALSE}
  VOID*   GUID(11E13869-1896-4A07-8B21-D8B23DD2A2B4)
  VOID*   GUID({ 0x11e13869, 0x1896, 0x4a07, { 0x8b, 0x21, 0xd8, 0xb2, 0x3d, 
0xd2, 0xa2, 0xb4 } })
  VOID*   GUID(gEfiBlockIoProtocolGuid)

Mike 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim 
> Lewis
> Sent: Tuesday, June 14, 2016 4:14 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Zhu, Yonghong
> <yonghong@intel.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC files
> 
> Mike --
> 
> We have traditionally used a preprocessor to convert the following into byte 
> arrays:
> 
> UINT8(xx), UINT16(xx), UINT32(xx), UINT64(xx), BOOLEAN(TRUE|FALSE), 
> GUID(struct-style
> {} or registry style "xx-yyy..."), "" (ASCII string no-nullterminator), 
> L"" (UCS16
> string no null-terminator), '' (ASCII character), L'' (UCS16 character) and
> DevicePath()
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Kinney, Michael
> D
> Sent: Tuesday, June 14, 2016 3:58 PM
> To: Z

Re: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC files

[Tim Lewis]

Oh, and we always use the function form (with parentheses rather than just a 
prefix keyword). So it is UINT8(0x44). This can be extended to your form if it 
is really UINT8 const-uint8-expr since () will just function as parentheses.

Tim

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Tuesday, June 14, 2016 4:50 PM
To: Tim Lewis <tim.le...@insyde.com>; Zhu, Yonghong <yonghong@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Subject: RE: [RFC] Add more flexible PCD value formats in DEC/DSC files

Tim,

Good suggestions.  

I like L'' for single a multi-character UCS16 characters without a null 
terminator.

I prefer "" and L"" to always have a null terminator.

The GUID() syntax makes sense support both registry format and struct style 
GUIDs.
The FDF spec also support GUID C names to define some GUID values.  Since GUID 
values are always 128-bits, it only makes sense to allow this syntax for VOID* 
PCDs.

The proposal here covers setting values for all PCD data types.  Not just VOID*.

I want to make sure the parsing is unambiguous and minimize the addition of new 
keywords.  I think we can get by with only one new keyword of GUID().
Though even this one new keyword may not be required since all 3 GUID styles 
can be distinguished from all other value formats.

Here is a revised proposal and example PCD values for various PCD data types:
=
I would like to propose more flexible value formats for PCDs in DEC/INF/DSC/FDF 
files and --pcd command line option.  

This would include the following:

* ASCII character values using single quotes(e.g. 'A').
* ASCII multi-character values using single quotes(e.g. 'ABCD').
* UCS16 character values using L and single quotes(e.g. L'A').
* UCS16 multi-Character values using L and single quotes(e.g. L 'ABCD').
* Able to use TRUE/FALSE for UINT8/16/32/64 values
* Able to use TRUE/FALSE in VOID* byte array
* Able to use decimal values in VOID* byte array
* Able to use ASCII single quote character values in VOID* byte arrays
* Able to use byte arrays, ASCII string, Unicode String,
  ASCII multi-character strings, UCS16 multi-character strings for
  UINT8/16/32/64 values as long as they fit in the target type.
* Able to assign GUID values to a VOID* PCD using a GUID() operator
  that supports Registry format GUIDs, C struct style GUIDs, and
  GUID C names.

Some examples of this additional flexibility are:
  BOOLEAN TRUE
  BOOLEAN FALSE
  BOOLEAN 0
  BOOLEAN 1
  BOOLEAN {0}
  BOOLEAN {1}
  UINT8   TRUE
  UINT8   FALSE
  UINT8   0x12
  UINT8   12
  UINT8   'A'
  UINT8   {TRUE}
  UINT8   {0x12}  
  UINT8   {'A'}
  UINT16  TRUE
  UINT16  0x1234
  UINT16  1234
  UINT16  'AB'
  UINT16  "A"
  UINT16  L'A'
  UINT16  {0x34, TRUE}
  UINT16  {27, FALSE}
  UINT16  {'A', 'B'}
  UINT32  FALSE
  UINT32  0x12345678
  UINT32  12345678
  UINT32  "ABC"
  UINT32  L"A"
  UINT32  'ABCD'
  UINT32  L'AB'
  UINT32  {0x12, 27, TRUE, 'A'}
  UINT64  FALSE
  UINT64  0x1234567812345678
  UINT64  1234567812345678
  UINT64  "ABCDEFG"
  UINT64  L"ABC"
  UINT64  'ABCDEFGH'
  UINT64  L'ABCD'
  UINT64  {0x12, 27, TRUE, FALSE, 'A', 'B', 'C', 'D'}
  VOID*   {0x1, 0x2, 0x3}
  VOID*   {10, 11, 12, 13, 14}
  VOID*   {'X', 'Y', 'Z'}
  VOID*   {TRUE, FALSE, FALSE, TRUE}
  VOID*   {0x41, 0x42, 67, 68, 'E', 'F', TRUE, FALSE}
  VOID*   GUID(11E13869-1896-4A07-8B21-D8B23DD2A2B4)
  VOID*   GUID({ 0x11e13869, 0x1896, 0x4a07, { 0x8b, 0x21, 0xd8, 0xb2, 0x3d, 
0xd2, 0xa2, 0xb4 } })
  VOID*   GUID(gEfiBlockIoProtocolGuid)

Mike 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Tuesday, June 14, 2016 4:14 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Zhu, Yonghong 
> <yonghong@intel.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC] Add more flexible PCD value formats in 
> DEC/DSC files
> 
> Mike --
> 
> We have traditionally used a preprocessor to convert the following into byte 
> arrays:
> 
> UINT8(xx), UINT16(xx), UINT32(xx), UINT64(xx), BOOLEAN(TRUE|FALSE), 
> GUID(struct-style {} or registry style "xx-yyy..."), "" (ASCII 
> string no-nullterminator), L"" (UCS16 string no null-terminator), '' 
> (ASCII character), L'' (UCS16 character) and
> DevicePath()
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Kinney, Michael D
> Sent: Tuesday, June 14, 2016 3:58 PM
> To: Zhu, Yonghong <yonghong@intel.com>; edk2-devel@lists.01.org; 
> Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: Re: [edk2] [RFC] Add more flexible PCD value formats in 
> DEC/DSC fi

Re: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC files

[Tim Lewis]

Mike --

We specifically did not use the null-terminator because of one common use case: 
Load Options. Making our users use characters to handle the load option 
descriptions caused issues.

We use a single GUID() identifier for GUIDs. The problem with using registry 
GUIDs without quotes is that it is not distinguishable from subtraction 
expressions. 

Tim

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Tuesday, June 14, 2016 4:50 PM
To: Tim Lewis <tim.le...@insyde.com>; Zhu, Yonghong <yonghong@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Subject: RE: [RFC] Add more flexible PCD value formats in DEC/DSC files

Tim,

Good suggestions.  

I like L'' for single a multi-character UCS16 characters without a null 
terminator.

I prefer "" and L"" to always have a null terminator.

The GUID() syntax makes sense support both registry format and struct style 
GUIDs.
The FDF spec also support GUID C names to define some GUID values.  Since GUID 
values are always 128-bits, it only makes sense to allow this syntax for VOID* 
PCDs.

The proposal here covers setting values for all PCD data types.  Not just VOID*.

I want to make sure the parsing is unambiguous and minimize the addition of new 
keywords.  I think we can get by with only one new keyword of GUID().
Though even this one new keyword may not be required since all 3 GUID styles 
can be distinguished from all other value formats.

Here is a revised proposal and example PCD values for various PCD data types:
=
I would like to propose more flexible value formats for PCDs in DEC/INF/DSC/FDF 
files and --pcd command line option.  

This would include the following:

* ASCII character values using single quotes(e.g. 'A').
* ASCII multi-character values using single quotes(e.g. 'ABCD').
* UCS16 character values using L and single quotes(e.g. L'A').
* UCS16 multi-Character values using L and single quotes(e.g. L 'ABCD').
* Able to use TRUE/FALSE for UINT8/16/32/64 values
* Able to use TRUE/FALSE in VOID* byte array
* Able to use decimal values in VOID* byte array
* Able to use ASCII single quote character values in VOID* byte arrays
* Able to use byte arrays, ASCII string, Unicode String,
  ASCII multi-character strings, UCS16 multi-character strings for
  UINT8/16/32/64 values as long as they fit in the target type.
* Able to assign GUID values to a VOID* PCD using a GUID() operator
  that supports Registry format GUIDs, C struct style GUIDs, and
  GUID C names.

Some examples of this additional flexibility are:
  BOOLEAN TRUE
  BOOLEAN FALSE
  BOOLEAN 0
  BOOLEAN 1
  BOOLEAN {0}
  BOOLEAN {1}
  UINT8   TRUE
  UINT8   FALSE
  UINT8   0x12
  UINT8   12
  UINT8   'A'
  UINT8   {TRUE}
  UINT8   {0x12}  
  UINT8   {'A'}
  UINT16  TRUE
  UINT16  0x1234
  UINT16  1234
  UINT16  'AB'
  UINT16  "A"
  UINT16  L'A'
  UINT16  {0x34, TRUE}
  UINT16  {27, FALSE}
  UINT16  {'A', 'B'}
  UINT32  FALSE
  UINT32  0x12345678
  UINT32  12345678
  UINT32  "ABC"
  UINT32  L"A"
  UINT32  'ABCD'
  UINT32  L'AB'
  UINT32  {0x12, 27, TRUE, 'A'}
  UINT64  FALSE
  UINT64  0x1234567812345678
  UINT64  1234567812345678
  UINT64  "ABCDEFG"
  UINT64  L"ABC"
  UINT64  'ABCDEFGH'
  UINT64  L'ABCD'
  UINT64  {0x12, 27, TRUE, FALSE, 'A', 'B', 'C', 'D'}
  VOID*   {0x1, 0x2, 0x3}
  VOID*   {10, 11, 12, 13, 14}
  VOID*   {'X', 'Y', 'Z'}
  VOID*   {TRUE, FALSE, FALSE, TRUE}
  VOID*   {0x41, 0x42, 67, 68, 'E', 'F', TRUE, FALSE}
  VOID*   GUID(11E13869-1896-4A07-8B21-D8B23DD2A2B4)
  VOID*   GUID({ 0x11e13869, 0x1896, 0x4a07, { 0x8b, 0x21, 0xd8, 0xb2, 0x3d, 
0xd2, 0xa2, 0xb4 } })
  VOID*   GUID(gEfiBlockIoProtocolGuid)

Mike 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Tuesday, June 14, 2016 4:14 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Zhu, Yonghong 
> <yonghong@intel.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC] Add more flexible PCD value formats in 
> DEC/DSC files
> 
> Mike --
> 
> We have traditionally used a preprocessor to convert the following into byte 
> arrays:
> 
> UINT8(xx), UINT16(xx), UINT32(xx), UINT64(xx), BOOLEAN(TRUE|FALSE), 
> GUID(struct-style {} or registry style "xx-yyy..."), "" (ASCII 
> string no-nullterminator), L"" (UCS16 string no null-terminator), '' 
> (ASCII character), L'' (UCS16 character) and
> DevicePath()
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Kinney, Michael D
> Sent: Tuesday, June 14, 2016 3:58 PM
> To: Zhu, Yonghong <yonghong@intel.com>; edk2-devel@lists.01.org; 
> Kinney, Michael D <m

Re: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC files

[Tim Lewis]

Mike --

We have traditionally used a preprocessor to convert the following into byte 
arrays:

UINT8(xx), UINT16(xx), UINT32(xx), UINT64(xx), BOOLEAN(TRUE|FALSE), 
GUID(struct-style {} or registry style "xx-yyy..."), "" (ASCII string 
no-nullterminator), L"" (UCS16 string no null-terminator), '' (ASCII 
character), L'' (UCS16 character) and DevicePath()

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney, 
Michael D
Sent: Tuesday, June 14, 2016 3:58 PM
To: Zhu, Yonghong ; edk2-devel@lists.01.org; Kinney, 
Michael D 
Subject: Re: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC files

Zhu Yonghong,

This proposal also applies to the optional default values in source INF files 
and PCD value assignments in FDF files.  We should also extend the syntax for 
the --pcd command line option to the build command to support this extended 
syntax.  So the specs impacted by this proposal are DEC/INF/DSC/FDF/Build.

Can you please provide a pointer to the spec that says C format GUIDs are 
supported for setting the value of a VOID* PCD?  I see several places where it 
states that only {} byte arrays are allowed.

Thanks,

Mike

> -Original Message-
> From: Zhu, Yonghong
> Sent: Monday, June 13, 2016 11:27 PM
> To: Kinney, Michael D ; 
> edk2-devel@lists.01.org; Kinney, Michael D 
> 
> Cc: Zhu, Yonghong 
> Subject: RE: [RFC] Add more flexible PCD value formats in DEC/DSC 
> files
> 
> Hi Mike,
> 
> Sorry for the delay response. I have some comment:
> 1. Is this proposal only for DEC and DSC file ? Do we need cover the 
> Pcd value in the INF file and FDF file ?
> 2. From build spec, it require build tools support C format GUIDs as 
> Void * PCD value, current this feature is not implemented. So whether 
> this new proposal need to support the  C format GUIDs as Void * PCD value ?
> 
> Best Regards,
> Zhu Yonghong
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Kinney, Michael D
> Sent: Thursday, May 19, 2016 3:22 AM
> To: edk2-devel@lists.01.org; Kinney, Michael D 
> 
> Subject: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC 
> files
> 
> Hello,
> 
> Today, the DEC/DSC specifications limit the PCD value formats to the 
> following:
> 
>   BOOLEAN  TRUE or FALSE
>   UINT88-bit decimal or hexadecimal value
>   UINT16   16-bit decimal or hexadecimal value
>   UINT32   32-bit decimal or hexadecimal value
>   UINT64   64-bit decimal or hexadecimal value
>   VOID*ASCII string(e.g. "Hello")
>   VOID*Unicode string(e.g. L"Hello")
>   VOID*Array of hexadecimal byte values(e.g. {0x01, 0x02})
> 
> I would like to propose more flexible value formats for PCDs.
> In DEC and DSC files.  This would include the following:
> 
> * Character values using single quotes(e.g. 'A').
> * Multi-Character values using single quotes(e.g. 'ABCD').
> * Able to use TRUE/FALSE for UINT8/16/32/64 values
> * Able to use TRUE/FALSE in VOID* byte array
> * Able to use decimal values in VOID* byte array
> * Able to use single quote character values in VOID* byte arrays
> * Able to use ASCII string, Unicode String, Multi-Character
>   strings for UINT8/16/32/64 values as long as they fit in the
>   target type.
> 
> Some examples of this additional flexibility are:
> 
>   UINT8   TRUE
>   UINT8   FALSE
>   UINT8   0x12
>   UINT8   12
>   UINT8   'A'
>   UINT16   TRUE
>   UINT16  0x1234
>   UINT16  1234
>   UINT16  'AB'
>   UINT16  "A"
>   UINT32  0x12345678
>   UINT32  12345678
>   UINT32  "ABC"
>   UINT32  L"A"
>   UINT32  'ABCD'
>   UINT64  0x1234567812345678
>   UINT64  1234567812345678
>   UINT64  "ABCDEFG"
>   UINT64  L"ABC"
>   UINT64  'ABCDEFGH'
>   VOID*   {0x1, 0x2, 0x3}
>   VOID*   {10, 11, 12, 13, 14}
>   VOID*   {'X', 'Y', 'Z'}
>   VOID*   {TRUE, FALSE, FALSE, TRUE}
>   VOID*   {0x41, 0x42, 67, 68, 'E', 'F', TRUE, FALSE}
> 
> Here is a python function that can parse these formats and return an 
> python integer value that does not have any size limits.  Based on the 
> data type, the size can be checked to see the value return fits in the 
> target type.  All strings and byte arrays are reversed for little-endian byte 
> ordering.
> 
>   NOTE: Need to add explicit null-terminator for ASCII/Unicode
>   strings.  Multi-character constants are not null-terminated.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney 
> 
> def ParseValue (Value):
>   if type(Value) == type(0):
> return Value
>   if type(Value) <> type(''):
> raise ValueError
>   Value = Value.strip()
>   if Value.startswith('L"') and Value.endswith('"'):
> # Unicode String
> List = list(Value[2:-1])
> List.reverse()
> Value = 0
> for Char in List:
>   Value 

Re: [edk2] propose 3 new UserExtensions in the INF specification

[Tim Lewis]

Jaben --

For the record, I think that continuing to add meta-build information to the 
.inf files is counter-productive. As a company that has written tools that 
conform to the grammar, these extensions to an .ini style file format are 
becoming more and more arcane to parse and process. Some comments are 
important, others are not. Some apply to statements that come after, others to 
statements on the same line. Files that once contains only build information 
(.uni) now have meta-build information.

Why not just add an xml-formatted extension to [ExtraFiles] and put these 
meta-build rules there. Yes, I know that XML existed in the EDK2 past and was 
rejected, mostly tied to ANT. Moving the meta-build information to a separate 
files allows those who are working with build systems to focus on these and 
those on meta-tools to focus on the extensions. 

Glancing ahead to the publicly released "Intel" User Extensions found in 
Firmware Engine, I would say that it appears that even Intel is finding the.ini 
style extensions somewhat cumbersome (for ACPI and I2C, for example), as are 
the PCD documentation extensions for .uni.

For what it's worth, XML or JSON would handle these better.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Friday, June 10, 2016 4:04 PM
To: edk2-devel@lists.01.org
Cc: Carsey, Jaben 
Subject: [edk2] propose 3 new UserExtensions in the INF specification

All,

I would like to propose 3 new UserExtensions in the INF specification.  These 
would be optional sections that can be used to convey additional information 
about the module.  This additional meta data is not expected to be used by the 
build. This is used by additional tools to help verify DSC functionality and 
completeness.  Modules that will not function based on the contents of the 
flash image could for example be easily identified.

Please respond with comments/objections/suggestions by next Friday June 17th.

1) BY_START / TO_START interaction

Currently the Protocols that are produced or consumed by the driver are marked 
as such in the INF file [Protocols] section, but there is no information on the 
interactions between these protocols.  This extension would allow the conveying 
of complex interactions to fully describe the meaning behind the TO_START and 
BY_START tags in the [Protocols] section.

The syntax for this section is proposed as:
[UserExtensions.TianoCore."ByStartExpressions"]
 "|" 

Where Expression uses Protocols marked TO_START, PCDs from the [Pcd] section of 
this INF file, and standard operators per the EDKII Expression Syntax document. 
 Each entry evaluates to TRUE or FALSE and if any expression evaluates to TRUE, 
then that Protocol will be produced in the DriverBinding Start().

Here is a valid example for a file system driver.  The additional information 
that is conveyed here is that BlockIo and DiskIo are both required, but only 
one of UnicodeCollation and UnicodeCollation2 are required.  Otherwise, the 
meta data requires both UC and UC2 for DriverBinding Start() to be successful.

[Protocols]
  gEfiDiskIoProtocolGuid## TO_START
  gEfiBlockIoProtocolGuid   ## TO_START
  gEfiSimpleFileSystemProtocolGuid  ## BY_START
  gEfiUnicodeCollationProtocolGuid  ## TO_START
  gEfiUnicodeCollation2ProtocolGuid ## TO_START

[UserExtensions.TianoCore."ByStartExpressions"]
  gEfiSimpleFileSystemProtocolGuid  | gEfiBlockIoProtocolGuid AND
  gEfiDiskIoProtocolGuid AND
  (gEfiUnicodeCollationProtocolGuid OR
   gEfiUnicodeCollation2ProtocolGuid)

2) SOMETIMES_CONSUMES additional information.

Currently Protocols/PPI/GUIDs are marked as UNDEFINED or SOMETIMES_CONSUMES 
with no way to know whether these will be consumed (thus required).  This 
section would have information to define which would be consumed based on other 
data.

The syntax for this section is proposed as:
[UserExtensions.TianoCore."ConsumesExpressions"]


Where Expression uses items marked UNDEFINED or SOMETIMES_CONSUMES, PCDs from 
the [Pcd] section of this INF file, and standard operators per the EDKII 
Expression Syntax document.  Each entry is evaluated individually as a Boolean 
and if any one evaluate to FALSE, then the module will not function due to 
missing dependencies.

Here is an example.  The additional information that is conveyed here is that 
one of Performance and PerformanceEx is required, but not both.

[Guids]
  gPerformanceProtocolGuid## SOMETIMES_CONSUMES
  gPerformanceExProtocolGuid  ## SOMETIMES_CONSUMES

[UserExtensions.TianoCore."ConsumesExpressions"]
  gPerformanceProtocolGuid OR gPerformanceExProtocolGuid

3) SOMETIMES_PRODUCES additional information.

Currently Protocols/PPI/GUIDs are marked as SOMETIMES_PRODUCES with no way to 
know when these will be produced.  

Re: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.

[Tim Lewis]

Yes.

Tim

-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com] 
Sent: Monday, May 09, 2016 6:42 PM
To: Kinney, Michael D <michael.d.kin...@intel.com>; Tim Lewis 
<tim.le...@insyde.com>; Mudusuru, Giri P <giri.p.mudus...@intel.com>; 
edk2-devel@lists.01.org
Cc: Mudusuru, Giri P <giri.p.mudus...@intel.com>; Zimmer, Vincent 
<vincent.zim...@intel.com>; Rangarajan, Ravi P <ravi.p.rangara...@intel.com>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.

Good discussion on PACKAGES_PATH usage.

For this specific case (FSP2 without FSP1.1 support), do we need change to 
IntelFsp2Pkg?

Thank you
Yao Jiewen

> -Original Message-
> From: Kinney, Michael D
> Sent: Friday, May 6, 2016 10:07 AM
> To: Tim Lewis <tim.le...@insyde.com>; Mudusuru, Giri P
> <giri.p.mudus...@intel.com>; Yao, Jiewen <jiewen@intel.com>;
> edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: Mudusuru, Giri P <giri.p.mudus...@intel.com>; Zimmer, Vincent
> <vincent.zim...@intel.com>; Rangarajan, Ravi P
> <ravi.p.rangara...@intel.com>
> Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split
> FspInitPei to FspmWrapperPeim and FspsWrapperPeim.
> 
> Tim,
> 
> I agree multiple repos in a WORKSPACE can potentially be confusing.
> Especially if the
> same package dir exists in more than of the repos.  To alleviate this issue, a
> repo can
> be pruned and the .gitignore feature can be used for git to ignore the
> packages that
> have been pruned.
> 
> The reason I am asking these questions is not related to FSP.
> 
> There have been prior discussions on edk2-devel to organize the packages in
> edk2
> into subdirectories, and I am working on a proposal for that.  However,
> moving
> packages into subdirectories would require the use of the PACKAGES_PATH
> feature.
> 
> Is PACKAGES_PATH something you could add support for in your tools?
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > Sent: Thursday, May 5, 2016 6:53 PM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>; Mudusuru, Giri P
> > <giri.p.mudus...@intel.com>; Yao, Jiewen <jiewen@intel.com>; edk2-
> > de...@lists.01.org
> > Cc: Mudusuru, Giri P <giri.p.mudus...@intel.com>; Zimmer, Vincent
> > <vincent.zim...@intel.com>; Rangarajan, Ravi P
> <ravi.p.rangara...@intel.com>
> > Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split
> FspInitPei to
> > FspmWrapperPeim and FspsWrapperPeim.
> >
> > Mike --
> >
> > At this time, no. Our internal tools do not recognize it, and would fail
> during tree
> > analysis.
> >
> > Likewise, our policy does not allow it because we find our customers are
> confused by
> > multiple roots. It makes it hard for the engineers looking at a downstream
> file to
> > predict where the final file resides. That leads to bad bug reports, etc.
> >
> > Tim
> >
> > -Original Message-
> > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > Sent: Thursday, May 05, 2016 6:14 PM
> > To: Tim Lewis <tim.le...@insyde.com>; Mudusuru, Giri P
> <giri.p.mudus...@intel.com>;
> > Yao, Jiewen <jiewen@intel.com>; edk2-devel@lists.01.org; Kinney,
> Michael D
> > <michael.d.kin...@intel.com>
> > Cc: Mudusuru, Giri P <giri.p.mudus...@intel.com>; Zimmer, Vincent
> > <vincent.zim...@intel.com>; Rangarajan, Ravi P
> <ravi.p.rangara...@intel.com>
> > Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split
> FspInitPei to
> > FspmWrapperPeim and FspsWrapperPeim.
> >
> > Hi Tim,
> >
> > I wanted to follow up on the general concern on the use of the
> PACKAGES_PATH feature.
> >
> > The EDK II BaseTools still use a single WORKSPACE and can use
> PACKAGES_PATH for
> > additional search paths for packages.  PACKAGES_PATH can point to
> directories
> > Below WORKSPACE or outside WORKSPACE, so it is very flexible.
> >
> >
> https://github.com/tianocore/tianocore.github.io/wiki/Multiple_Workspace
> >
> > For your specific use case, could you use PACKAGES_PATH if all the paths
> listed
> > in PACKAGES_PATH are below WORKSPACE?
> >
> > For example, if you have the following dir structure:
> >
> > tianocore/
> >     edk2/
> > Udk2015/
> >
> > You can set WORKSPACE to tianocore/ and PACKAGES_PATH to
> &g

Re: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.

[Tim Lewis]

Mike --

At this time, no. Our internal tools do not recognize it, and would fail during 
tree analysis.

Likewise, our policy does not allow it because we find our customers are 
confused by multiple roots. It makes it hard for the engineers looking at a 
downstream file to predict where the final file resides. That leads to bad bug 
reports, etc.

Tim

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Thursday, May 05, 2016 6:14 PM
To: Tim Lewis <tim.le...@insyde.com>; Mudusuru, Giri P 
<giri.p.mudus...@intel.com>; Yao, Jiewen <jiewen@intel.com>; 
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Mudusuru, Giri P <giri.p.mudus...@intel.com>; Zimmer, Vincent 
<vincent.zim...@intel.com>; Rangarajan, Ravi P <ravi.p.rangara...@intel.com>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.

Hi Tim,

I wanted to follow up on the general concern on the use of the PACKAGES_PATH 
feature.

The EDK II BaseTools still use a single WORKSPACE and can use PACKAGES_PATH for
additional search paths for packages.  PACKAGES_PATH can point to directories
Below WORKSPACE or outside WORKSPACE, so it is very flexible.

https://github.com/tianocore/tianocore.github.io/wiki/Multiple_Workspace

For your specific use case, could you use PACKAGES_PATH if all the paths listed
in PACKAGES_PATH are below WORKSPACE?

For example, if you have the following dir structure:

tianocore/
edk2/
Udk2015/

You can set WORKSPACE to tianocore/ and PACKAGES_PATH to 
tianocore/edk2;tianocore/Udk2015.

This means an additional directory level is added, so all the packages are not 
in the
root of WORKSPACE.  This is how we can support pulling content from multiple 
git 
repos/tags/branches for a single WSORKSPACE build environment without having to 
update
the [Packages] section in every INF.

Thanks,

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim 
> Lewis
> Sent: Thursday, May 5, 2016 12:09 PM
> To: Mudusuru, Giri P <giri.p.mudus...@intel.com>; Yao, Jiewen 
> <jiewen@intel.com>;
> edk2-devel@lists.01.org
> Cc: Mudusuru, Giri P <giri.p.mudus...@intel.com>; Zimmer, Vincent
> <vincent.zim...@intel.com>; Rangarajan, Ravi P <ravi.p.rangara...@intel.com>
> Subject: Re: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split 
> FspInitPei to
> FspmWrapperPeim and FspsWrapperPeim.
> 
> That works well, thank you
> 
> Tim
> 
> Sent from my Windows 10 phone
> 
> From: Mudusuru, Giri P<mailto:giri.p.mudus...@intel.com>
> Sent: Thursday, May 5, 2016 12:07 PM
> To: Tim Lewis<mailto:tim.le...@insyde.com>; Yao, 
> Jiewen<mailto:jiewen@intel.com>;
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Rangarajan, Ravi P<mailto:ravi.p.rangara...@intel.com>; Yarlagadda, Satya
> P<mailto:satya.p.yarlaga...@intel.com>; Zimmer,
> Vincent<mailto:vincent.zim...@intel.com>; Mudusuru, Giri
> P<mailto:giri.p.mudus...@intel.com>
> Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split 
> FspInitPei to
> FspmWrapperPeim and FspsWrapperPeim.
> 
> Hi Tim,
> Here is summary of the plan and next steps after discussing internally with 
> Vincent and
> others...
> 
> 
> 1)  IntelFspPkg & IntelFspWrapperPkg will continue to support FSP v1.x 
> support.
> These packages are in maintenance mode i.e., only critical bug fix or changes
> 
> 2)  Create new packages IntelFsp2Pkg and IntelFsp2WrapperPkg to support 
> FSP v2.0
> support
> 
> Please let me know if this meets your need.
> 
> Thanks,
> -Giri
> 
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, May 4, 2016 6:40 AM
> To: Mudusuru, Giri P <giri.p.mudus...@intel.com>; Yao, Jiewen 
> <jiewen@intel.com>;
> edk2-devel@lists.01.org
> Cc: Rangarajan, Ravi P <ravi.p.rangara...@intel.com>; Yarlagadda, Satya P
> <satya.p.yarlaga...@intel.com>; Zimmer, Vincent <vincent.zim...@intel.com>; 
> Mudusuru,
> Giri P <giri.p.mudus...@intel.com>
> Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split 
> FspInitPei to
> FspmWrapperPeim and FspsWrapperPeim.
> 
> Thank you.
> 
> Tim
> 
> Sent from my Windows 10 phone
> 
> From: Mudusuru, Giri P<mailto:giri.p.mudus...@intel.com>
> Sent: Tuesday, May 3, 2016 11:06 PM
> To: Tim Lewis<mailto:tim.le...@insyde.com>; Yao, 
> Jiewen<mailto:jiewen@intel.com>;
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Rangarajan, Ravi P<mailto:ravi.p.rangara...@intel.com>; 

Re: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.

[Tim Lewis]

That works well, thank you

Tim

Sent from my Windows 10 phone

From: Mudusuru, Giri P<mailto:giri.p.mudus...@intel.com>
Sent: Thursday, May 5, 2016 12:07 PM
To: Tim Lewis<mailto:tim.le...@insyde.com>; Yao, 
Jiewen<mailto:jiewen@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Rangarajan, Ravi P<mailto:ravi.p.rangara...@intel.com>; Yarlagadda, Satya 
P<mailto:satya.p.yarlaga...@intel.com>; Zimmer, 
Vincent<mailto:vincent.zim...@intel.com>; Mudusuru, Giri 
P<mailto:giri.p.mudus...@intel.com>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.

Hi Tim,
Here is summary of the plan and next steps after discussing internally with 
Vincent and others…


1)  IntelFspPkg & IntelFspWrapperPkg will continue to support FSP v1.x 
support. These packages are in maintenance mode i.e., only critical bug fix or 
changes

2)  Create new packages IntelFsp2Pkg and IntelFsp2WrapperPkg to support FSP 
v2.0 support

Please let me know if this meets your need.

Thanks,
-Giri

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, May 4, 2016 6:40 AM
To: Mudusuru, Giri P <giri.p.mudus...@intel.com>; Yao, Jiewen 
<jiewen@intel.com>; edk2-devel@lists.01.org
Cc: Rangarajan, Ravi P <ravi.p.rangara...@intel.com>; Yarlagadda, Satya P 
<satya.p.yarlaga...@intel.com>; Zimmer, Vincent <vincent.zim...@intel.com>; 
Mudusuru, Giri P <giri.p.mudus...@intel.com>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.

Thank you.

Tim

Sent from my Windows 10 phone

From: Mudusuru, Giri P<mailto:giri.p.mudus...@intel.com>
Sent: Tuesday, May 3, 2016 11:06 PM
To: Tim Lewis<mailto:tim.le...@insyde.com>; Yao, 
Jiewen<mailto:jiewen@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Rangarajan, Ravi P<mailto:ravi.p.rangara...@intel.com>; Yarlagadda, Satya 
P<mailto:satya.p.yarlaga...@intel.com>; Zimmer, 
Vincent<mailto:vincent.zim...@intel.com>; Mudusuru, Giri 
P<mailto:giri.p.mudus...@intel.com>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.

Thanks for info on the policy and usage. Let me follow up internally and get 
back to you.

Thanks,
-Giri
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, May 3, 2016 4:24 PM
To: Mudusuru, Giri P 
<giri.p.mudus...@intel.com<mailto:giri.p.mudus...@intel.com>>; Yao, Jiewen 
<jiewen@intel.com<mailto:jiewen@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Rangarajan, Ravi P 
<ravi.p.rangara...@intel.com<mailto:ravi.p.rangara...@intel.com>>; Yarlagadda, 
Satya P <satya.p.yarlaga...@intel.com<mailto:satya.p.yarlaga...@intel.com>>; 
Zimmer, Vincent <vincent.zim...@intel.com<mailto:vincent.zim...@intel.com>>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.


1.  Because we, per our custom tools and per our company policy, require 
that all source code exist underneath $(WORKSPACE).  As previously discussed on 
this list, we think multiple workspaces makes our projects harder to maintain 
and harder to scan. Multiple workspaces was meant to be an OPTIONAL feature 
and, while some may use it, making it a requirement that all codebases follow 
this path to support what is today already supported seems a bit steep.

2.  There is NO PRODUCTION silicon that uses FSP 2.0 at this time that I am 
aware of. That means Intel is upgrading the Wrapper package to support silicon 
that is not yet shipping and removing support for the (by my count) 5 publicly 
announced chipsets, and probably a few others that are in alpha or beta.

3.  Many of these chipsets have a long life, which means new projects start 
on them well after initial product launch. Because of features and security 
concerns, we continually upgrade our chipsets to use newer kernel code. This 
puts an extra variable.

Regards,

Tim Lewis
CTO, Insyde Software
www.insyde.com<http://www.insyde.com>

From: Mudusuru, Giri P [mailto:giri.p.mudus...@intel.com]
Sent: Tuesday, May 03, 2016 4:07 PM
To: Tim Lewis <tim.le...@insyde.com<mailto:tim.le...@insyde.com>>; Yao, Jiewen 
<jiewen@intel.com<mailto:jiewen@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Rangarajan, Ravi P 
<ravi.p.rangara...@intel.com<mailto:ravi.p.rangara...@intel.com>>; Yarlagadda, 
Satya P <satya.p.yarlaga...@intel.com<mailto:satya.p.yarlaga...@intel.com>>; 
Zimmer, Vincent <vincent.zim...@intel.com<mailto:vincent.zim...@intel.com>>; 
Mudusuru, Giri P <giri.p.mudus...@intel.com<mail

Re: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.

[Tim Lewis]

Thank you.

Tim

Sent from my Windows 10 phone

From: Mudusuru, Giri P<mailto:giri.p.mudus...@intel.com>
Sent: Tuesday, May 3, 2016 11:06 PM
To: Tim Lewis<mailto:tim.le...@insyde.com>; Yao, 
Jiewen<mailto:jiewen@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Rangarajan, Ravi P<mailto:ravi.p.rangara...@intel.com>; Yarlagadda, Satya 
P<mailto:satya.p.yarlaga...@intel.com>; Zimmer, 
Vincent<mailto:vincent.zim...@intel.com>; Mudusuru, Giri 
P<mailto:giri.p.mudus...@intel.com>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.

Thanks for info on the policy and usage. Let me follow up internally and get 
back to you.

Thanks,
-Giri
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, May 3, 2016 4:24 PM
To: Mudusuru, Giri P <giri.p.mudus...@intel.com>; Yao, Jiewen 
<jiewen@intel.com>; edk2-devel@lists.01.org
Cc: Rangarajan, Ravi P <ravi.p.rangara...@intel.com>; Yarlagadda, Satya P 
<satya.p.yarlaga...@intel.com>; Zimmer, Vincent <vincent.zim...@intel.com>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.


1.  Because we, per our custom tools and per our company policy, require 
that all source code exist underneath $(WORKSPACE).  As previously discussed on 
this list, we think multiple workspaces makes our projects harder to maintain 
and harder to scan. Multiple workspaces was meant to be an OPTIONAL feature 
and, while some may use it, making it a requirement that all codebases follow 
this path to support what is today already supported seems a bit steep.

2.  There is NO PRODUCTION silicon that uses FSP 2.0 at this time that I am 
aware of. That means Intel is upgrading the Wrapper package to support silicon 
that is not yet shipping and removing support for the (by my count) 5 publicly 
announced chipsets, and probably a few others that are in alpha or beta.

3.  Many of these chipsets have a long life, which means new projects start 
on them well after initial product launch. Because of features and security 
concerns, we continually upgrade our chipsets to use newer kernel code. This 
puts an extra variable.

Regards,

Tim Lewis
CTO, Insyde Software
www.insyde.com<http://www.insyde.com>

From: Mudusuru, Giri P [mailto:giri.p.mudus...@intel.com]
Sent: Tuesday, May 03, 2016 4:07 PM
To: Tim Lewis <tim.le...@insyde.com<mailto:tim.le...@insyde.com>>; Yao, Jiewen 
<jiewen@intel.com<mailto:jiewen@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Rangarajan, Ravi P 
<ravi.p.rangara...@intel.com<mailto:ravi.p.rangara...@intel.com>>; Yarlagadda, 
Satya P <satya.p.yarlaga...@intel.com<mailto:satya.p.yarlaga...@intel.com>>; 
Zimmer, Vincent <vincent.zim...@intel.com<mailto:vincent.zim...@intel.com>>; 
Mudusuru, Giri P <giri.p.mudus...@intel.com<mailto:giri.p.mudus...@intel.com>>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.

Hi Tim,
Yes we considered creating a separate package name along with moving the 
package under Deprecated folder and just leave it in the UDK2015 branch.

There are pro’s and con’s for all options.

Can you please help me understand on why multi-workspace is not an option?

Thanks,
-Giri

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, May 03, 2016 8:47 AM
To: Mudusuru, Giri P 
<giri.p.mudus...@intel.com<mailto:giri.p.mudus...@intel.com>>; Yao, Jiewen 
<jiewen@intel.com<mailto:jiewen@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Rangarajan, Ravi P 
<ravi.p.rangara...@intel.com<mailto:ravi.p.rangara...@intel.com>>; Yarlagadda, 
Satya P <satya.p.yarlaga...@intel.com<mailto:satya.p.yarlaga...@intel.com>>; 
Zimmer, Vincent <vincent.zim...@intel.com<mailto:vincent.zim...@intel.com>>; 
Mudusuru, Giri P <giri.p.mudus...@intel.com<mailto:giri.p.mudus...@intel.com>>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.


Giri ,

I suggest you create a new package name, rather than use the same one with 
different semantics.



Multiple workspaces is not ah option for us.



Tim



Sent from my Windows 10 phone



From: Mudusuru, Giri P<mailto:giri.p.mudus...@intel.com>
Sent: Tuesday, May 3, 2016 8:07 AM
To: Tim Lewis<mailto:tim.le...@insyde.com>; Yao, 
Jiewen<mailto:jiewen@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Rangarajan, Ravi P<mailto:ravi.p.rangara...@intel.com>; Yarlagadda, Satya 
P<mailto:satya.p.yarlaga...@intel.com>; Zimmer, 
Vincent<mailto:vincent.zim...@intel.com>; Mudusur

Re: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.

[Tim Lewis]

1.   Because we, per our custom tools and per our company policy, require 
that all source code exist underneath $(WORKSPACE).  As previously discussed on 
this list, we think multiple workspaces makes our projects harder to maintain 
and harder to scan. Multiple workspaces was meant to be an OPTIONAL feature 
and, while some may use it, making it a requirement that all codebases follow 
this path to support what is today already supported seems a bit steep.

2.   There is NO PRODUCTION silicon that uses FSP 2.0 at this time that I 
am aware of. That means Intel is upgrading the Wrapper package to support 
silicon that is not yet shipping and removing support for the (by my count) 5 
publicly announced chipsets, and probably a few others that are in alpha or 
beta.

3.   Many of these chipsets have a long life, which means new projects 
start on them well after initial product launch. Because of features and 
security concerns, we continually upgrade our chipsets to use newer kernel 
code. This puts an extra variable.

Regards,

Tim Lewis
CTO, Insyde Software
www.insyde.com

From: Mudusuru, Giri P [mailto:giri.p.mudus...@intel.com]
Sent: Tuesday, May 03, 2016 4:07 PM
To: Tim Lewis <tim.le...@insyde.com>; Yao, Jiewen <jiewen@intel.com>; 
edk2-devel@lists.01.org
Cc: Rangarajan, Ravi P <ravi.p.rangara...@intel.com>; Yarlagadda, Satya P 
<satya.p.yarlaga...@intel.com>; Zimmer, Vincent <vincent.zim...@intel.com>; 
Mudusuru, Giri P <giri.p.mudus...@intel.com>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.

Hi Tim,
Yes we considered creating a separate package name along with moving the 
package under Deprecated folder and just leave it in the UDK2015 branch.

There are pro's and con's for all options.

Can you please help me understand on why multi-workspace is not an option?

Thanks,
-Giri

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, May 03, 2016 8:47 AM
To: Mudusuru, Giri P 
<giri.p.mudus...@intel.com<mailto:giri.p.mudus...@intel.com>>; Yao, Jiewen 
<jiewen@intel.com<mailto:jiewen@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Rangarajan, Ravi P 
<ravi.p.rangara...@intel.com<mailto:ravi.p.rangara...@intel.com>>; Yarlagadda, 
Satya P <satya.p.yarlaga...@intel.com<mailto:satya.p.yarlaga...@intel.com>>; 
Zimmer, Vincent <vincent.zim...@intel.com<mailto:vincent.zim...@intel.com>>; 
Mudusuru, Giri P <giri.p.mudus...@intel.com<mailto:giri.p.mudus...@intel.com>>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.


Giri ,

I suggest you create a new package name, rather than use the same one with 
different semantics.



Multiple workspaces is not ah option for us.



Tim



Sent from my Windows 10 phone



From: Mudusuru, Giri P<mailto:giri.p.mudus...@intel.com>
Sent: Tuesday, May 3, 2016 8:07 AM
To: Tim Lewis<mailto:tim.le...@insyde.com>; Yao, 
Jiewen<mailto:jiewen@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Rangarajan, Ravi P<mailto:ravi.p.rangara...@intel.com>; Yarlagadda, Satya 
P<mailto:satya.p.yarlaga...@intel.com>; Zimmer, 
Vincent<mailto:vincent.zim...@intel.com>; Mudusuru, Giri 
P<mailto:giri.p.mudus...@intel.com>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.


Hi Tim,
The main reason to deprecate the v1.x support was to reduce the complexity and 
focus on v2.0 going forward. At the same time as Jiewen mentioned below our 
plan is to continue maintaining v1.1 in the UDK2015 branch for the existing 
chipsets.

Understand your usage with single tree. For this usage, suggest to use the 
multi-workspace capability so you can have both in a single tree.

Thanks,
-Giri

-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, May 3, 2016 4:48 AM
To: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Mudusuru, Giri P 
<giri.p.mudus...@intel.com<mailto:giri.p.mudus...@intel.com>>; Rangarajan, Ravi 
P <ravi.p.rangara...@intel.com<mailto:ravi.p.rangara...@intel.com>>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.

Is this really a good idea, dropping 1.1 support? We don't maintain two 
separate trees for our products, just 1. There are several chipsets which have 
long life that will need additional features, but are only 1.1

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiewen 
Yao
Sent: Monday, May 02, 2016 9:51 PM
To: edk2-devel@lists.01.org<mailto:edk2-devel@list

Re: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.

[Tim Lewis]

Giri ,

I suggest you create a new package name, rather than use the same one with 
different semantics.



Multiple workspaces is not ah option for us.



Tim



Sent from my Windows 10 phone



From: Mudusuru, Giri P<mailto:giri.p.mudus...@intel.com>
Sent: Tuesday, May 3, 2016 8:07 AM
To: Tim Lewis<mailto:tim.le...@insyde.com>; Yao, 
Jiewen<mailto:jiewen@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Rangarajan, Ravi P<mailto:ravi.p.rangara...@intel.com>; Yarlagadda, Satya 
P<mailto:satya.p.yarlaga...@intel.com>; Zimmer, 
Vincent<mailto:vincent.zim...@intel.com>; Mudusuru, Giri 
P<mailto:giri.p.mudus...@intel.com>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.



Hi Tim,
The main reason to deprecate the v1.x support was to reduce the complexity and 
focus on v2.0 going forward. At the same time as Jiewen mentioned below our 
plan is to continue maintaining v1.1 in the UDK2015 branch for the existing 
chipsets.

Understand your usage with single tree. For this usage, suggest to use the 
multi-workspace capability so you can have both in a single tree.

Thanks,
-Giri

-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, May 3, 2016 4:48 AM
To: Yao, Jiewen <jiewen@intel.com>; edk2-devel@lists.01.org
Cc: Mudusuru, Giri P <giri.p.mudus...@intel.com>; Rangarajan, Ravi P 
<ravi.p.rangara...@intel.com>
Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei 
to FspmWrapperPeim and FspsWrapperPeim.

Is this really a good idea, dropping 1.1 support? We don't maintain two 
separate trees for our products, just 1. There are several chipsets which have 
long life that will need additional features, but are only 1.1

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiewen 
Yao
Sent: Monday, May 02, 2016 9:51 PM
To: edk2-devel@lists.01.org
Cc: Giri P Mudusuru <giri.p.mudus...@intel.com>; Ravi P Rangarajan 
<ravi.p.rangara...@intel.com>
Subject: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei to 
FspmWrapperPeim and FspsWrapperPeim.

Update FSP to follow:
https://firmware.intel.com/sites/default/files/FSP_EAS_v2.0_Draft%20External.pdf

Align to FSP2.0.
Remove 1.1 support from FspInit.
Split it into FspmWrapperPeim and FspsWrapperPeim, so they can build in
different FV.

The FSP1.1 compatibility is NOT maintained.

The new Intel platform will follow FSP2.0.
The old platform can either use an old EDK branch,
or move FSP1.1 support to platform directory.

Cc: Giri P Mudusuru <giri.p.mudus...@intel.com>
Cc: Maurice Ma <maurice...@intel.com>
Cc: Ravi P Rangarajan <ravi.p.rangara...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudus...@intel.com>
Reviewed-by: Maurice Ma <maurice...@intel.com>
Reviewed-by: Ravi P Rangarajan <ravi.p.rangara...@intel.com>
---
 IntelFspWrapperPkg/FspInitPei/FindPeiCore.c| 199 
 IntelFspWrapperPkg/FspInitPei/FspInitPei.c |  66 
 IntelFspWrapperPkg/FspInitPei/FspInitPei.h |  64 
 IntelFspWrapperPkg/FspInitPei/FspInitPei.inf   |  90 --
 IntelFspWrapperPkg/FspInitPei/FspInitPeiV1.c   | 182 ---
 IntelFspWrapperPkg/FspInitPei/FspInitPeiV2.c   | 338 

 IntelFspWrapperPkg/FspInitPei/FspNotifyS3.c|  80 -
 IntelFspWrapperPkg/FspInitPei/SecMain.c| 310 --
 IntelFspWrapperPkg/FspInitPei/SecMain.h| 116 ---
 IntelFspWrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c   | 161 ++
 IntelFspWrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf |  77 +
 IntelFspWrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c   | 313 ++
 IntelFspWrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf |  79 +
 13 files changed, 630 insertions(+), 1445 deletions(-)

diff --git a/IntelFspWrapperPkg/FspInitPei/FindPeiCore.c 
b/IntelFspWrapperPkg/FspInitPei/FindPeiCore.c
deleted file mode 100644
index ce003d0..000
--- a/IntelFspWrapperPkg/FspInitPei/FindPeiCore.c
+++ /dev/null
@@ -1,199 +0,0 @@
-/** @file
-  Locate the entry point for the PEI Core
-
-  Copyright (c) 2014, Intel Corporation. All rights reserved.
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php.
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include 
-#include 
-#include 
-
-#include 

Re: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.

[Tim Lewis]

Is this really a good idea, dropping 1.1 support? We don't maintain two 
separate trees for our products, just 1. There are several chipsets which have 
long life that will need additional features, but are only 1.1

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiewen 
Yao
Sent: Monday, May 02, 2016 9:51 PM
To: edk2-devel@lists.01.org
Cc: Giri P Mudusuru ; Ravi P Rangarajan 

Subject: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei to 
FspmWrapperPeim and FspsWrapperPeim.

Update FSP to follow:
https://firmware.intel.com/sites/default/files/FSP_EAS_v2.0_Draft%20External.pdf

Align to FSP2.0.
Remove 1.1 support from FspInit.
Split it into FspmWrapperPeim and FspsWrapperPeim, so they can build in
different FV.

The FSP1.1 compatibility is NOT maintained.

The new Intel platform will follow FSP2.0.
The old platform can either use an old EDK branch,
or move FSP1.1 support to platform directory.

Cc: Giri P Mudusuru 
Cc: Maurice Ma 
Cc: Ravi P Rangarajan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Reviewed-by: Giri P Mudusuru 
Reviewed-by: Maurice Ma 
Reviewed-by: Ravi P Rangarajan 
---
 IntelFspWrapperPkg/FspInitPei/FindPeiCore.c| 199 
 IntelFspWrapperPkg/FspInitPei/FspInitPei.c |  66 
 IntelFspWrapperPkg/FspInitPei/FspInitPei.h |  64 
 IntelFspWrapperPkg/FspInitPei/FspInitPei.inf   |  90 --
 IntelFspWrapperPkg/FspInitPei/FspInitPeiV1.c   | 182 ---
 IntelFspWrapperPkg/FspInitPei/FspInitPeiV2.c   | 338 

 IntelFspWrapperPkg/FspInitPei/FspNotifyS3.c|  80 -
 IntelFspWrapperPkg/FspInitPei/SecMain.c| 310 --
 IntelFspWrapperPkg/FspInitPei/SecMain.h| 116 ---
 IntelFspWrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c   | 161 ++
 IntelFspWrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf |  77 +
 IntelFspWrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c   | 313 ++
 IntelFspWrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf |  79 +
 13 files changed, 630 insertions(+), 1445 deletions(-)

diff --git a/IntelFspWrapperPkg/FspInitPei/FindPeiCore.c 
b/IntelFspWrapperPkg/FspInitPei/FindPeiCore.c
deleted file mode 100644
index ce003d0..000
--- a/IntelFspWrapperPkg/FspInitPei/FindPeiCore.c
+++ /dev/null
@@ -1,199 +0,0 @@
-/** @file
-  Locate the entry point for the PEI Core
-
-  Copyright (c) 2014, Intel Corporation. All rights reserved.
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php.
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include 
-#include 
-#include 
-
-#include "SecMain.h"
-
-/**
-  Find core image base.
-
-  @param[in]  BootFirmwareVolumePtrPoint to the boot firmware volume.
-  @param[out] SecCoreImageBase The base address of the SEC core image.
-  @param[out] PeiCoreImageBase The base address of the PEI core image.
-
-**/
-EFI_STATUS
-EFIAPI
-FindImageBase (
-  IN  EFI_FIRMWARE_VOLUME_HEADER   *BootFirmwareVolumePtr,
-  OUT EFI_PHYSICAL_ADDRESS *SecCoreImageBase,
-  OUT EFI_PHYSICAL_ADDRESS *PeiCoreImageBase
-  )
-{
-  EFI_PHYSICAL_ADDRESSCurrentAddress;
-  EFI_PHYSICAL_ADDRESSEndOfFirmwareVolume;
-  EFI_FFS_FILE_HEADER *File;
-  UINT32  Size;
-  EFI_PHYSICAL_ADDRESSEndOfFile;
-  EFI_COMMON_SECTION_HEADER   *Section;
-  EFI_PHYSICAL_ADDRESSEndOfSection;
-
-  *SecCoreImageBase = 0;
-  *PeiCoreImageBase = 0;
-
-  CurrentAddress = (EFI_PHYSICAL_ADDRESS)(UINTN) BootFirmwareVolumePtr;
-  EndOfFirmwareVolume = CurrentAddress + BootFirmwareVolumePtr->FvLength;
-
-  //
-  // Loop through the FFS files in the Boot Firmware Volume
-  //
-  for (EndOfFile = CurrentAddress + BootFirmwareVolumePtr->HeaderLength; ; ) {
-
-CurrentAddress = (EndOfFile + 7) & 0xfff8ULL;
-if (CurrentAddress > EndOfFirmwareVolume) {
-  return EFI_NOT_FOUND;
-}
-
-File = (EFI_FFS_FILE_HEADER*)(UINTN) CurrentAddress;
-if (IS_FFS_FILE2 (File)) {
-  Size = FFS_FILE2_SIZE (File);
-  if (Size <= 0x00FF) {
-return EFI_NOT_FOUND;
-  }
-} else {
-  Size = FFS_FILE_SIZE (File);
-  if (Size < sizeof (EFI_FFS_FILE_HEADER)) {
-return EFI_NOT_FOUND;
-  }
-}
-
-EndOfFile = CurrentAddress + 

Re: [edk2] BOM in .dec, .dsc, .fdf

[Tim Lewis]

Liming --

At a minimum, yes. The error message currently does not help the user to 
identify the problem correctly.

Better would be to skip the UTF-8 BOM marker, but complain later if a non-ASCII 
character shows up.

Tim

-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Wednesday, March 02, 2016 11:27 PM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Subject: RE: BOM in .dec, .dsc, .fdf

Tim:
  So, you suggest to let build tool report the meaning error message if .dec, 
.dsc, .fdf and .inf are not ASCII files. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Wednesday, March 02, 2016 7:42 AM
> To: Kinney, Michael D; edk2-devel@lists.01.org
> Subject: Re: [edk2] BOM in .dec, .dsc, .fdf
> 
> Mike --
> 
> Ok. It's not an EDK2 file, in this case. I suspected that this was 
> what was happening, since we couldn't find another non-ASCII character.
> 
> The error message (BC0DE) wasn't so helpful, coming back through the 
> exception handler in build.py.
> 
> Tim
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Tuesday, March 01, 2016 3:33 PM
> To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, 
> Michael D <michael.d.kin...@intel.com>
> Subject: RE: BOM in .dec, .dsc, .fdf
> 
> Tim,
> 
> Those files types are all required to be ASCII files.
> 
> If one of those files in EDK II repo has UTF-8 BOM, then that is a bug 
> and needs to be fixed.
> 
> I have seen text editors that auto convert ASCII to UTF-8 if a 
> non-ASCII character is ever added to a file.  The file then retains 
> the UTF-8 BOM even after the non-ASCII character is removed.  You have 
> to convert the file back to ASCII and save to remove the BOM.
> 
> Mike
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Tim Lewis
> > Sent: Tuesday, March 1, 2016 3:20 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] BOM in .dec, .dsc, .fdf
> >
> > I thought I saw a thread talking about this. We are seeing an issue 
> > with a UTF-8 BOM appears at the beginning of a .dec file, even if 
> > there are no other non-ASCII characters. In our case, this causes 
> > the parser to bomb out with a stack trace. This happens to our users in 
> > Asia.
> >
> > I couldn't find anything in the check-in comments, but perhaps I missed it?
> >
> > Tim
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel