deprecation policy


Boie, Andrew P
 

Do we have a concrete policy on deprecated APIs?

A while back we agreed to deprecate the dynamic IRQ / exception APIs, and task irq APIs, and they all have been marked with __deprecated. The change that did this landed mid-April and was in the 1.4.0 release.
Once the merge window reopens after 1.5.0 gets tagged and released, I would like to remove this code from the kernel.
Any objections to this? Is 6 months enough time (period between 1.4.0 -> 1.6.0) for end users to adapt?

Andrew


Perez-Gonzalez, Inaky <inaky.perez-gonzalez@...>
 

Are there any in-kernel users?
________________________________
From: Boie, Andrew P [andrew.p.boie(a)intel.com]
Sent: Friday, July 29, 2016 1:28 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] deprecation policy

Do we have a concrete policy on deprecated APIs?

A while back we agreed to deprecate the dynamic IRQ / exception APIs, and task irq APIs, and they all have been marked with __deprecated. The change that did this landed mid-April and was in the 1.4.0 release.
Once the merge window reopens after 1.5.0 gets tagged and released, I would like to remove this code from the kernel.
Any objections to this? Is 6 months enough time (period between 1.4.0 -> 1.6.0) for end users to adapt?

Andrew


Boie, Andrew P
 

________________________________
From: Perez-Gonzalez, Inaky
Sent: Thursday, July 28, 2016 5:33 PM
To: Boie, Andrew P; devel(a)lists.zephyrproject.org
Subject: RE: deprecation policy

Are there any in-kernel users?
No not at this time. There is one reference to dynamic IRQs, in the task IRQ code. No kernel or sample/testcase code that uses task IRQs.


Kumar Gala
 

On Jul 28, 2016, at 10:29 PM, Boie, Andrew P <andrew.p.boie(a)intel.com> wrote:


From: Perez-Gonzalez, Inaky
Sent: Thursday, July 28, 2016 5:33 PM
To: Boie, Andrew P; devel(a)lists.zephyrproject.org
Subject: RE: deprecation policy

Are there any in-kernel users?
No not at this time. There is one reference to dynamic IRQs, in the task IRQ code. No kernel or sample/testcase code that uses task IRQs.
Was it expected that the interface was for kernel code only? If so, I think its fair game to remove.

If this was intended for some application code, we should probably come up with with a documented policy about how we intend to address such issues going forward. I’m guessing in the short term for this case its probably fine. I keep think we need some means to try and have a clearer definition of application interfaces vs kernel.

- k


Boie, Andrew P
 

On Mon, 2016-08-01 at 12:24 -0500, Kumar Gala wrote:
 
No not at this time. There is one reference to dynamic IRQs, in the
task IRQ code. No kernel or sample/testcase code that uses task
IRQs.
Was it expected that the interface was for kernel code only?  If so,
I think its fair game to remove.
They were exposed to the application level. They both were concerned
with installing interrupt handlers dynamically at runtime. The
preferred approach nowadays is to configure interrupts statically at
build time, as removing dynamic interrupts presents the option on XIP
systems to keep certain large-ish data structures like the IDT in ROM.

If this was intended for some application code, we should probably
come up with with a documented policy about how we intend to address
such issues going forward.  I’m guessing in the short term for this
case its probably fine.  I keep think we need some means to try and
have a clearer definition of application interfaces vs kernel.
Agreed, I don't think we have a concrete policy. We may need the TSC to
weigh in.

Andrew


Patel, Niheer <Niheer.Patel@...>
 

-----Original Message-----
From: Boie, Andrew P [mailto:andrew.p.boie(a)intel.com]
Sent: Monday, August 01, 2016 10:57 AM
To: kumar.gala(a)linaro.org
Cc: devel(a)lists.zephyrproject.org; PEREZ-GONZALEZ, INAKY
Subject: [devel] Re: Re: deprecation policy

On Mon, 2016-08-01 at 12:24 -0500, Kumar Gala wrote:

No not at this time. There is one reference to dynamic IRQs, in the
task IRQ code. No kernel or sample/testcase code that uses task
IRQs.
Was it expected that the interface was for kernel code only?  If so, I
think its fair game to remove.
They were exposed to the application level. They both were concerned with
installing interrupt handlers dynamically at runtime. The preferred approach
nowadays is to configure interrupts statically at build time, as removing dynamic
interrupts presents the option on XIP systems to keep certain large-ish data
structures like the IDT in ROM.

If this was intended for some application code, we should probably
come up with with a documented policy about how we intend to address
such issues going forward.  I’m guessing in the short term for this
case its probably fine.  I keep think we need some means to try and
have a clearer definition of application interfaces vs kernel.
Agreed, I don't think we have a concrete policy. We may need the TSC to weigh
in.
I have added two separate agenda items for the TSC on Wednesday to discuss separately or together as it makes sense.
1. General deprecation policy
2. Defining application versus kernel interfaces.

Regards,
Niheer


Andrew


Boie, Andrew P
 

On Mon, 2016-08-01 at 18:05 +0000, Patel, Niheer V (Wind River) wrote:
Agreed, I don't think we have a concrete policy. We may need the
TSC to weigh
in.
I have added two separate agenda items for the TSC on Wednesday to
discuss separately or together as it makes sense.
        1. General deprecation policy
        2. Defining application versus kernel interfaces.
Thanks Niheer.
wrt item #2, my current understanding is that all internel kernel
interfaces are prefixed with '_'.

Andrew


Perez-Gonzalez, Inaky <inaky.perez-gonzalez@...>
 

I think it calls for a separate include

I'd put public app interfaces in include/zephyr

anything in include/ itself is a private kernel interface, fair game (same applies to include/subarea)
________________________________________
From: Kumar Gala [kumar.gala(a)linaro.org]
Sent: Tuesday, August 02, 2016 1:24 AM
To: Boie, Andrew P
Cc: Perez-Gonzalez, Inaky; devel(a)lists.zephyrproject.org
Subject: Re: [devel] deprecation policy

On Jul 28, 2016, at 10:29 PM, Boie, Andrew P <andrew.p.boie(a)intel.com> wrote:


From: Perez-Gonzalez, Inaky
Sent: Thursday, July 28, 2016 5:33 PM
To: Boie, Andrew P; devel(a)lists.zephyrproject.org
Subject: RE: deprecation policy

Are there any in-kernel users?
No not at this time. There is one reference to dynamic IRQs, in the task IRQ code. No kernel or sample/testcase code that uses task IRQs.
Was it expected that the interface was for kernel code only? If so, I think its fair game to remove.

If this was intended for some application code, we should probably come up with with a documented policy about how we intend to address such issues going forward. I’m guessing in the short term for this case its probably fine. I keep think we need some means to try and have a clearer definition of application interfaces vs kernel.

- k