Yes, I think Raiden's approach is better because it keeps generic drivers (and upper-half) in a separated place from arch specific drivers.
BR, Alan On Sat, Oct 3, 2026 at 11:12 AM Xiang Xiao <[email protected]> wrote: > One intermediate solution could be shared the driver code from the same > chip vendor like raiden00pl done for stm family. > > On Fri, Oct 2, 2026 at 12:23 PM <[email protected]> wrote: > > > I'd support that spproach. For example, I am currently dealing with > > practically same peripheral drivers for NXP chips; arch/arm/imx9 and > > arch/arm64/imx9 have duplicates of the drivers for exactly the same SoC. > > arch/arm/imxrt has also the same peripheral drivers, 3rd time. So having > > something like drivers/<vendor> (lower halfs), arch/cpu (cpu > architectures) > > and arch/chip (SoC specifics/integration) would make integration much > > cleaner. As an intermediate step, everything doesn't need to be > harmonized, > > there could be different versions of the same drivers initially so that > > nothing breaks. But structure change would make a lot of sense. > > > > - Jukka > > > > Xiang Xiao kirjoitti perjantai 2. lokakuuta 2026: > > > From the discussion, the major concern of vendor HAL in Zephyr is the > > code > > > duplication for the same IP. > > > But in NuttX, even the native chip integration still duplicates a lot > of > > > code which share the same IP. > > > Should NuttX driver integration switch from arch/chip/xxx to > > driver/xxx/yyy > > > like Linux/Zephyr? > > > So, the chip could share the code if they use the same hardware IP > block. > > > > > > Thanks > > > Xiang > > > > > > On Fri, Oct 2, 2026 at 4:12 AM Alan C. Assis <[email protected]> > wrote: > > > > > > > Hi Ahmed, > > > > > > > > I think the issue you raised is valid; they have an enormous number > of > > > > developers because the project was promoted very strongly starting in > > 2016 > > > > when it became part of the Linux Foundation. > > > > > > > > However, having fewer people doesn't mean we should take the easy way > > out > > > > and end-up in the same quality situation they are currently facing. > > > > > > > > In fact it is better to have less supported hardware, but a few very > > well > > > > supported ones. > > > > > > > > So, I was trying to accept the idea that the HAL was good for NuttX, > > but > > > > after reading that thread, I think it will be the opposite. > > > > > > > > Vendors will add integrations with poor HAL quality and we will > inherit > > > > responsibility for that bad code. > > > > > > > > BR, > > > > > > > > Alan > > > > > > > > On Thu, Oct 1, 2026 at 4:47 PM Ahmed Ashraf < > > [email protected]> > > > > wrote: > > > > > > > > > I read a bit from the discussion, so they want to make the drivers > > native > > > > > implemented right? > > > > > > > > > > I think this will be easier a bit because they have a nice number > of > > > > > specialized maintainers for each area, iam a bit new contributor to > > > > Nuttx ( > > > > > and to Zephyr too ) I didn't see that number of contributers in > Nuttx > > > > which > > > > > could make it harder. I think making specialized groups of > > maintainers > > > > for > > > > > each area ( just like Zephyr do ) would make the migration easier. > > > > > > > > > > Best regards, > > > > > Ahmed > > > > > > > > > > On Thu, Oct 1, 2026, 10:23 PM Alan C. Assis <[email protected]> > > wrote: > > > > > > > > > > > Hi Everyone, > > > > > > > > > > > > While we discuss making HAL official on NuttX, the Zephyr project > > is > > > > now > > > > > > discussing avoiding it: > > > > > > > > > > > > https://github.com/zephyrproject-rtos/zephyr/issues/108088 > > > > > > > > > > > > I think it's too late for them, but we still have a chance... > > > > > > > > > > > > BR, > > > > > > > > > > > > Alan > > > > > > > > > > > > > > > > > > > > > > -- > > Lähetetty Sailfish-laitteestani >
