regarding folder common/espressif

[yf13]

Currently we have arch/risc-v/src/commmon/espressif which holds espressif specific things only.

I am wondering if it can be moved out of the common folder of all RiscV chips? probably to a folder like arch/risc-v/src/espressif?

This feels more in line what we have done for arch/arm. This also makes its changes only be checked against espressif chips later when our CI is smarter.

[xiaoxiang781216]

Yes, I think so.

[yamt]

i guess whatever decision made about it would apply to arch/xtensa/src/common/espressif too.

[yf13]

@tmedicci can we have your opinion?

[tmedicci]

I prefer to keep it in common folder because it's common to all Espressif SoCs.

We used to have something like that and named the RISC-V-based SoCs just as espressif. This old organization was very confusing and we always had people asking about the SoCs. Then, we reverted it to make it easier to identify what is a common code source and what is specific to a chip only.
See, nuttx/arch/risc-v/src contains chips (and espressif isn't a chip). These chips may (or not) use a common code base (the code at arch/risc-v/src/commmon/espressif) or implement their own version of some peripheral/driver. The current organization allows doing that more straightforward. We thought a lot about the location of these folders trying to keep a consistency between existing and yet-to-be-supported SoCs on NuttX.

[yf13]

@tmedicci, thanks for sharing the history.

Can you teach why arch/risc-v/src/espressif is confusing people? I can't see it because specific names like arch/risc-v/src/esp32c3 will attract me at the first place.

[tmedicci]

@tmedicci, thanks for sharing the history.

Can you teach why arch/risc-v/src/espressif is confusing people? I can't see it because specific names like arch/risc-v/src/esp32c3 will attract me at the first place.

Well, it's more about concepts. See CONFIG_ARCH_CHIP used to set the chip directory for the nuttx/CMakeLists.txt, and for the board/chip directory at the traditional make-related files, like nuttx/tools/Config.mk: these configs refer to sources under arch/<arch>/src/<chip> and boards/<arch>/<chip>. I would expect this behavior to be followed by any arch/vendor/chip/. There are no espressif chips, and then makes no sense to move the common folder to arch/risc-v/src/espressif. If a series of chips use a common source code base, it makes sense to me it to be under arch/<arch>/src/common if the code applies to all arch or under arch/<arch>/src/common/<vendor> if applies to specific vendor.

I understand that it would be technically possible to keep the esp32c3 and the espressif folders under the same level, but this creates more effort in adjusting the build system and isn't as intuitive as using it under the common folder.

My point: don't mess arch, vendors and chips. Currently, the level arch/risc-v/src/ refers to chips (see first paragraph). One possible change would be transforming this level into vendors (and we'd have something like arch/risc-v/src/espressif/esp32c3 and arch/arm/src/stm/stm32f7, for instance) and move chips into it. As you may suppose, that would be a huge change (so, that's why we moved espressif vendor to the common folder)

[yf13]

Thank you @tmedicci for the explanations.

Seems you are assuming that subfolders of arch/risc-v/src/ must be chip specific but espressif isn't chip specific.

However, I think the directory structure design just says that chip specific folder should be subfolder of arch/risc-v/src, but it doesn't say that subfolders of arch/risc-v/src must all be chip specific.

Taking the stm32 example, it depends on armv7-m which further depends on common. Here both armv7-m and common are subfolders in arch/arm/src and are not chip specific.

[tmedicci]

Taking the stm32 example, it depends on armv7-m which further depends on common. Here both armv7-m and common are subfolders in arch/arm/src and are not chip specific.

Yes, exactly! This is confusing: if armv7-m is not a chip by itself, it should be moved to common because it provides source code to more than one chip of different vendors (I supposed about the various vendors). It isn't only about the path, but Kconfig and build-related files need to be adjusted to include "common" files, some of the "common" source files are in a sub-directory called common, others are in the same directory level. It isn't that easy for a beginner to figure that out. See, NuttX is growing and people are interested in supporting more devices: we need to create a clear path for our sources. We NEED new people contributing and understanding code organization clearly. We had that for RISC-V and Xtensa-based devices: we just kept using the same logic.