Topics

Handling unused but bit rotting code...


Marcus Shawcroft <marcus.shawcroft@...>
 

Hi,

Recently I stumbled into a couple of examples of components within the
zephyr tree that for whatever reason are currently unused, not
compilable and not testable in current form. The code is retained in
tree because it is expected to be useful at some point in the future.

The const config-info and const driver-api patches I posted a few
weeks back are now complete bar those patches which impact drivers
that currently cannot be compiled. I've refrained from pushing those
patches to gerrit in order to avoid presenting changes that cannot be
tested (or even compiled).

This means that those components for which I have not pushed the
relevant patches are effectively 'bit rotting'.

There are a couple of different approaches to this situation:

1) Wire up some form of trivial test quickly.
2) Pull the component out of tree. Re-instate the driver (from git)
and fix it up when someone has use for it (or it can be tested, or
perhaps at least compiled).
3) Leave the component in the tree, don't take any change. Fix it up
when it has use in the future.
4) Leave the component in the tree, take structural changes that
cannot be compiled or tested, deal with the breakage in the future
when the component has use/tests or compiles.
5) ?

Option 1 is clearly a good approach and indeed in the context of the
patch sets referred to above, this has happened. However it is not
always possible or practical...

Which leaves us with 2/3/4 for dealing with the awkward squad.

Does zephyr have a policy on dealing with this situation?

Cheers
/Marcus


Nashif, Anas
 

Marcus,
Do you have a list of the code you mention below?

Anas

-----Original Message-----
From: Marcus Shawcroft [mailto:marcus.shawcroft(a)gmail.com]
Sent: Wednesday, November 2, 2016 4:43 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Handling unused but bit rotting code...

Hi,

Recently I stumbled into a couple of examples of components within the zephyr tree that for whatever reason are currently unused, not compilable and not testable in current form. The code is retained in tree because it is expected to be useful at some point in the future.

The const config-info and const driver-api patches I posted a few weeks back are now complete bar those patches which impact drivers that currently cannot be compiled. I've refrained from pushing those patches to gerrit in order to avoid presenting changes that cannot be tested (or even compiled).

This means that those components for which I have not pushed the relevant patches are effectively 'bit rotting'.

There are a couple of different approaches to this situation:

1) Wire up some form of trivial test quickly.
2) Pull the component out of tree. Re-instate the driver (from git) and fix it up when someone has use for it (or it can be tested, or perhaps at least compiled).
3) Leave the component in the tree, don't take any change. Fix it up when it has use in the future.
4) Leave the component in the tree, take structural changes that cannot be compiled or tested, deal with the breakage in the future when the component has use/tests or compiles.
5) ?

Option 1 is clearly a good approach and indeed in the context of the patch sets referred to above, this has happened. However it is not always possible or practical...

Which leaves us with 2/3/4 for dealing with the awkward squad.

Does zephyr have a policy on dealing with this situation?

Cheers
/Marcus


Marcus Shawcroft <marcus.shawcroft@...>
 

On 2 November 2016 at 11:20, Nashif, Anas <anas.nashif(a)intel.com> wrote:
Marcus,
Do you have a list of the code you mention below?
Sure, the drivers that I have yet to find a test case for are:

pwm/dw
gpio/mmio
adc/dw
pinmux_dev_qmsi
grove/temperature_sensor
grove/light_sensor
gpio/stm32

Cheers
/Marcus


Anas

-----Original Message-----
From: Marcus Shawcroft [mailto:marcus.shawcroft(a)gmail.com]
Sent: Wednesday, November 2, 2016 4:43 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Handling unused but bit rotting code...

Hi,

Recently I stumbled into a couple of examples of components within the zephyr tree that for whatever reason are currently unused, not compilable and not testable in current form. The code is retained in tree because it is expected to be useful at some point in the future.

The const config-info and const driver-api patches I posted a few weeks back are now complete bar those patches which impact drivers that currently cannot be compiled. I've refrained from pushing those patches to gerrit in order to avoid presenting changes that cannot be tested (or even compiled).

This means that those components for which I have not pushed the relevant patches are effectively 'bit rotting'.

There are a couple of different approaches to this situation:

1) Wire up some form of trivial test quickly.
2) Pull the component out of tree. Re-instate the driver (from git) and fix it up when someone has use for it (or it can be tested, or perhaps at least compiled).
3) Leave the component in the tree, don't take any change. Fix it up when it has use in the future.
4) Leave the component in the tree, take structural changes that cannot be compiled or tested, deal with the breakage in the future when the component has use/tests or compiles.
5) ?

Option 1 is clearly a good approach and indeed in the context of the patch sets referred to above, this has happened. However it is not always possible or practical...

Which leaves us with 2/3/4 for dealing with the awkward squad.

Does zephyr have a policy on dealing with this situation?

Cheers
/Marcus


Boie, Andrew P
 

On Wed, 2016-11-02 at 11:36 +0000, Marcus Shawcroft wrote:
Sure, the drivers that I have yet to find a test case for are:

pwm/dw
gpio/mmio
adc/dw
pinmux_dev_qmsi
grove/temperature_sensor
grove/light_sensor
gpio/stm32
I feel that outside of extraordinary circumstances, a test program
should be added to show that a subsystem or driver at least *compiles*,
if not prove that it works.

Option 1 is clearly a good approach and indeed in the context of theĀ 
patch sets referred to above, this has happened. However it is notĀ 
always possible or practical...
Under what circumstances is adding a small sample to at least build
against the relevant APIs not possible/practical? Obviously it's not
always feasible to prove that something works correctly, especially an
external peripheral which may require some elaborate test apparatus,
but proving that something at least compiles seems trivial to me.

Andrew


Marcus Shawcroft <marcus.shawcroft@...>
 

On 2 November 2016 at 18:42, Boie, Andrew P <andrew.p.boie(a)intel.com> wrote:
On Wed, 2016-11-02 at 11:36 +0000, Marcus Shawcroft wrote:
Sure, the drivers that I have yet to find a test case for are:

pwm/dw
gpio/mmio
adc/dw
pinmux_dev_qmsi
grove/temperature_sensor
grove/light_sensor
gpio/stm32
I feel that outside of extraordinary circumstances, a test program
should be added to show that a subsystem or driver at least *compiles*,
if not prove that it works.

Option 1 is clearly a good approach and indeed in the context of the
patch sets referred to above, this has happened. However it is not
always possible or practical...
Under what circumstances is adding a small sample to at least build
against the relevant APIs not possible/practical? Obviously it's not
always feasible to prove that something works correctly, especially an
external peripheral which may require some elaborate test apparatus,
but proving that something at least compiles seems trivial to me.
The trigger for this thread is pwm/dw where no board currently
supports the driver, it does not currently build but there is an
expectation that the driver will be useful in the future.

Cheers
/Marcus