RE: kconfig (Re: mbedtls)

> -Original Message- > From: Gregory Nutt > Sent: Tuesday, May 26, 2020 2:13 AM > To: dev@nuttx.apache.org > Subject: Re: kconfig (Re: mbedtls) > > > > I agree, and all the more reason we should ensure that our project has > > a controlled snapshot of this tool -- and to ensure the lo

FAR for pointer to pointer

hi, our strtoul prototype is: unsigned long strtoul(FAR const char *nptr, FAR char **endptr, int base); why shouldn't they be like, say, "FAR char * FAR * endptr"?

Re: kconfig (Re: mbedtls)

On Tue, May 26, 2020 at 10:16 AM spudaneco wrote: > > Don't forget, you are not a user anymore. You are a maintainer and you are > responsible for keeping a stable environment for all users.Sent from Samsung > tablet. yes. i guess we share the goal. just having different opinions. >

Re: kconfig (Re: mbedtls)

On Tue, May 26, 2020 at 10:11 AM Nathan Hartman wrote: > > On Mon, May 25, 2020 at 8:41 PM Takashi Yamamoto > wrote: > > > On Tue, May 26, 2020 at 12:48 AM Gregory Nutt wrote: > > > > > > We should all be using a consistent, common version of > > > kconfig-frontends. A snapshot was taken and ha

Re: kconfig (Re: mbedtls)

Don't forget, you are not a user anymore.  You are a maintainer and you are responsible for keeping a stable environment for all users.Sent from Samsung tablet. Original message From: Takashi Yamamoto Date: 5/25/20 6:41 PM (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: kc

Re: kconfig (Re: mbedtls)

On Mon, May 25, 2020 at 8:41 PM Takashi Yamamoto wrote: > On Tue, May 26, 2020 at 12:48 AM Gregory Nutt wrote: > > > > We should all be using a consistent, common version of > > kconfig-frontends. A snapshot was taken and has never disappeared from > > internet contrary to other statements it i

Re: kconfig (Re: mbedtls)

On Tue, May 26, 2020 at 12:48 AM Gregory Nutt wrote: > > We should all be using a consistent, common version of > kconfig-frontends. A snapshot was taken and has never disappeared from > internet contrary to other statements it is always been here and will > always be here: https://bitbucket.org/

Re: kconfig (Re: mbedtls)

I agree, and all the more reason we should ensure that our project has a controlled snapshot of this tool -- and to ensure the longevity of that snapshot so that it will not be lost suddenly! There is also a snapshot of genromfs in the tools repository. This is a snapshot of the tool from th

Re: kconfig (Re: mbedtls)

On Mon, May 25, 2020 at 12:28 PM Gregory Nutt wrote: > Most projects that use kconfig-frontends use a snapshot version that is > built into the codebase. We cannot do that because kconfig-frontends is > GPL. However, I still argue that we should use a fixed, common version > of kconfig-frontends

Re: kconfig (Re: mbedtls)

On Mon, May 25, 2020 at 11:48 AM Gregory Nutt wrote: A snapshot was taken and has never disappeared from internet contrary to other statements it is always been here and will always be here: https://bitbucket.org/nuttx/tools/src/master/ Correct. I meant that the original (from Yann Morin) di

Re: kconfig (Re: mbedtls)

On 5/25/2020 10:03 AM, Nathan Hartman wrote: On Mon, May 25, 2020 at 11:48 AM Gregory Nutt wrote: A snapshot was taken and has never disappeared from internet contrary to other statements it is always been here and will always be here: https://bitbucket.org/nuttx/tools/src/master/ Correct. I m

Re: kconfig (Re: mbedtls)

On Mon, May 25, 2020 at 11:48 AM Gregory Nutt wrote: > A snapshot was taken and has never disappeared from > internet contrary to other statements it is always been here and will > always be here: https://bitbucket.org/nuttx/tools/src/master/ Correct. I meant that the original (from Yann Morin) d

Re: kconfig (Re: mbedtls)

We should all be using a consistent, common version of kconfig-frontends.  A snapshot was taken and has never disappeared from internet contrary to other statements it is always been here and will always be here: https://bitbucket.org/nuttx/tools/src/master/ Since the kconfig-frontends pro

Re: kconfig (Re: mbedtls)

We should all be using a consistent, common version of kconfig-frontends.  A snapshot was taken and has never disappeared from internet contrary to other statements it is always been here and will always be here: https://bitbucket.org/nuttx/tools/src/master/ We do not accept any  Python-based

Re: kconfig (Re: mbedtls)

On Mon, May 25, 2020 at 12:36 AM Takashi Yamamoto wrote: > On Mon, May 25, 2020 at 1:00 AM Nathan Hartman > wrote: > > We do have to solve the issue of Kconfig. That has disappeared from > > the Internet and we depend on it. We were told, before we joined > > do we have some reasons not to switc

