Hi,
The reason is OK to set buffer address to NULL but the implantation can't
do something effective.
-Hsien
2012/10/30 <[email protected]>
> Send edk2-devel mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of edk2-devel digest..."
>
>
> Today's Topics:
>
> 1. About function UncachedSafeFreePool () (???)
> 2. Re: About function UncachedSafeFreePool () (Andrew Fish)
> 3. Re: About function UncachedSafeFreePool () (Charlie Hsu)
> 4. Question on Version & Storage_security protocol (Amol Tasgaonkar)
> 5. Re: Both legacy OpROM and UEFI BSD loaded (Tao Yuan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 30 Oct 2012 15:05:32 -0700
> From: ??? <[email protected]>
> Subject: [edk2] About function UncachedSafeFreePool ()
> To: [email protected]
> Message-ID:
> <
> caoax-jxnhvinop4s5nt9wqf3yxbesmr0m55ub2rdujidtn7...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi all,
> I think the statement "Buffer = NULL;" is redundant or we might modify the
> function as below:
>
> STATIC
> VOID
> EFIAPI
> SafeFreePool (
> IN VOID **Buffer
> )
> {
> if (*Buffer != NULL) {
> gBS->FreePool (*Buffer);
> *Buffer = NULL;
> }
> }
>
> How do you think about this?
>
> Regards,
> -Hsien
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 2
> Date: Tue, 30 Oct 2012 15:28:02 -0700
> From: Andrew Fish <[email protected]>
> Subject: Re: [edk2] About function UncachedSafeFreePool ()
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=utf-8
>
>
> On Oct 30, 2012, at 3:05 PM, ??? wrote:
>
> > Hi all,
> > I think the statement "Buffer = NULL;" is redundant or we might modify
> the function as below:
> >
> > STATIC
> > VOID
> > EFIAPI
> > SafeFreePool (
> > IN VOID **Buffer
> > )
> > {
> > if (*Buffer != NULL) {
> > gBS->FreePool (*Buffer);
> > *Buffer = NULL;
> > }
> > }
> >
> > How do you think about this?
> >
>
> I think changing the library API by adding an extra * to buffer would
> break all the calling code.
>
> I agree that setting the pointer, that is just in a register, to NULL does
> nothing. We should probably just remove the `Buffer = NULL` from the
> library function.
>
> > Regards,
> > -Hsien
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> >
> http://p.sf.net/sfu/appdyn_sfd2d_oct_______________________________________________
> > edk2-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 31 Oct 2012 06:57:40 +0800
> From: Charlie Hsu <[email protected]>
> Subject: Re: [edk2] About function UncachedSafeFreePool ()
> To: "[email protected]"
> <[email protected]>
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> According to UEFI 2.3.1, the gBS->FreePool () function returns the memory
> specified by Buffer to the system, but the address, which was allocated by
> gBS->AllocatePool() function, doesn't go back to NULL.
>
> For safety purpose, I think that set Buffer to NULL is reasonable.
>
> Best regards,
> Charlie Hsu
>
> -----Original Message-----
> From: Andrew Fish [mailto:[email protected]]
> Sent: Tuesday, October 30, 2012 3:28 PM
> To: [email protected]
> Subject: Re: [edk2] About function UncachedSafeFreePool ()
>
>
> On Oct 30, 2012, at 3:05 PM, ??? wrote:
>
> > Hi all,
> > I think the statement "Buffer = NULL;" is redundant or we might modify
> the function as below:
> >
> > STATIC
> > VOID
> > EFIAPI
> > SafeFreePool (
> > IN VOID **Buffer
> > )
> > {
> > if (*Buffer != NULL) {
> > gBS->FreePool (*Buffer);
> > *Buffer = NULL;
> > }
> > }
> >
> > How do you think about this?
> >
>
> I think changing the library API by adding an extra * to buffer would
> break all the calling code.
>
> I agree that setting the pointer, that is just in a register, to NULL does
> nothing. We should probably just remove the `Buffer = NULL` from the
> library function.
>
> > Regards,
> > -Hsien
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> >
> http://p.sf.net/sfu/appdyn_sfd2d_oct_______________________________________________
> > edk2-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> ------------------------------
>
> Message: 4
> Date: Tue, 30 Oct 2012 19:53:16 -0700 (PDT)
> From: Amol Tasgaonkar <[email protected]>
> Subject: [edk2] Question on Version & Storage_security protocol
> To: "[email protected]"
> <[email protected]>
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello,
> ?
> I have?3 question.
> ?
> 1. When i type version command in shell, it show as 2.31 as UEFI version.
> Is it same as UEFI 2.3.1 ?
> ?
> 2. If the answer to the above question is?TRUE then, i fail to understand
> why the?HandleProtocol() on the?STORAGE_SECURITY_COMMAND_PROTOCOL ?fails
> with error 3. I provide the device handle of the disk drive(BLOCKIO)?where
> the image is loaded from and needless to say that the drive is opal v2.
> ?
> 3. I tried to load the ATABusDxe driver and it also did not load the
> STORAGE_SECURITY_COMMAND_PROTOCOL? though the device had the opal Bit ON
> (data from the ATA_IDENTIFY command).
> ?
> Any help on this is appreciated.
> ?
> Thanks,
> ?
> -Amol.
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 5
> Date: Tue, 30 Oct 2012 22:40:36 -0700
> From: Tao Yuan <[email protected]>
> Subject: Re: [edk2] Both legacy OpROM and UEFI BSD loaded
> To: [email protected]
> Message-ID:
> <CAEh=+
> [email protected]>
> Content-Type: text/plain; charset="windows-1252"
>
> BlockIo is a trunk and once legacy OpROM executed it will marked the device
> handler as ALREADY_STARTED and how UEFI driver can get started on the same
> device handle? The same thing apply to UEFI first then blockio wil not
> able to start on that device handler so I believe it will be a bug if on
> some systems both of them get executed?
>
> Thanks,
> Tao
>
> On Tue, Oct 30, 2012 at 1:27 PM, Richardson, Brian <
> [email protected]> wrote:
>
> > The BIOS shouldn?t execute both UEFI OpROM & Legacy OpROM for the same
> > device. I would classify this as a bug. Of course, the OpROM should also
> > have some sort of check to see if the device has already been initialized
> > (safety net).****
> >
> > ** **
> >
> > Thanks ... br****
> >
> > ---****
> >
> > Brian Richardson -- [email protected] -- Twitter:
> intel_brian****
> >
> > ** **
> >
> > *From:* Andrew Fish [mailto:[email protected]]
> > *Sent:* Tuesday, October 30, 2012 4:02 PM
> >
> > *To:* [email protected]
> > *Subject:* Re: [edk2] Both legacy OpROM and UEFI BSD loaded****
> >
> > ** **
> >
> > If I can remember back to the original CSM spec the onboard disk devices
> > kind of work like this...****
> >
> > ** **
> >
> > Run EFI code to do the device discovery. When you start up CSM (for
> > legacy boot) you collect the discovery info from EFI and pass it to the
> > BIOS. For the onboard devices the INT 13h is not a full ROM, but just a
> > runtime shim. You have to pass it discovery info from EFI into BIOS. ****
> >
> > ** **
> >
> > Plug in devices should executed based on platform policy. Even on a pure
> > EFI system you may not chose to execute the PCI ROM to boot faster.
> Usually
> > a CSM legacy boot will post all the legacy ROMs for computability
> reasons.
> > ****
> >
> > ** **
> >
> > If you have both EFI & Legacy ROM active at the same time that sounds
> like
> > a bug?****
> >
> > ** **
> >
> > Andrew Fish****
> >
> > ** **
> >
> > On Oct 30, 2012, at 12:39 PM, Prakash, Sathya wrote:****
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
>
> ------------------------------
>
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
> End of edk2-devel Digest, Vol 34, Issue 113
> *******************************************
>
------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
