snikeguo commented on issue #16415:
URL: https://github.com/apache/nuttx/issues/16415#issuecomment-2926815162
>Furthermore your proposed simplicity comes with a big cost, which is the
use using dynamic memory allocation. I think should be avoided on a RTOS for
resource-constrained devices.
Actually, it won't. You can take a look at my PR code. If
CONFIG_ARCH_HAVE_SDIO_PREFLIGHT is not defined, the buffer provided by the user
will be used directly. If CONFIG_ARCH_HAVE_SDIO_PREFLIGHT is defined, the
address will be checked first. If the address is aligned, the data will be
transferred directly. If not, an aligned address will be allocated.
```
read( buf,buflen )
{
#ifdef CONFIG_ARCH_HAVE_SDIO_PREFLIGHT
if( dma addr is not align?)
{
new align manager(buflen)
read sector(algin buffer)
}
else
{read sector(buf)}
#else
read sector (buf)
#endif
}
```
If we don't use dynamic memory and POSIX, why are we using NuttX? Wouldn't
it be better to use FreeRTOS or uC/OS? Why would I choose a relatively
heavyweight framework like NuttX?
You can't have your cake and eat it too. Take security and convenience as an
example—they've always been a contradiction.
I believe our goal should be to provide the application layer with as many
convenient interfaces as possible, while ensuring that the interfaces exposed
to the specific chip driver layer are as simple as possible to implement. The
remaining complex tasks should be handled by the NUTTX device driver layer,
which requires individuals with philosophical thinking to tackle.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