Re: Correct call sequence to initialize the heap in CONFIG_BUILD_FLAT?

On Mon, May 25, 2020 at 1:25 AM Laitinen, Jukka wrote: > > Hi, > > Right now, looking at the file nx_start.c, all calls to up_allocate_heap are > being done when one of these flags are defined: > > #if defined(MM_KERNEL_USRHEAP_INIT) || defined(CONFIG_MM_KERNEL_HEAP) || \ > defined(CONFIG_MM

Re: mbedtls

On Mon, May 25, 2020 at 10:51 AM Gregory Nutt wrote: > I would say that it is an absolute requirement that nothing depend on > GIT in anyway from the standpoint of the end user. I agree Nathan

Re: Get size of block character device file with stat()

> The bch driver supports an IOCTL called BIOC_GEOMETRY that will return the geometry of the underlying block device. Yes, I understand. But user application handle all files the same way using path and int stat(FAR const char *path, FAR struct stat *buf) function. I've made a pull request #1118

Re: mbedtls

Yes, we can reuse github.com/nuttx to host the 3rd party library which stop the active development. But It's better to host the library by the different git to keep the full history for each project. I think it could be used in projects in active development too. I have seen people take a

Re: mbedtls

Yes, I think it could live at github.com/nuttx/apps-externals I'm not a big fun of git submodules but it could be a way to integrate the a copy of external projects that could live as forks there. Please ... no submodules in the git repositories!  The don't work for people who don't use G

Re: mbedtls

Yes, I think it could live at github.com/nuttx/apps-externals I'm not a big fun of git submodules but it could be a way to integrate the a copy of external projects that could live as forks there. Please ... no submodules in the git repositories!  The don't work for people who don't use GIT

Re: mbedtls

Hi Xiang, Yes, I think it could live at github.com/nuttx/apps-externals I'm not a big fun of git submodules but it could be a way to integrate the a copy of external projects that could live as forks there. BR, Alan On 5/25/20, Xiang Xiao wrote: > Yes, we can reuse github.com/nuttx to host th

Re: Get size of block character device file with stat()

It looks like I overthink and the best and simple solution is just to use for all block devices the block_operation function of inode to get geometry: inode->u.i_bops->geometry I miss that bchlib is already use this function to fill bchlib_s structure. Will try this approach now. The bch

RE: mbedtls

Yes, we can reuse github.com/nuttx to host the 3rd party library which stop the active development. But It's better to host the library by the different git to keep the full history for each project. > -Original Message- > From: Alan Carvalho de Assis > Sent: Monday, May 25, 2020 8:01 P

Re: Get size of block character device file with stat()

It looks like I overthink and the best and simple solution is just to use for all block devices the block_operation function of inode to get geometry: inode->u.i_bops->geometry I miss that bchlib is already use this function to fill bchlib_s structure. Will try this approach now. пн, 25 мая 2

Get size of block character device file with stat()

Hi, I wonder how to get size of character device that referenced mtd partition block device? As I see bchlib_setup in drivers/bch/bchlib_setup.c fills block geometry info to bchlib_s structure (number of sectors and sector size) that then stored as i_private to inode. This inode is part of the ro

Re: mbedtls

I completely agree on that! Also I think it is important to have a copy of each thirdparty project at nuttx-apps-external to avoid they disappear from the Internet. BR, Alan On 5/25/20, Abdelatif Guettouche wrote: > I think we should avoid apps/external. People use it for their own app, > put

Re: mbedtls

I think we should avoid apps/external. People use it for their own app, putting more code there would mess up their versioning control. A separate folder would be more convenient (whatever its name is "3rdparty", "thirdparty", "glue", etc.) On Mon, May 25, 2020, 08:23 Xiang Xiao wrote: > Yes, i

Re: NuttX on the IMXRT1060-EVK

Hi Thomas, It works! I appreciate your help. It saved me a lot of time. Yes, I removed those jumpers to bypass the onboard debugger (CMSIS-DAP) and to use J-Link. BR. Erdem Thomas Axelsson , 22 May 2020 Cum, 12:07 tarihinde şunu yazdı: > Hi Erdem, > > I'm not actively developing using IMXRT at

RE: SPI slave interface discussion

Hi, I have opened a PR #1115 describing this IF change idea. I have also included the slave controller driver code that we have been using, which demonstrates the usage of the interface. I also started drafting the needed change for samv5 controller driver, but that part is untested. In our c

Jenkins build is back to normal : NuttX-Nightly-Build #170

See

RE: mbedtls

Yes, item 4 is also good enough. To reduce the git repo number and simplify the finding, I think that item 1 and 4 is better than other. > -Original Message- > From: Takashi Yamamoto > Sent: Monday, May 25, 2020 2:55 PM > To: dev@nuttx.apache.org > Subject: Re: mbedtls > > On Mon, May 2