Re: [edk2] edk2 interface deprecation policy

2017-12-01 Thread Laszlo Ersek 
On 12/01/17 03:27, Ni, Ruiyu wrote:
> I prefer to remove all deprecated items because I like clean:)
> But then lots of customer complains may come.
> 
> So just provide my thoughts:
> Deprecated items can be separated into:
> 
> 1. Definitions: E.g.: UgaDraw protocol, DriverConfiguration2 protocol
> Keep:
> But harm the newbie developers because they don't know which 
> interfaces should depend on.
> Remove:
> A pure world.
> But easy to cause build break. Yet easy to fix by downloading the 
> definitions from old revision.
> Proposal:
> Move all deprecated definitions to a DeprecatePkg/OldPkg. 
> 
> 2. Modules. E.g.: IntelFrameworkModulePkg/Universal/BdsDxe, 
> IntelFrameworkModulePkg/Bus/Isa/*
>  Keep:
>  Increase feature owner's maintain effort.
>  Cause confusing because new features won't be enabled in deprecated 
> modules.
>  Remove:
>   A pure world.
>   But easy to cause build break. Yet easy to fix by downloading the 
> definitions from old revision.
> Proposal:
>  Keep it if in IntelFramework[Module]Pkg because in future the two 
> pkgs will be deprecated.
>  Move it to DeprecatePkg/OldPkg if in Mde[Module]Pkg
> 
> 3. Libraries: E.g.: 
> IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode
>   Same as #2.
> 
> So how about we create another GIT repo and store the DeprecatePkg/OldPkg.
> Old consumers can download old stuffs from the other GIT repo.
> Eventually the IntelFramework[Module]Pkg can be moved to that repo as well.

I really like the DeprecatedPkg idea, but I think the package should
live in the *same* edk2 repository. Similarly to EdkCompatibilityPkg.

The benefit is that deprecation can occur gradually, and it all will be
part of one common git history.

(I don't feel strongly about this topic, I just thought I'd comment on
the "separate git repo" part -- I think there's value in keeping
DeprecatedPkg in edk2.)

Thanks
Laszlo


>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
>> Liming
>> Sent: Friday, December 1, 2017 9:51 AM
>> To: Felix Poludov <fel...@ami.com>; af...@apple.com
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] edk2 interface deprecation policy
>>
>> Felix:
>>   I agree to define the tag to specify the deprecated definition, library 
>> and drivers.
>> If so, user can easily know which one is not used any more. But, I think we 
>> can
>> still keep them in edk2 project, because they have no negative impact.
>>
>> Thanks
>> Liming
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>> Felix Poludov
>>> Sent: Friday, December 01, 2017 6:12 AM
>>> To: af...@apple.com
>>> Cc: edk2-devel@lists.01.org
>>> Subject: Re: [edk2] edk2 interface deprecation policy
>>>
>>> I agree. It would be beneficial to have a mailing list discussion on
>>> how to deal with the deprecated item.
>>> In some cases it would make sense to tag an interface as deprecated,
>>> but keep in the code base for a while (6 month?) before actually deleting 
>>> it.
>>>
>>> -Original Message-
>>> From: af...@apple.com [mailto:af...@apple.com]
>>> Sent: Thursday, November 30, 2017 11:57 AM
>>> To: Felix Poludov
>>> Cc: edk2-devel@lists.01.org
>>> Subject: Re: [edk2] edk2 interface deprecation policy
>>>
>>> Felix,
>>>
>>> I don't think we have one
>>>
>>> Adding new interfaces does not impact the downstream projects, but
>>> depreciating interface can break stuff. Seems like it might at least be
>>> a good idea to have a depreciation discussion on the mailing  list. I'm
>>> open to other suggestions
>>>
>>> Thanks,
>>>
>>> Andrew Fish
>>>
>>>> On Nov 30, 2017, at 6:00 AM, Felix Poludov <fel...@ami.com> wrote:
>>>>
>>>> Does edk2 have a policy regarding deprecation of interface definition
>>> headers?
>>>> I can see that definition of the UgaDraw protocol that was deprecated
>>>> years
>>> ago (I believe in UEFI 2.0) is still part of the code base; yet,
>>> definition of the SMM Communication ACPI Table that was deprecated this
>>> year in UEFI 2.6B has already been removed.
>>>>
>>>> Please consider the environment before printing this email.
>>>>
>>>> The information contained

Re: [edk2] edk2 interface deprecation policy

2017-11-30 Thread Zeng, Star 
How about the case below for example? They all have comments " This library 
instance is no longer used and module using this library class should update to 
directly ..." for a very long time (since 2009) and no one should use them, 
when could they be removed?
Literally, they seems useful, and people can only know they are deprecated by 
looking into the comments.

MdeModulePkg/Include/Library/RecoveryLib.h
MdeModulePkg/Include/Library/S3Lib.h
MdeModulePkg/Library/PeiS3LibNull
MdeModulePkg/Library/PeiRecoveryLibNull
IntelFrameworkModulePkg/Library/PeiRecoveryLib
IntelFrameworkModulePkg/Library/PeiS3Lib


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, Ruiyu
Sent: Friday, December 1, 2017 10:27 AM
To: Gao, Liming <liming@intel.com>; Felix Poludov <fel...@ami.com>; 
af...@apple.com
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] edk2 interface deprecation policy

I prefer to remove all deprecated items because I like clean:) But then lots of 
customer complains may come.

So just provide my thoughts:
Deprecated items can be separated into:

1. Definitions: E.g.: UgaDraw protocol, DriverConfiguration2 protocol
Keep:
But harm the newbie developers because they don't know which interfaces 
should depend on.
Remove:
A pure world.
But easy to cause build break. Yet easy to fix by downloading the 
definitions from old revision.
Proposal:
Move all deprecated definitions to a DeprecatePkg/OldPkg. 

2. Modules. E.g.: IntelFrameworkModulePkg/Universal/BdsDxe, 
IntelFrameworkModulePkg/Bus/Isa/*
 Keep:
 Increase feature owner's maintain effort.
 Cause confusing because new features won't be enabled in deprecated 
modules.
 Remove:
  A pure world.
  But easy to cause build break. Yet easy to fix by downloading the 
definitions from old revision.
Proposal:
 Keep it if in IntelFramework[Module]Pkg because in future the two pkgs 
will be deprecated.
 Move it to DeprecatePkg/OldPkg if in Mde[Module]Pkg

3. Libraries: E.g.: 
IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode
  Same as #2.

So how about we create another GIT repo and store the DeprecatePkg/OldPkg.
Old consumers can download old stuffs from the other GIT repo.
Eventually the IntelFramework[Module]Pkg can be moved to that repo as well.


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Gao, Liming
> Sent: Friday, December 1, 2017 9:51 AM
> To: Felix Poludov <fel...@ami.com>; af...@apple.com
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] edk2 interface deprecation policy
> 
> Felix:
>   I agree to define the tag to specify the deprecated definition, library and 
> drivers.
> If so, user can easily know which one is not used any more. But, I 
> think we can still keep them in edk2 project, because they have no negative 
> impact.
> 
> Thanks
> Liming
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> >Of Felix Poludov
> >Sent: Friday, December 01, 2017 6:12 AM
> >To: af...@apple.com
> >Cc: edk2-devel@lists.01.org
> >Subject: Re: [edk2] edk2 interface deprecation policy
> >
> >I agree. It would be beneficial to have a mailing list discussion on 
> >how to deal with the deprecated item.
> >In some cases it would make sense to tag an interface as deprecated, 
> >but keep in the code base for a while (6 month?) before actually deleting it.
> >
> >-Original Message-
> >From: af...@apple.com [mailto:af...@apple.com]
> >Sent: Thursday, November 30, 2017 11:57 AM
> >To: Felix Poludov
> >Cc: edk2-devel@lists.01.org
> >Subject: Re: [edk2] edk2 interface deprecation policy
> >
> >Felix,
> >
> >I don't think we have one
> >
> >Adding new interfaces does not impact the downstream projects, but 
> >depreciating interface can break stuff. Seems like it might at least 
> >be a good idea to have a depreciation discussion on the mailing  
> >list. I'm open to other suggestions
> >
> >Thanks,
> >
> >Andrew Fish
> >
> >> On Nov 30, 2017, at 6:00 AM, Felix Poludov <fel...@ami.com> wrote:
> >>
> >> Does edk2 have a policy regarding deprecation of interface 
> >> definition
> >headers?
> >> I can see that definition of the UgaDraw protocol that was 
> >> deprecated years
> >ago (I believe in UEFI 2.0) is still part of the code base; yet, 
> >definition of the SMM Communication ACPI Table that was deprecated 
> >this year in UEFI 2.6B has already been removed.
> >>
> >> Please consider the en

Re: [edk2] edk2 interface deprecation policy

2017-11-30 Thread Zeng, Star 
The negative impact is there will be more and more deprecated codes in the 
project.
We'd better have an exit mechanism for them although some of them may need to 
be kept for compatibility case by case.


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
Liming
Sent: Friday, December 1, 2017 9:51 AM
To: Felix Poludov <fel...@ami.com>; af...@apple.com
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] edk2 interface deprecation policy

Felix:
  I agree to define the tag to specify the deprecated definition, library and 
drivers. If so, user can easily know which one is not used any more. But, I 
think we can still keep them in edk2 project, because they have no negative 
impact. 

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>Felix Poludov
>Sent: Friday, December 01, 2017 6:12 AM
>To: af...@apple.com
>Cc: edk2-devel@lists.01.org
>Subject: Re: [edk2] edk2 interface deprecation policy
>
>I agree. It would be beneficial to have a mailing list discussion on 
>how to deal with the deprecated item.
>In some cases it would make sense to tag an interface as deprecated, 
>but keep in the code base for a while (6 month?) before actually deleting it.
>
>-Original Message-
>From: af...@apple.com [mailto:af...@apple.com]
>Sent: Thursday, November 30, 2017 11:57 AM
>To: Felix Poludov
>Cc: edk2-devel@lists.01.org
>Subject: Re: [edk2] edk2 interface deprecation policy
>
>Felix,
>
>I don't think we have one
>
>Adding new interfaces does not impact the downstream projects, but 
>depreciating interface can break stuff. Seems like it might at least be 
>a good idea to have a depreciation discussion on the mailing  list. I'm 
>open to other suggestions
>
>Thanks,
>
>Andrew Fish
>
>> On Nov 30, 2017, at 6:00 AM, Felix Poludov <fel...@ami.com> wrote:
>>
>> Does edk2 have a policy regarding deprecation of interface definition
>headers?
>> I can see that definition of the UgaDraw protocol that was deprecated 
>> years
>ago (I believe in UEFI 2.0) is still part of the code base; yet, 
>definition of the SMM Communication ACPI Table that was deprecated this 
>year in UEFI 2.6B has already been removed.
>>
>> Please consider the environment before printing this email.
>>
>> The information contained in this message may be confidential and
>proprietary to American Megatrends, Inc.  This communication is 
>intended to be read only by the individual or entity to whom it is 
>addressed or by their designee. If the reader of this message is not 
>the intended recipient, you are on notice that any distribution of this 
>message, in any form, is strictly prohibited.  Please promptly notify 
>the sender by reply e-mail or by telephone at 770-246-8600, and then delete or 
>destroy all copies of the transmission.
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>
>
>Please consider the environment before printing this email.
>
>The information contained in this message may be confidential and 
>proprietary to American Megatrends, Inc.  This communication is 
>intended to be read only by the individual or entity to whom it is 
>addressed or by their designee. If the reader of this message is not 
>the intended recipient, you are on notice that any distribution of this 
>message, in any form, is strictly prohibited.  Please promptly notify 
>the sender by reply e-mail or by telephone at 770-246-8600, and then delete or 
>destroy all copies of the transmission.
>___
>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] edk2 interface deprecation policy

2017-11-30 Thread Ni, Ruiyu 
I prefer to remove all deprecated items because I like clean:)
But then lots of customer complains may come.

So just provide my thoughts:
Deprecated items can be separated into:

1. Definitions: E.g.: UgaDraw protocol, DriverConfiguration2 protocol
Keep:
But harm the newbie developers because they don't know which interfaces 
should depend on.
Remove:
A pure world.
But easy to cause build break. Yet easy to fix by downloading the 
definitions from old revision.
Proposal:
Move all deprecated definitions to a DeprecatePkg/OldPkg. 

2. Modules. E.g.: IntelFrameworkModulePkg/Universal/BdsDxe, 
IntelFrameworkModulePkg/Bus/Isa/*
 Keep:
 Increase feature owner's maintain effort.
 Cause confusing because new features won't be enabled in deprecated 
modules.
 Remove:
  A pure world.
  But easy to cause build break. Yet easy to fix by downloading the 
definitions from old revision.
Proposal:
 Keep it if in IntelFramework[Module]Pkg because in future the two pkgs 
will be deprecated.
 Move it to DeprecatePkg/OldPkg if in Mde[Module]Pkg

3. Libraries: E.g.: 
IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode
  Same as #2.

So how about we create another GIT repo and store the DeprecatePkg/OldPkg.
Old consumers can download old stuffs from the other GIT repo.
Eventually the IntelFramework[Module]Pkg can be moved to that repo as well.


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
> Liming
> Sent: Friday, December 1, 2017 9:51 AM
> To: Felix Poludov <fel...@ami.com>; af...@apple.com
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] edk2 interface deprecation policy
> 
> Felix:
>   I agree to define the tag to specify the deprecated definition, library and 
> drivers.
> If so, user can easily know which one is not used any more. But, I think we 
> can
> still keep them in edk2 project, because they have no negative impact.
> 
> Thanks
> Liming
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >Felix Poludov
> >Sent: Friday, December 01, 2017 6:12 AM
> >To: af...@apple.com
> >Cc: edk2-devel@lists.01.org
> >Subject: Re: [edk2] edk2 interface deprecation policy
> >
> >I agree. It would be beneficial to have a mailing list discussion on
> >how to deal with the deprecated item.
> >In some cases it would make sense to tag an interface as deprecated,
> >but keep in the code base for a while (6 month?) before actually deleting it.
> >
> >-Original Message-
> >From: af...@apple.com [mailto:af...@apple.com]
> >Sent: Thursday, November 30, 2017 11:57 AM
> >To: Felix Poludov
> >Cc: edk2-devel@lists.01.org
> >Subject: Re: [edk2] edk2 interface deprecation policy
> >
> >Felix,
> >
> >I don't think we have one
> >
> >Adding new interfaces does not impact the downstream projects, but
> >depreciating interface can break stuff. Seems like it might at least be
> >a good idea to have a depreciation discussion on the mailing  list. I'm
> >open to other suggestions
> >
> >Thanks,
> >
> >Andrew Fish
> >
> >> On Nov 30, 2017, at 6:00 AM, Felix Poludov <fel...@ami.com> wrote:
> >>
> >> Does edk2 have a policy regarding deprecation of interface definition
> >headers?
> >> I can see that definition of the UgaDraw protocol that was deprecated
> >> years
> >ago (I believe in UEFI 2.0) is still part of the code base; yet,
> >definition of the SMM Communication ACPI Table that was deprecated this
> >year in UEFI 2.6B has already been removed.
> >>
> >> Please consider the environment before printing this email.
> >>
> >> The information contained in this message may be confidential and
> >proprietary to American Megatrends, Inc.  This communication is
> >intended to be read only by the individual or entity to whom it is
> >addressed or by their designee. If the reader of this message is not
> >the intended recipient, you are on notice that any distribution of this
> >message, in any form, is strictly prohibited.  Please promptly notify
> >the sender by reply e-mail or by telephone at 770-246-8600, and then delete 
> >or
> destroy all copies of the transmission.
> >> ___
> >> edk2-devel mailing list
> >> edk2-devel@lists.01.org
> >> https://lists.01.org/mailman/listinfo/edk2-devel
> >
> >
> >Please consider the environment before printing this email.
> >
> >The information containe

Re: [edk2] edk2 interface deprecation policy

2017-11-30 Thread Gao, Liming 
Felix:
  I agree to define the tag to specify the deprecated definition, library and 
drivers. If so, user can easily know which one is not used any more. But, I 
think we can still keep them in edk2 project, because they have no negative 
impact. 

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Felix Poludov
>Sent: Friday, December 01, 2017 6:12 AM
>To: af...@apple.com
>Cc: edk2-devel@lists.01.org
>Subject: Re: [edk2] edk2 interface deprecation policy
>
>I agree. It would be beneficial to have a mailing list discussion on how to 
>deal
>with the deprecated item.
>In some cases it would make sense to tag an interface as deprecated, but
>keep in the code base for a while (6 month?) before actually deleting it.
>
>-Original Message-
>From: af...@apple.com [mailto:af...@apple.com]
>Sent: Thursday, November 30, 2017 11:57 AM
>To: Felix Poludov
>Cc: edk2-devel@lists.01.org
>Subject: Re: [edk2] edk2 interface deprecation policy
>
>Felix,
>
>I don't think we have one
>
>Adding new interfaces does not impact the downstream projects, but
>depreciating interface can break stuff. Seems like it might at least be a good
>idea to have a depreciation discussion on the mailing  list. I'm open to other
>suggestions
>
>Thanks,
>
>Andrew Fish
>
>> On Nov 30, 2017, at 6:00 AM, Felix Poludov <fel...@ami.com> wrote:
>>
>> Does edk2 have a policy regarding deprecation of interface definition
>headers?
>> I can see that definition of the UgaDraw protocol that was deprecated years
>ago (I believe in UEFI 2.0) is still part of the code base; yet, definition of 
>the
>SMM Communication ACPI Table that was deprecated this year in UEFI 2.6B
>has already been removed.
>>
>> Please consider the environment before printing this email.
>>
>> The information contained in this message may be confidential and
>proprietary to American Megatrends, Inc.  This communication is intended to
>be read only by the individual or entity to whom it is addressed or by their
>designee. If the reader of this message is not the intended recipient, you are
>on notice that any distribution of this message, in any form, is strictly
>prohibited.  Please promptly notify the sender by reply e-mail or by telephone
>at 770-246-8600, and then delete or destroy all copies of the transmission.
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>
>
>Please consider the environment before printing this email.
>
>The information contained in this message may be confidential and
>proprietary to American Megatrends, Inc.  This communication is intended to
>be read only by the individual or entity to whom it is addressed or by their
>designee. If the reader of this message is not the intended recipient, you are
>on notice that any distribution of this message, in any form, is strictly
>prohibited.  Please promptly notify the sender by reply e-mail or by telephone
>at 770-246-8600, and then delete or destroy all copies of the transmission.
>___
>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] edk2 interface deprecation policy

2017-11-30 Thread Felix Poludov 
I agree. It would be beneficial to have a mailing list discussion on how to 
deal with the deprecated item.
In some cases it would make sense to tag an interface as deprecated, but keep 
in the code base for a while (6 month?) before actually deleting it.

-Original Message-
From: af...@apple.com [mailto:af...@apple.com] 
Sent: Thursday, November 30, 2017 11:57 AM
To: Felix Poludov
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] edk2 interface deprecation policy

Felix,

I don't think we have one

Adding new interfaces does not impact the downstream projects, but depreciating 
interface can break stuff. Seems like it might at least be a good idea to have 
a depreciation discussion on the mailing  list. I'm open to other 
suggestions

Thanks,

Andrew Fish

> On Nov 30, 2017, at 6:00 AM, Felix Poludov <fel...@ami.com> wrote:
> 
> Does edk2 have a policy regarding deprecation of interface definition headers?
> I can see that definition of the UgaDraw protocol that was deprecated years 
> ago (I believe in UEFI 2.0) is still part of the code base; yet, definition 
> of the SMM Communication ACPI Table that was deprecated this year in UEFI 
> 2.6B has already been removed.
> 
> Please consider the environment before printing this email.
> 
> The information contained in this message may be confidential and proprietary 
> to American Megatrends, Inc.  This communication is intended to be read only 
> by the individual or entity to whom it is addressed or by their designee. If 
> the reader of this message is not the intended recipient, you are on notice 
> that any distribution of this message, in any form, is strictly prohibited.  
> Please promptly notify the sender by reply e-mail or by telephone at 
> 770-246-8600, and then delete or destroy all copies of the transmission.
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary 
to American Megatrends, Inc.  This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited.  Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] edk2 interface deprecation policy

2017-11-30 Thread Andrew Fish 
Felix,

I don't think we have one

Adding new interfaces does not impact the downstream projects, but depreciating 
interface can break stuff. Seems like it might at least be a good idea to have 
a depreciation discussion on the mailing  list. I'm open to other 
suggestions

Thanks,

Andrew Fish

> On Nov 30, 2017, at 6:00 AM, Felix Poludov  wrote:
> 
> Does edk2 have a policy regarding deprecation of interface definition headers?
> I can see that definition of the UgaDraw protocol that was deprecated years 
> ago (I believe in UEFI 2.0) is still part of the code base; yet, definition 
> of the SMM Communication ACPI Table that was deprecated this year in UEFI 
> 2.6B has already been removed.
> 
> Please consider the environment before printing this email.
> 
> The information contained in this message may be confidential and proprietary 
> to American Megatrends, Inc.  This communication is intended to be read only 
> by the individual or entity to whom it is addressed or by their designee. If 
> the reader of this message is not the intended recipient, you are on notice 
> that any distribution of this message, in any form, is strictly prohibited.  
> Please promptly notify the sender by reply e-mail or by telephone at 
> 770-246-8600, and then delete or destroy all copies of the transmission.
> ___
> 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] edk2 interface deprecation policy

2017-11-30 Thread Felix Poludov 
Does edk2 have a policy regarding deprecation of interface definition headers?
I can see that definition of the UgaDraw protocol that was deprecated years ago 
(I believe in UEFI 2.0) is still part of the code base; yet, definition of the 
SMM Communication ACPI Table that was deprecated this year in UEFI 2.6B has 
already been removed.

Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary 
to American Megatrends, Inc.  This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited.  Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel