An idea to reduce duplicate code in ./boards/.

[apache]

An idea to reduce duplicate code in ./boards/.

[acassis]

Hi Pieter, in fact the idea of moving from the old configs/ directory to the new boards/ was exactly to let boards to share common code. Maybe to make it clear, the directory should be called ./boards/arm/common/drivers/ and so besides drivers we could have other common things (init/, script/, etc).

Also note that inside each board family (i.e. stm32, nrf52, etc) already exist a drivers/ directory. So I think putting this new drivers/ inside common/ will help to avoid users making mistakes.

Since @jerpelea is was to responsible to this original change, we need to wait for this feedback.

[patacongo]

I am opposed to these kinds of changes. The board directories are customization points and MUST NOT BE MERGED INTO COMMON FILES. That corrupts the modulare architecture of the OS and cannot be permitted.

There are things that are common not particularly customization points (like some USB Host logic). But I would resist strong any willy nilly combination of code just because it looks the same today (it might look different tomorrow, that is the nature of customization points).

I would refer you to the top-level INVIOLABLES.txt under "The Enemies."

109 Sometimes Code Duplication is OK
110 --------------------------------
111
112 o Sometimes is better to duplicate some logic than to introduce coupling

Any rampant combination of logic for now reason than the OCD compulsion to due so must be resisted. What you are proposing WILL damage the OS.

Autoleds, in particular, must not be combined!

Anyone who supports this proposal has no sense or understanding of the NuttX architecture or modularity goals. This would an absolute disaster for the OS!

[patacongo]

Very bad idea. Violates the basic principles or a modular operating system. We cannot consider this.

[wingunder]

Hi Alan,

Thanks for your answer.

@acassis wrote:

Maybe to make it clear, the directory should be called ./boards/arm/common/drivers/ and so besides drivers we could have other common things (init/, script/, etc).

I take it you mean ./boards/arm/common/drivers/ , ./boards/arm/common/init/, ./boards/arm/common/init/, etc?

@acassis wrote:

Also note that inside each board family (i.e. stm32, nrf52, etc) already exist a drivers/ directory. So I think putting this new drivers/ inside common/ will help to avoid users making mistakes.

Do you mean that for example a new driver for ./boards/arm/stm32/<newboard>/src/<newdriver>.* will have to live in ./boards/arm/common/drivers/, so that ./boards/arm/<stm32variants>/<board>/ can re-use it in a modular way?

[wingunder]

Hi Greg,

Thanks for your answer. I appreciate your point of view.

I do understand that making a braking change in any common place will break all code that uses it.
The trade-off is that changing something, that was copied 50 or more times, takes much more time and is just as error prone as fixing it in a common place.

@patacongo wrote:

The board directories are customization points and MUST NOT BE MERGED INTO COMMON FILES.
.
.
What you are proposing WILL damage the OS.

This was not my intention. I wanted to move common stuff from ./boards/ into a common place inside ./boards/. From my understanding this cannot affect the OS, but it can affect other implementations inside ./boards/.

I'm sorry if I'm misunderstanding the OS, but am I wrong to argue that ./boards/ is not part of the OS, as ./boards/ has implementations that just use the OS?

[patacongo]

Reducing code duplication is not a priority. Never has been, never will be. Maintaining a strict module, independent architecture where changes in one are does not affect other areas is a high priority. We get there via a modulare, siloed architecture with no sharing between silos.

I am VERY strongly opposed with the urge to combine code for no reason than the other people are obsessed with combining code. It is unhealthy for the OS and will be resisted with every fiber.

There has never been a single case where duplicating code has caused any significant issues. yes, sometimes people have the same problem but that had been corrected in similar code. That happens maybe a couple of times per yeard and is immediately resolved. But combined code has a far worse problem (aside from trashing the architecture): Peoplel change the combined code for their own purposes and break everyone else's platforms. That is no acceptable and will not be allowed to happen (at least any futher that it already has).

This is a bad topic and is not going get you any support. I suggest doing something better with your time. This is unacceptable.