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 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 the time I wrote the ROMFS file system. > People have been using "willy-nilly" versions of genromfs, I believe. > However, so far that has not caused any problems. > For genromfs, Ubuntu and WSL can be installed directly by "sudo apt-get install genromfs". kconfig-frontend also get supported in the recent Debian/Ubuntu release: https://packages.debian.org/sid/kconfig-frontends https://manpages.debian.org/testing/kconfig-frontends/index.html But, anyway we need take a snapshot for other platform. > There is other interesting stuff in the tools directory that people are not > well aware of. For example, nxfuse: > > A Linux FUSE implementation that enables native mounting of NuttX > filesystems > in Linux. Currently supports SmartFS and NXFFS (within the limitations > of > the NXFFS architecture). See the nxfuse/README.txt file for further > information.
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. > Original message From: Takashi Yamamoto > Date: 5/25/20 6:41 PM (GMT-06:00) To: > dev@nuttx.apache.org Subject: 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/nuttx/tools/src/master/>> We do not accept any > Python-based tools in the critical build path.> There are some secondary > Python scripts under tools/ but we cannot> permit the introduction of any new > user tool requirements in the basic> build. That is simply off-limits.>> > Think of the NuttX user first! Technologies and tools are much further> down > the list.i can understand you don't like to have python dependency.but i > don't think the "user first" argument is not a good reason.for some users > (like me) python is definitely easier to deal withthan the current state of > kconfig-frontends.>> Greg>> On 5/25/2020 9:38 AM, Nathan Hartman wrote:> > 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 > switch to kconfiglib?> > Does kconfiglib depend on Python? Currently we do > not have a> > dependency on Python. That would introduce Python as a pretty > big> > dependency, which I would rather avoid.> >> > Also, that project could > disappear from the Internet, just like> > Kconfig, and we'd be back at square > one.> >> > I think we should solve the kconfig licensing / hosting question.> > > Early in our ASF efforts we were told that exceptions are sometimes> > made > so that a project can host "well-known" third party tools that it> > depends > on. We depend on kconfig as a central piece of our build> > system, just as > we depend on 3rd party compiler toolchains etc. It> > runs on the developer's > host machine. It does NOT get compiled into> > the user's NuttX build. > Kconfig as a project has come and gone from> > the Internet so for the time > being Greg is hosting a mirror at his> > BitBucket along with other build > tools.> >> > We need some guidance from our mentors on how to ensure the > longevity> > of the tools, like Kconfig, that are needed for NuttX, at > Apache> > NuttX, not at some third party location that can disappear > suddenly.> >> > Thanks,> > Nathan>>
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 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 tools in the critical build path. > > > There are some secondary Python scripts under tools/ but we cannot > > > permit the introduction of any new user tool requirements in the basic > > > build. That is simply off-limits. > > > > > > Think of the NuttX user first! Technologies and tools are much further > > > down the list. > > > > i can understand you don't like to have python dependency. > > but i don't think the "user first" argument is not a good reason. > > for some users (like me) python is definitely easier to deal with > > than the current state of kconfig-frontends. > > > What don't you like about the current state of kconfig-frontends? having to build and install a tool from source is already cumbersome. especially when you need to apply patches manually. it isn't a problem for me anymore because i already get used to it. but i guess it's a hurdle for new users. > > Nathan
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: 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/nuttx/tools/src/master/>> We do not accept any Python-based tools in the critical build path.> There are some secondary Python scripts under tools/ but we cannot> permit the introduction of any new user tool requirements in the basic> build. That is simply off-limits.>> Think of the NuttX user first! Technologies and tools are much further> down the list.i can understand you don't like to have python dependency.but i don't think the "user first" argument is not a good reason.for some users (like me) python is definitely easier to deal withthan the current state of kconfig-frontends.>> Greg>> On 5/25/2020 9:38 AM, Nathan Hartman wrote:> > 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 switch to kconfiglib?> > Does kconfiglib depend on Python? Currently we do not have a> > dependency on Python. That would introduce Python as a pretty big> > dependency, which I would rather avoid.> >> > Also, that project could disappear from the Internet, just like> > Kconfig, and we'd be back at square one.> >> > I think we should solve the kconfig licensing / hosting question.> > Early in our ASF efforts we were told that exceptions are sometimes> > made so that a project can host "well-known" third party tools that it> > depends on. We depend on kconfig as a central piece of our build> > system, just as we depend on 3rd party compiler toolchains etc. It> > runs on the developer's host machine. It does NOT get compiled into> > the user's NuttX build. Kconfig as a project has come and gone from> > the Internet so for the time being Greg is hosting a mirror at his> > BitBucket along with other build tools.> >> > We need some guidance from our mentors on how to ensure the longevity> > of the tools, like Kconfig, that are needed for NuttX, at Apache> > NuttX, not at some third party location that can disappear suddenly.> >> > Thanks,> > Nathan>>
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 is always been here and will > > always be here: https://bitbucket.org/nuttx/tools/src/master/ > > > > We do not accept any Python-based tools in the critical build path. > > There are some secondary Python scripts under tools/ but we cannot > > permit the introduction of any new user tool requirements in the basic > > build. That is simply off-limits. > > > > Think of the NuttX user first! Technologies and tools are much further > > down the list. > > i can understand you don't like to have python dependency. > but i don't think the "user first" argument is not a good reason. > for some users (like me) python is definitely easier to deal with > than the current state of kconfig-frontends. > What don't you like about the current state of kconfig-frontends? Nathan
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/nuttx/tools/src/master/ > > We do not accept any Python-based tools in the critical build path. > There are some secondary Python scripts under tools/ but we cannot > permit the introduction of any new user tool requirements in the basic > build. That is simply off-limits. > > Think of the NuttX user first! Technologies and tools are much further > down the list. i can understand you don't like to have python dependency. but i don't think the "user first" argument is not a good reason. for some users (like me) python is definitely easier to deal with than the current state of kconfig-frontends. > > Greg > > On 5/25/2020 9:38 AM, Nathan Hartman wrote: > > 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 switch to kconfiglib? > > Does kconfiglib depend on Python? Currently we do not have a > > dependency on Python. That would introduce Python as a pretty big > > dependency, which I would rather avoid. > > > > Also, that project could disappear from the Internet, just like > > Kconfig, and we'd be back at square one. > > > > I think we should solve the kconfig licensing / hosting question. > > Early in our ASF efforts we were told that exceptions are sometimes > > made so that a project can host "well-known" third party tools that it > > depends on. We depend on kconfig as a central piece of our build > > system, just as we depend on 3rd party compiler toolchains etc. It > > runs on the developer's host machine. It does NOT get compiled into > > the user's NuttX build. Kconfig as a project has come and gone from > > the Internet so for the time being Greg is hosting a mirror at his > > BitBucket along with other build tools. > > > > We need some guidance from our mentors on how to ensure the longevity > > of the tools, like Kconfig, that are needed for NuttX, at Apache > > NuttX, not at some third party location that can disappear suddenly. > > > > Thanks, > > Nathan > >
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 the time I wrote the ROMFS file system. People have been using "willy-nilly" versions of genromfs, I believe. However, so far that has not caused any problems. There is other interesting stuff in the tools directory that people are not well aware of. For example, nxfuse: A Linux FUSE implementation that enables native mounting of NuttX filesystems in Linux. Currently supports SmartFS and NXFFS (within the limitations of the NXFFS architecture). See the nxfuse/README.txt file for further information.
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... no matter what is available in some bleeding > edge repository. > > That is important because if new and/or incompatible features are added > to the bleeding edge kconfig-frontends then are exploited in NuttX, this > will cause problems for the rest of the world who do not have those > features. That is best solved by everyone using a common version of > kconfig-frontends, that being the one at > https://bitbucket.org/nuttx/tools/src/master/ > > If, for some reason, we want to have some features that are available > only in some newer release, then we should carefully integrate a new > snapshot at https://bitbucket.org/nuttx/tools/src/master/, make an > announcement to all NuttX users indicating our intent to upgrade to a > new version, and after some time then, and only then. we can exploit any > new features. Any willy-nilly uncontrolled use of kconfig-frontends > versions will not have a good result. It will break user's builds! We > need to be be careful, measured, and slow when considering any updates > to this tool. 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! Nathan
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) disappeared. Eventually Morin did put it back online and IIRC said that the server had been disconnected from the Internet for some weeks due to moving to a new apartment. Thanks to you having the foresight to keep a snapshot, our community didn't suffer any disruption. Nathan 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... no matter what is available in some bleeding edge repository. That is important because if new and/or incompatible features are added to the bleeding edge kconfig-frontends then are exploited in NuttX, this will cause problems for the rest of the world who do not have those features. That is best solved by everyone using a common version of kconfig-frontends, that being the one at https://bitbucket.org/nuttx/tools/src/master/ If, for some reason, we want to have some features that are available only in some newer release, then we should carefully integrate a new snapshot at https://bitbucket.org/nuttx/tools/src/master/, make an announcement to all NuttX users indicating our intent to upgrade to a new version, and after some time then, and only then. we can exploit any new features. Any willy-nilly uncontrolled use of kconfig-frontends versions will not have a good result. It will break user's builds! We need to be be careful, measured, and slow when considering any updates to this tool.
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 meant that the original (from Yann Morin) disappeared. Eventually Morin did put it back online and IIRC said that the server had been disconnected from the Internet for some weeks due to moving to a new apartment. Thanks to you having the foresight to keep a snapshot, our community didn't suffer any disruption. Nathan
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) disappeared. Eventually Morin did put it back online and IIRC said that the server had been disconnected from the Internet for some weeks due to moving to a new apartment. Thanks to you having the foresight to keep a snapshot, our community didn't suffer any disruption. Nathan
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 project is dead, we can consider that the authoritative source for the tools for our purposes. There we can accept any changes that may be necessary and do not have to be concerned with upstream compatibility.
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 tools in the critical build path. There are some secondary Python scripts under tools/ but we cannot permit the introduction of any new user tool requirements in the basic build. That is simply off-limits. Think of the NuttX user first! Technologies and tools are much further down the list. Greg On 5/25/2020 9:38 AM, Nathan Hartman wrote: 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 switch to kconfiglib? Does kconfiglib depend on Python? Currently we do not have a dependency on Python. That would introduce Python as a pretty big dependency, which I would rather avoid. Also, that project could disappear from the Internet, just like Kconfig, and we'd be back at square one. I think we should solve the kconfig licensing / hosting question. Early in our ASF efforts we were told that exceptions are sometimes made so that a project can host "well-known" third party tools that it depends on. We depend on kconfig as a central piece of our build system, just as we depend on 3rd party compiler toolchains etc. It runs on the developer's host machine. It does NOT get compiled into the user's NuttX build. Kconfig as a project has come and gone from the Internet so for the time being Greg is hosting a mirror at his BitBucket along with other build tools. We need some guidance from our mentors on how to ensure the longevity of the tools, like Kconfig, that are needed for NuttX, at Apache NuttX, not at some third party location that can disappear suddenly. Thanks, Nathan
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 switch to kconfiglib? Does kconfiglib depend on Python? Currently we do not have a dependency on Python. That would introduce Python as a pretty big dependency, which I would rather avoid. Also, that project could disappear from the Internet, just like Kconfig, and we'd be back at square one. I think we should solve the kconfig licensing / hosting question. Early in our ASF efforts we were told that exceptions are sometimes made so that a project can host "well-known" third party tools that it depends on. We depend on kconfig as a central piece of our build system, just as we depend on 3rd party compiler toolchains etc. It runs on the developer's host machine. It does NOT get compiled into the user's NuttX build. Kconfig as a project has come and gone from the Internet so for the time being Greg is hosting a mirror at his BitBucket along with other build tools. We need some guidance from our mentors on how to ensure the longevity of the tools, like Kconfig, that are needed for NuttX, at Apache NuttX, not at some third party location that can disappear suddenly. Thanks, Nathan
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: 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 git fork for application code that that they want to modify. Then they put their modifications on a branch of that fork. Then it is very simple to refresh the master branch of the application and rebase the modified branch. In that way, we can keep in sync with the active upstream project with only a little effort. That is an advantage of keeping 3rd party code outside of the NuttX repositories. The best would be to get the application code to take our changes upstream. That could be done with a simple PR from the fork. But in the event that they are unwilling to accept the changes upstream, keeping our changes on a branch of a local fork is still workable for us.
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 and they are a nuisance and impossible to maintain. No one likes them.
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 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 PM >> To: dev@nuttx.apache.org >> Subject: 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, 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, 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 25, 2020 at 3:41 PM Xiang Xiao >> >> > >> >> wrote: >> >> > > >> >> > > >> >> > > >> >> > > > -Original Message- >> >> > > > From: Nathan Hartman >> >> > > > Sent: Monday, May 25, 2020 12:00 AM >> >> > > > To: dev@nuttx.apache.org >> >> > > > Subject: Re: mbedtls >> >> > > > >> >> > > > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis < >> >> acas...@gmail.com> wrote: >> >> > > > > Some months ago I suggested that NuttX could focus only in >> >> > > > > the kernel and we could create an external distribution using >> >> > > > > some build system like buildroot, yocto, etc. But as some >> >> > > > > people pointed, maybe a great strength of NuttX is to have >> >> > > > > everything >> >> integrated. >> >> > > > >> >> > > > That is a strength of NuttX, and it would be a shame to ruin it >> >> > > > for no technical reason and only because we can't find an >> >> > > > acceptable way >> >> to deal with licenses and where to keep code... >> >> > > > >> >> > > > ...which is why I think the "glue code" idea is best for 3rd >> >> > > > party >> >> code that we want to integrate. >> >> > > > >> >> > > > With "glue code": >> >> > > > * We do not have to copy 3rd party projects into our repository. >> >> > > > * We do not need external non-Apache-project repositories. >> >> > > > * We do not have to copy 3rd party projects into external >> >> non-Apache-project repositories. >> >> > > > >> >> > > > All we do is develop "glue code" which comprises Kconfig files, >> >> > > > Make.defs files, and possibly patch files. Those would be >> >> > > > developed by us. Those would be part of Apache NuttX. Those >> >> > > > would have the >> >> Apache license. We would NOT copy any 3rd party projects >> >> > into our repositories. >> >> > > > >> >> > > > When users select those items in Kconfig, our build system will >> >> > > > invoke the "glue code" which will download/clone (if not >> >> > > > already >> >> > > > present) the 3rd party project onto the user's machine and >> >> > > > build >> >> that code as part of their NuttX build. >> >> > > > >> >> &
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 PM > To: dev@nuttx.apache.org > Subject: 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, 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, 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 25, 2020 at 3:41 PM Xiang Xiao > >> > > >> wrote: > >> > > > >> > > > >> > > > >> > > > -Original Message- > >> > > > From: Nathan Hartman > >> > > > Sent: Monday, May 25, 2020 12:00 AM > >> > > > To: dev@nuttx.apache.org > >> > > > Subject: Re: mbedtls > >> > > > > >> > > > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis < > >> acas...@gmail.com> wrote: > >> > > > > Some months ago I suggested that NuttX could focus only in > >> > > > > the kernel and we could create an external distribution using > >> > > > > some build system like buildroot, yocto, etc. But as some > >> > > > > people pointed, maybe a great strength of NuttX is to have > >> > > > > everything > >> integrated. > >> > > > > >> > > > That is a strength of NuttX, and it would be a shame to ruin it > >> > > > for no technical reason and only because we can't find an > >> > > > acceptable way > >> to deal with licenses and where to keep code... > >> > > > > >> > > > ...which is why I think the "glue code" idea is best for 3rd > >> > > > party > >> code that we want to integrate. > >> > > > > >> > > > With "glue code": > >> > > > * We do not have to copy 3rd party projects into our repository. > >> > > > * We do not need external non-Apache-project repositories. > >> > > > * We do not have to copy 3rd party projects into external > >> non-Apache-project repositories. > >> > > > > >> > > > All we do is develop "glue code" which comprises Kconfig files, > >> > > > Make.defs files, and possibly patch files. Those would be > >> > > > developed by us. Those would be part of Apache NuttX. Those > >> > > > would have the > >> Apache license. We would NOT copy any 3rd party projects > >> > into our repositories. > >> > > > > >> > > > When users select those items in Kconfig, our build system will > >> > > > invoke the "glue code" which will download/clone (if not > >> > > > already > >> > > > present) the 3rd party project onto the user's machine and > >> > > > build > >> that code as part of their NuttX build. > >> > > > > >> > > > Our glue code could be smart: For example if a 3rd party > >> > > > library is GPL, in our glue code, it would depend on > >> > > > "CONFIG_ALLOW_GPL_LICENSE" > >> > > > or something like that. So the end user will have to decide if > >> > > > GPL is suitable, and if yes, select to allow it, and then > >> > > > select > >> whatever GPL 3rd party code they want to have it built and included > >> in their > >> > image. > >> > > > > >> > >
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, > 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, 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 25, 2020 at 3:41 PM Xiang Xiao >> wrote: >> > > >> > > >> > > >> > > > -Original Message- >> > > > From: Nathan Hartman >> > > > Sent: Monday, May 25, 2020 12:00 AM >> > > > To: dev@nuttx.apache.org >> > > > Subject: Re: mbedtls >> > > > >> > > > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis < >> acas...@gmail.com> wrote: >> > > > > Some months ago I suggested that NuttX could focus only in the >> > > > > kernel and we could create an external distribution using some >> > > > > build system like buildroot, yocto, etc. But as some people >> > > > > pointed, maybe a great strength of NuttX is to have everything >> integrated. >> > > > >> > > > That is a strength of NuttX, and it would be a shame to ruin it for >> > > > no technical reason and only because we can't find an acceptable >> > > > way >> to deal with licenses and where to keep code... >> > > > >> > > > ...which is why I think the "glue code" idea is best for 3rd party >> code that we want to integrate. >> > > > >> > > > With "glue code": >> > > > * We do not have to copy 3rd party projects into our repository. >> > > > * We do not need external non-Apache-project repositories. >> > > > * We do not have to copy 3rd party projects into external >> non-Apache-project repositories. >> > > > >> > > > All we do is develop "glue code" which comprises Kconfig files, >> > > > Make.defs files, and possibly patch files. Those would be developed >> > > > by us. Those would be part of Apache NuttX. Those would have the >> Apache license. We would NOT copy any 3rd party projects >> > into our repositories. >> > > > >> > > > When users select those items in Kconfig, our build system will >> > > > invoke the "glue code" which will download/clone (if not already >> > > > present) the 3rd party project onto the user's machine and build >> that code as part of their NuttX build. >> > > > >> > > > Our glue code could be smart: For example if a 3rd party library is >> > > > GPL, in our glue code, it would depend on >> > > > "CONFIG_ALLOW_GPL_LICENSE" >> > > > or something like that. So the end user will have to decide if GPL >> > > > is suitable, and if yes, select to allow it, and then select >> whatever GPL 3rd party code they want to have it built and included in >> their >> > image. >> > > > >> > > > There is no problem with licensing with this approach. >> > > > >> > > > There are no hostile forks. >> > > > >> > > > There is no need to ask permission, SGAs, etc. because we are not >> copying 3rd party code into our repositories. >> > > > >> > > > And you can integrate every FOSS project in the world with NuttX. >> > > > >> > > > Because: We are only developing glue code and we own the glue code. >> > > > >> > > > People can choose to activate it if they want to, or not. If they >> > > > want to, they accept the licenses of the 3rd party code that they >> will download. >> > > > >> > > >> > > So the question is where should we put the "glue code"? >> > > 1.Put to apps/external/ directly >> > > 2.Pu
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, 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 25, 2020 at 3:41 PM Xiang Xiao > wrote: > > > > > > > > > > > > > -Original Message- > > > > From: Nathan Hartman > > > > Sent: Monday, May 25, 2020 12:00 AM > > > > To: dev@nuttx.apache.org > > > > Subject: Re: mbedtls > > > > > > > > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis < > acas...@gmail.com> wrote: > > > > > Some months ago I suggested that NuttX could focus only in the > > > > > kernel and we could create an external distribution using some > > > > > build system like buildroot, yocto, etc. But as some people > > > > > pointed, maybe a great strength of NuttX is to have everything > integrated. > > > > > > > > That is a strength of NuttX, and it would be a shame to ruin it for > > > > no technical reason and only because we can't find an acceptable way > to deal with licenses and where to keep code... > > > > > > > > ...which is why I think the "glue code" idea is best for 3rd party > code that we want to integrate. > > > > > > > > With "glue code": > > > > * We do not have to copy 3rd party projects into our repository. > > > > * We do not need external non-Apache-project repositories. > > > > * We do not have to copy 3rd party projects into external > non-Apache-project repositories. > > > > > > > > All we do is develop "glue code" which comprises Kconfig files, > > > > Make.defs files, and possibly patch files. Those would be developed > > > > by us. Those would be part of Apache NuttX. Those would have the > Apache license. We would NOT copy any 3rd party projects > > into our repositories. > > > > > > > > When users select those items in Kconfig, our build system will > > > > invoke the "glue code" which will download/clone (if not already > > > > present) the 3rd party project onto the user's machine and build > that code as part of their NuttX build. > > > > > > > > Our glue code could be smart: For example if a 3rd party library is > > > > GPL, in our glue code, it would depend on "CONFIG_ALLOW_GPL_LICENSE" > > > > or something like that. So the end user will have to decide if GPL > > > > is suitable, and if yes, select to allow it, and then select > whatever GPL 3rd party code they want to have it built and included in their > > image. > > > > > > > > There is no problem with licensing with this approach. > > > > > > > > There are no hostile forks. > > > > > > > > There is no need to ask permission, SGAs, etc. because we are not > copying 3rd party code into our repositories. > > > > > > > > And you can integrate every FOSS project in the world with NuttX. > > > > > > > > Because: We are only developing glue code and we own the glue code. > > > > > > > > People can choose to activate it if they want to, or not. If they > > > > want to, they accept the licenses of the 3rd party code that they > will download. > > > > > > > > > > So the question is where should we put the "glue code"? > > > 1.Put to apps/external/ directly > > > 2.Put to a new git(e.g. apache-nuttx-external.git) 3.Put to some > > > folders under apps by catalog(e.g. apps/crypto/mbedtls) I prefer item > > > 1 or item 2 personally. > > > > 4. similar to 1, but put them to a new directory, say apps/glues, to > avoid conflicting with the existing apps/external users. > > > > > > > > > The only concern I can see with this is: What happens if I, as a > > > > user of NuttX, depend on external projects, and those external > > > > projects disappear from the Internet. Well, the answer is that our > > > > glue code should allow you to customize the download/clone location. > So, as a user of NuttX, you can create your own local clone > > of 3rd party code, so that if the original disappears from the Internet, > you have a copy. > > > > That becomes the user's responsibility. We don't copy any 3rd party > code into our repositories. > > > > > > > > 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 > Apache, that sometimes ASF does allow to mirror well-known > > FOSS tools. > > > > So we'll have to look at that. > > > > > > > > > > Before ASF host this tools, we have to keep them on > https://bitbucket.org/nuttx or https://github.com/nuttx. > > > > > > > Nathan > > > > >
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 25, 2020 at 3:41 PM Xiang Xiao wrote: > > > > > > > > > -Original Message- > > > From: Nathan Hartman > > > Sent: Monday, May 25, 2020 12:00 AM > > > To: dev@nuttx.apache.org > > > Subject: Re: mbedtls > > > > > > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis > > > wrote: > > > > Some months ago I suggested that NuttX could focus only in the > > > > kernel and we could create an external distribution using some > > > > build system like buildroot, yocto, etc. But as some people > > > > pointed, maybe a great strength of NuttX is to have everything > > > > integrated. > > > > > > That is a strength of NuttX, and it would be a shame to ruin it for > > > no technical reason and only because we can't find an acceptable way to > > > deal with licenses and where to keep code... > > > > > > ...which is why I think the "glue code" idea is best for 3rd party code > > > that we want to integrate. > > > > > > With "glue code": > > > * We do not have to copy 3rd party projects into our repository. > > > * We do not need external non-Apache-project repositories. > > > * We do not have to copy 3rd party projects into external > > > non-Apache-project repositories. > > > > > > All we do is develop "glue code" which comprises Kconfig files, > > > Make.defs files, and possibly patch files. Those would be developed > > > by us. Those would be part of Apache NuttX. Those would have the Apache > > > license. We would NOT copy any 3rd party projects > into our repositories. > > > > > > When users select those items in Kconfig, our build system will > > > invoke the "glue code" which will download/clone (if not already > > > present) the 3rd party project onto the user's machine and build that > > > code as part of their NuttX build. > > > > > > Our glue code could be smart: For example if a 3rd party library is > > > GPL, in our glue code, it would depend on "CONFIG_ALLOW_GPL_LICENSE" > > > or something like that. So the end user will have to decide if GPL > > > is suitable, and if yes, select to allow it, and then select whatever GPL > > > 3rd party code they want to have it built and included in their > image. > > > > > > There is no problem with licensing with this approach. > > > > > > There are no hostile forks. > > > > > > There is no need to ask permission, SGAs, etc. because we are not copying > > > 3rd party code into our repositories. > > > > > > And you can integrate every FOSS project in the world with NuttX. > > > > > > Because: We are only developing glue code and we own the glue code. > > > > > > People can choose to activate it if they want to, or not. If they > > > want to, they accept the licenses of the 3rd party code that they will > > > download. > > > > > > > So the question is where should we put the "glue code"? > > 1.Put to apps/external/ directly > > 2.Put to a new git(e.g. apache-nuttx-external.git) 3.Put to some > > folders under apps by catalog(e.g. apps/crypto/mbedtls) I prefer item > > 1 or item 2 personally. > > 4. similar to 1, but put them to a new directory, say apps/glues, to avoid > conflicting with the existing apps/external users. > > > > > > The only concern I can see with this is: What happens if I, as a > > > user of NuttX, depend on external projects, and those external > > > projects disappear from the Internet. Well, the answer is that our > > > glue code should allow you to customize the download/clone location. So, > > > as a user of NuttX, you can create your own local clone > of 3rd party code, so that if the original disappears from the Internet, you > have a copy. > > > That becomes the user's responsibility. We don't copy any 3rd party code > > > into our repositories. > > > > > > 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 Apache, > > > that sometimes ASF does allow to mirror well-known > FOSS tools. > > > So we'll have to look at that. > > > > > > > Before ASF host this tools, we have to keep them on > > https://bitbucket.org/nuttx or https://github.com/nuttx. > > > > > Nathan > >
Re: mbedtls
On Mon, May 25, 2020 at 3:41 PM Xiang Xiao wrote: > > > > > -Original Message- > > From: Nathan Hartman > > Sent: Monday, May 25, 2020 12:00 AM > > To: dev@nuttx.apache.org > > Subject: Re: mbedtls > > > > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis > > wrote: > > > Some months ago I suggested that NuttX could focus only in the kernel > > > and we could create an external distribution using some build system > > > like buildroot, yocto, etc. But as some people pointed, maybe a great > > > strength of NuttX is to have everything integrated. > > > > That is a strength of NuttX, and it would be a shame to ruin it for no > > technical reason and only because we can't find an acceptable way > > to deal with licenses and where to keep code... > > > > ...which is why I think the "glue code" idea is best for 3rd party code > > that we want to integrate. > > > > With "glue code": > > * We do not have to copy 3rd party projects into our repository. > > * We do not need external non-Apache-project repositories. > > * We do not have to copy 3rd party projects into external > > non-Apache-project repositories. > > > > All we do is develop "glue code" which comprises Kconfig files, Make.defs > > files, and possibly patch files. Those would be developed by > > us. Those would be part of Apache NuttX. Those would have the Apache > > license. We would NOT copy any 3rd party projects into our > > repositories. > > > > When users select those items in Kconfig, our build system will invoke the > > "glue code" which will download/clone (if not already > > present) the 3rd party project onto the user's machine and build that code > > as part of their NuttX build. > > > > Our glue code could be smart: For example if a 3rd party library is GPL, in > > our glue code, it would depend on > > "CONFIG_ALLOW_GPL_LICENSE" > > or something like that. So the end user will have to decide if GPL is > > suitable, and if yes, select to allow it, and then select whatever GPL > > 3rd party code they want to have it built and included in their image. > > > > There is no problem with licensing with this approach. > > > > There are no hostile forks. > > > > There is no need to ask permission, SGAs, etc. because we are not copying > > 3rd party code into our repositories. > > > > And you can integrate every FOSS project in the world with NuttX. > > > > Because: We are only developing glue code and we own the glue code. > > > > People can choose to activate it if they want to, or not. If they want to, > > they accept the licenses of the 3rd party code that they will > > download. > > > > So the question is where should we put the "glue code"? > 1.Put to apps/external/ directly > 2.Put to a new git(e.g. apache-nuttx-external.git) > 3.Put to some folders under apps by catalog(e.g. apps/crypto/mbedtls) > I prefer item 1 or item 2 personally. 4. similar to 1, but put them to a new directory, say apps/glues, to avoid conflicting with the existing apps/external users. > > > The only concern I can see with this is: What happens if I, as a user of > > NuttX, depend on external projects, and those external projects > > disappear from the Internet. Well, the answer is that our glue code should > > allow you to customize the download/clone location. So, as > > a user of NuttX, you can create your own local clone of 3rd party code, so > > that if the original disappears from the Internet, you have a > > copy. > > That becomes the user's responsibility. We don't copy any 3rd party code > > into our repositories. > > > > 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 Apache, that sometimes ASF does allow to mirror well-known FOSS > > tools. > > So we'll have to look at that. > > > > Before ASF host this tools, we have to keep them on > https://bitbucket.org/nuttx or https://github.com/nuttx. > > > Nathan >
RE: mbedtls
> -Original Message- > From: Nathan Hartman > Sent: Monday, May 25, 2020 12:00 AM > To: dev@nuttx.apache.org > Subject: Re: mbedtls > > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis > wrote: > > Some months ago I suggested that NuttX could focus only in the kernel > > and we could create an external distribution using some build system > > like buildroot, yocto, etc. But as some people pointed, maybe a great > > strength of NuttX is to have everything integrated. > > That is a strength of NuttX, and it would be a shame to ruin it for no > technical reason and only because we can't find an acceptable way > to deal with licenses and where to keep code... > > ...which is why I think the "glue code" idea is best for 3rd party code that > we want to integrate. > > With "glue code": > * We do not have to copy 3rd party projects into our repository. > * We do not need external non-Apache-project repositories. > * We do not have to copy 3rd party projects into external non-Apache-project > repositories. > > All we do is develop "glue code" which comprises Kconfig files, Make.defs > files, and possibly patch files. Those would be developed by > us. Those would be part of Apache NuttX. Those would have the Apache license. > We would NOT copy any 3rd party projects into our > repositories. > > When users select those items in Kconfig, our build system will invoke the > "glue code" which will download/clone (if not already > present) the 3rd party project onto the user's machine and build that code as > part of their NuttX build. > > Our glue code could be smart: For example if a 3rd party library is GPL, in > our glue code, it would depend on > "CONFIG_ALLOW_GPL_LICENSE" > or something like that. So the end user will have to decide if GPL is > suitable, and if yes, select to allow it, and then select whatever GPL > 3rd party code they want to have it built and included in their image. > > There is no problem with licensing with this approach. > > There are no hostile forks. > > There is no need to ask permission, SGAs, etc. because we are not copying 3rd > party code into our repositories. > > And you can integrate every FOSS project in the world with NuttX. > > Because: We are only developing glue code and we own the glue code. > > People can choose to activate it if they want to, or not. If they want to, > they accept the licenses of the 3rd party code that they will > download. > So the question is where should we put the "glue code"? 1.Put to apps/external/ directly 2.Put to a new git(e.g. apache-nuttx-external.git) 3.Put to some folders under apps by catalog(e.g. apps/crypto/mbedtls) I prefer item 1 or item 2 personally. > The only concern I can see with this is: What happens if I, as a user of > NuttX, depend on external projects, and those external projects > disappear from the Internet. Well, the answer is that our glue code should > allow you to customize the download/clone location. So, as > a user of NuttX, you can create your own local clone of 3rd party code, so > that if the original disappears from the Internet, you have a > copy. > That becomes the user's responsibility. We don't copy any 3rd party code into > our repositories. > > 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 Apache, that sometimes ASF does allow to mirror well-known FOSS tools. > So we'll have to look at that. > Before ASF host this tools, we have to keep them on https://bitbucket.org/nuttx or https://github.com/nuttx. > Nathan
kconfig (Re: mbedtls)
On Mon, May 25, 2020 at 1:00 AM Nathan Hartman wrote: > > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis > wrote: > > Some months ago I suggested that NuttX could focus only in the kernel > > and we could create an external distribution using some build system > > like buildroot, yocto, etc. But as some people pointed, maybe a great > > strength of NuttX is to have everything integrated. > > That is a strength of NuttX, and it would be a shame to ruin it for no > technical reason and only because we can't find an acceptable way to > deal with licenses and where to keep code... > > ...which is why I think the "glue code" idea is best for 3rd party > code that we want to integrate. > > With "glue code": > * We do not have to copy 3rd party projects into our repository. > * We do not need external non-Apache-project repositories. > * We do not have to copy 3rd party projects into external > non-Apache-project repositories. > > All we do is develop "glue code" which comprises Kconfig files, > Make.defs files, and possibly patch files. Those would be developed by > us. Those would be part of Apache NuttX. Those would have the Apache > license. We would NOT copy any 3rd party projects into our > repositories. > > When users select those items in Kconfig, our build system will invoke > the "glue code" which will download/clone (if not already present) the > 3rd party project onto the user's machine and build that code as part > of their NuttX build. > > Our glue code could be smart: For example if a 3rd party library is > GPL, in our glue code, it would depend on "CONFIG_ALLOW_GPL_LICENSE" > or something like that. So the end user will have to decide if GPL is > suitable, and if yes, select to allow it, and then select whatever GPL > 3rd party code they want to have it built and included in their image. > > There is no problem with licensing with this approach. > > There are no hostile forks. > > There is no need to ask permission, SGAs, etc. because we are not > copying 3rd party code into our repositories. > > And you can integrate every FOSS project in the world with NuttX. > > Because: We are only developing glue code and we own the glue code. > > People can choose to activate it if they want to, or not. If they want > to, they accept the licenses of the 3rd party code that they will > download. > > The only concern I can see with this is: What happens if I, as a user > of NuttX, depend on external projects, and those external projects > disappear from the Internet. Well, the answer is that our glue code > should allow you to customize the download/clone location. So, as a > user of NuttX, you can create your own local clone of 3rd party code, > so that if the original disappears from the Internet, you have a copy. > That becomes the user's responsibility. We don't copy any 3rd party > code into our repositories. > > 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 switch to kconfiglib? > Apache, that sometimes ASF does allow to mirror well-known FOSS tools. > So we'll have to look at that. > > Nathan
Re: mbedtls
On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis wrote: > Some months ago I suggested that NuttX could focus only in the kernel > and we could create an external distribution using some build system > like buildroot, yocto, etc. But as some people pointed, maybe a great > strength of NuttX is to have everything integrated. That is a strength of NuttX, and it would be a shame to ruin it for no technical reason and only because we can't find an acceptable way to deal with licenses and where to keep code... ...which is why I think the "glue code" idea is best for 3rd party code that we want to integrate. With "glue code": * We do not have to copy 3rd party projects into our repository. * We do not need external non-Apache-project repositories. * We do not have to copy 3rd party projects into external non-Apache-project repositories. All we do is develop "glue code" which comprises Kconfig files, Make.defs files, and possibly patch files. Those would be developed by us. Those would be part of Apache NuttX. Those would have the Apache license. We would NOT copy any 3rd party projects into our repositories. When users select those items in Kconfig, our build system will invoke the "glue code" which will download/clone (if not already present) the 3rd party project onto the user's machine and build that code as part of their NuttX build. Our glue code could be smart: For example if a 3rd party library is GPL, in our glue code, it would depend on "CONFIG_ALLOW_GPL_LICENSE" or something like that. So the end user will have to decide if GPL is suitable, and if yes, select to allow it, and then select whatever GPL 3rd party code they want to have it built and included in their image. There is no problem with licensing with this approach. There are no hostile forks. There is no need to ask permission, SGAs, etc. because we are not copying 3rd party code into our repositories. And you can integrate every FOSS project in the world with NuttX. Because: We are only developing glue code and we own the glue code. People can choose to activate it if they want to, or not. If they want to, they accept the licenses of the 3rd party code that they will download. The only concern I can see with this is: What happens if I, as a user of NuttX, depend on external projects, and those external projects disappear from the Internet. Well, the answer is that our glue code should allow you to customize the download/clone location. So, as a user of NuttX, you can create your own local clone of 3rd party code, so that if the original disappears from the Internet, you have a copy. That becomes the user's responsibility. We don't copy any 3rd party code into our repositories. 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 Apache, that sometimes ASF does allow to mirror well-known FOSS tools. So we'll have to look at that. Nathan
Re: mbedtls
I’m concerned that you are discussion doing work outside of the Apache repositories. Why is the main issue here? I think Alan summarized this well. We are already doing work outside of the Apache repositories here: https://bitbucket.org/nuttx/?repo_name=apps-old . We have discussed this many times before. The other repositories have GPL tools that are excluded from the Apache repositories (apps/, and nuttx/ repositories there are mirrors of the Apache repositories for backward compatibility). The discussion is then moving this from Bitbucket to https://github.com/nuttx which has only unmaintained garbage in it now and does not have any suitable project controls to be the authoritative source of anything. Greg mentions that the apache report are not properly controlled and verified but I’m not 100% sure what he means by that. The PMC has control of them and only verified committers have access. If this is just to avoid licensing issues then I suggest that is also not the best way to deal with that and let’s discuss what those issue are and see if there are other ways of resolving them. I am not sure what you mean by the apache report. Typo? Did you mean Apache repositories? No, we are not discussing the Apache repositories at all other than they exclude things needed by an OS like GPL tools and LOTs of 3rd party software. Nothing was said about the apache repositories. That discussion is about the https://github.com/nuttx group of repositories and making those usable for this purpose. I don't believe that there is anything controversial in that. What I did propose that could be controversial is that the PPMC also take control of the https://github.com/nuttx as well to provide some project framework for those other, non-Apache, non-NuttX repositories. Greg
Re: mbedtls
Hi Justin, The point we are discussing is how to integrate external/third-party projects on NuttX apps repository. The licensing it only one of many issues we have. Some months ago I suggested that NuttX could focus only in the kernel and we could create an external distribution using some build system like buildroot, yocto, etc. But as some people pointed, maybe a great strength of NuttX is to have everything integrated. So, I tend to agree with that. Maybe a better approach should be an option where the user select which licenses he/she accepts to use: BSD, MIT, LGPL, GPL, etc, and some disclaimer based on licenses he selected (i.e.: "You selected (L)GPL, then your final firmware cannot be used for commercial application if you don't release the source code"). Then now comes the issue you are talking about: we cannot include all types of software licenses inside the Apache repository. So an alternative is to have a nuttx-apps-external that will have all kind of projects that are not part of native NuttX Applications, but that are very useful for users. Other option is to follow the current path we already do: just put the Makefile with the instructions to download, configure and build the external project. But this solution is very prone to errors: sometimes the original file to be downloaded was moved to other place or removed, then we need to spend time fixing it. Using the nuttx-apps-external repository we will not have these issues because there we will have a copy of each external project. BR, Alan On 5/24/20, Justin Mclean wrote: > Hi, > > I’m concerned that you are discussion doing work outside of the Apache > repositories. Why is the main issue here? > > Greg mentions that the apache report are not properly controlled and > verified but I’m not 100% sure what he means by that. The PMC has control of > them and only verified committers have access. If this is just to avoid > licensing issues then I suggest that is also not the best way to deal with > that and let’s discuss what those issue are and see if there are other ways > of resolving them. > > Thanks, > Justin
Re: mbedtls
Hi, I’m concerned that you are discussion doing work outside of the Apache repositories. Why is the main issue here? Greg mentions that the apache report are not properly controlled and verified but I’m not 100% sure what he means by that. The PMC has control of them and only verified committers have access. If this is just to avoid licensing issues then I suggest that is also not the best way to deal with that and let’s discuss what those issue are and see if there are other ways of resolving them. Thanks, Justin
Re: mbedtls
I propose that we reuse the same process(Apache Way) for github.com/nuttx(e.g. review/merge, select new committer/PMC). The only difference is that github.com/nuttx isn't an Apache project and is an optional component. I think other than the repository location, it can piggyback completely on the Apache project. We don't need a new PMC and we can extend existing web resources to include information about applications. If github.com/apache were properly controlled and verified, as is github/apache, I would not have any issues in moving the remaining bitbuck repositories there either. Greg
RE: mbedtls
> -Original Message- > From: Takashi Yamamoto > Sent: Friday, May 22, 2020 11:18 PM > To: dev@nuttx.apache.org > Subject: Re: mbedtls > > On Fri, May 22, 2020 at 10:14 PM Xiang Xiao wrote: > > > > On Fri, May 22, 2020 at 8:41 PM Alan Carvalho de Assis > > wrote: > > > > > > Hi Xiang, > > > > > > On 5/22/20, Xiang Xiao wrote: > > > sic > > > > > > > > But mbedtls can be used in more context than HTTPS/TLS like > > > > security boot, OTA and TEE, it doesn't make sense to put into > > > > netutils. A central folder(e.g. external) for 3rd party is a > > > > better choice > > > > because: > > > > > > The external folder is used for other purpose (to test user own code). > > > Not it is even in the .gitignore. > > > And since the code will be there already, it is better to keep the > > > way NuttX already to it for external application. > > > > > > > We don't need put Makefile/Kconfig into apps/external directly. Like > > Chao's suggestion, we can create a new apache-nuttx-external git to > > manage the porting. People can link apps/external to > > apache-nuttx-external or their own version. > > i guess a user often want to use apache-nuttx-external AND his own version. > while you can always workaround it with symbolic links, i wonder if it could > be more straightforward to use multiple "external" repos. > NuttX build system can find new Makefile/Kconfig automatically once you add a new folder(not only external) into apps. You can: 1.Extend apache-nuttx-external with the new 3rd party library or 2.Create a new folder for the new 3rd party library and link it from apps > > > > > > 1.New user can find what already provide by NuttX quickly before > > > > start porting > > > > > > Normally new users will look inside menuconfig before looking the > > > code, so it is not an appealing reason. > > > > > > > Even with menuconfig, user need dig into several level to find, e.g.: > > Application Configuration->Grahpics Support->Littlev Graphic > > Libray(LVGL) Considering we have more than 1000 Kconfig options, the > > new user is hard to find the library he/she want from Kconfig quickly. > > > > > > 2.Help PMC check LICENSE file reflect the truth > > > > > > It doesn't better since the code is not distributed inside NuttX. > > > > > > > 3.Follow other project practice > > > > > > > > > > Hmm, so I think I didn't get it correctly from start. Maybe your > > > idea is to keep the complete code inside an apps/external or > > > apps/thirdparty folder, is it? > > > > No, just Makefile/Kconfig, but we need a system way to layout 3rd > > party library if you consider how to find them quickly after we port > > 100+ libraries which very likely happen after one or two years. > > > > > If this is the idea, maybe in this case other option is to have an > > > apps-external or thirdparty repository to avoid the apps/ repository > > > becoming too big with code from external projects. > > > > > > > It's very important to have a common place to share the 3rd party > > library support. Many user select one RTOS just because it support the > > library he/she want to use in box. We need catch up here to compete > > with other RTOS. > > > > > >> > 4. how do you think about adding tls support to netutils/webclient? > > > >> > > > > >> > > > >> I think it is better to create the mbedtls as a separated "library" > > > >> (note the quotes) instead of mixing it directly inside webclient, > > > >> because it could make it easier to users to use mbedtls on their > > > >> web applications. But, of course, it should be nice to have an > > > >> option to compile the webclient with the mbedtls "library" > > > >> support. There are some examples of "libraries" and applications on > > > >> NuttX apps, i.e.: > > > >> gpsutils/minmea/minmea.c and an application using it: examples/gps. > > > >> > > > > > > > > Yes, mbedtls is better to integrate as a library, and then any > > > > builtin or 3rd party apps can utilize it. > > > > > > > > > > I suppose this is the way you did at Xiaomi, right? > > > > > > BR, > > > > > > Alan
RE: mbedtls
> -Original Message- > From: Gregory Nutt > Sent: Saturday, May 23, 2020 2:04 PM > To: dev@nuttx.apache.org > Subject: Re: mbedtls > > > > i guess a user often want to use apache-nuttx-external AND his own version. > > while you can always workaround it with symbolic links, i wonder if it > > could be more straightforward to use multiple "external" repos. > > People have talked about this on and off for some time in various way. There > really needs to be a better decoupling between the > RTOS and the applications that run on top of it. I would think that > incubator-nuttx-apps should be only an application framework with > highly integrated apps (like NSH) and that ALL other applications reside > elsewhere. > Yes, apps is suitable for the code write from scratch for NuttX or the project stop the active development. But since Apache Foundation has more strict license requirement which mean that the owner of 3rd party code need sign SGA: https://www.apache.org/licenses/contributor-agreements.html#grants So if you want to put the source code into apps git, you need: 1.The library is Apache license 2.The library isn't in the active development 3.The owner sign Software Grant Agreement 4.Pass nxstyle check > Taking this to the next step, this could involve some external repositories > containing a variety of applications, original NuttX > applications and 3rd party applications, along with some configuration tool > to setup a NuttX userland. People, particularly Alan, has > often advocated this as a "NuttX distro". However, I think the term distro > alienates people. Let's just say repositories outside of > Apache that integrate applications intothe incubator-nuttx-apps application > framework. > > There is a good spot at github.com/nuttx, but that is not currently in-use. > It is currently just a free-for-all and not suitable for any Yes, github.com/nuttx is a good location to mitigate the above constraint. > critical software development. But I think we could tighten up the security > there, add some automated testing, and create some kind > of project structure to protect and maintain the repositories. > > Ultimately, you are talking about another non-Apache project. That project > would need some organization and support. > I propose that we reuse the same process(Apache Way) for github.com/nuttx(e.g. review/merge, select new committer/PMC). The only difference is that github.com/nuttx isn't an Apache project and is an optional component. >
Re: mbedtls
On Fri, May 22, 2020 at 9:18 AM Alan Carvalho de Assis wrote: > Hi Daniel, > > Yes, I think an option is to create an apps/thirdparty folder to > follow with Xiang idea. I like the idea of glue code. There are many libraries out there which people may want to use with NuttX, and we can't/shouldn't fork them all and stick them in our codebase. Not only would that be a problem for Apache (because Apache doesn't make "hostile forks" and licensing) but from a technical/management point it creates a bigger maintenance burden on us to manually track upstream and bring updates into NuttX. It is better to work with upstream libraries as-is, and make only the custom glue code that consists of Kconfig, Make.defs, etc. The glue code will belong to us and will be Apache licensed. The 3rd party library stays separate and is not in our repository. Only if the user activates a 3rd party library, the glue code will (1) download or clone it, if needed, and (2) integrate it into the NuttX build system. If a port to NuttX requires patching the 3rd party code, whoever does the porting should upstream the changes back to the 3rd party project. If the 3rd party project doesn't accept the changes, the patch can be part of our glue code. In any case, we will only need to maintain the glue, not the whole project, and the glue will be Apache licensed so we aren't stepping on anyone's toes. I think it's a good general solution for integrating 3rd party code. I think glue code will even allow to make GNU licensed 3rd party code integrations, because the glue code is ours, and the GNU code is not downloaded or used unless the user specifically wants it. One more thing: I think the glue code should provide a way to customize the download location of the 3rd party code. So if a NuttX user is worried that the 3rd party code will disappear from the Internet, or if they want to customize the 3rd party code, they can keep their own local clone and provide that link to Kconfig. > Cheers, Nathan
Re: mbedtls
i guess a user often want to use apache-nuttx-external AND his own version. while you can always workaround it with symbolic links, i wonder if it could be more straightforward to use multiple "external" repos. People have talked about this on and off for some time in various way. There really needs to be a better decoupling between the RTOS and the applications that run on top of it. I would think that incubator-nuttx-apps should be only an application framework with highly integrated apps (like NSH) and that ALL other applications reside elsewhere. Taking this to the next step, this could involve some external repositories containing a variety of applications, original NuttX applications and 3rd party applications, along with some configuration tool to setup a NuttX userland. People, particularly Alan, has often advocated this as a "NuttX distro". However, I think the term distro alienates people. Let's just say repositories outside of Apache that integrate applications intothe incubator-nuttx-apps application framework. There is a good spot at github.com/nuttx, but that is not currently in-use. It is currently just a free-for-all and not suitable for any critical software development. But I think we could tighten up the security there, add some automated testing, and create some kind of project structure to protect and maintain the repositories. Ultimately, you are talking about another non-Apache project. That project would need some organization and support.
Re: mbedtls
On Fri, May 22, 2020 at 10:14 PM Xiang Xiao wrote: > > On Fri, May 22, 2020 at 8:41 PM Alan Carvalho de Assis > wrote: > > > > Hi Xiang, > > > > On 5/22/20, Xiang Xiao wrote: > > sic > > > > > > But mbedtls can be used in more context than HTTPS/TLS like security > > > boot, OTA and TEE, it doesn't make sense to put into netutils. A > > > central folder(e.g. external) for 3rd party is a better choice > > > because: > > > > The external folder is used for other purpose (to test user own code). > > Not it is even in the .gitignore. > > And since the code will be there already, it is better to keep the way > > NuttX already to it for external application. > > > > We don't need put Makefile/Kconfig into apps/external directly. Like > Chao's suggestion, we can create a new apache-nuttx-external git to > manage the porting. People can link apps/external to > apache-nuttx-external or their own version. i guess a user often want to use apache-nuttx-external AND his own version. while you can always workaround it with symbolic links, i wonder if it could be more straightforward to use multiple "external" repos. > > > > 1.New user can find what already provide by NuttX quickly before start > > > porting > > > > Normally new users will look inside menuconfig before looking the > > code, so it is not an appealing reason. > > > > Even with menuconfig, user need dig into several level to find, e.g.: > Application Configuration->Grahpics Support->Littlev Graphic Libray(LVGL) > Considering we have more than 1000 Kconfig options, the new user is > hard to find the library he/she want from Kconfig quickly. > > > > 2.Help PMC check LICENSE file reflect the truth > > > > It doesn't better since the code is not distributed inside NuttX. > > > > > 3.Follow other project practice > > > > > > > Hmm, so I think I didn't get it correctly from start. Maybe your idea > > is to keep the complete code inside an apps/external or > > apps/thirdparty folder, is it? > > No, just Makefile/Kconfig, but we need a system way to layout 3rd > party library if you consider how to find them quickly after we port > 100+ libraries which very likely happen after one or two years. > > > If this is the idea, maybe in this case other option is to have an > > apps-external or thirdparty repository to avoid the apps/ repository > > becoming too big with code from external projects. > > > > It's very important to have a common place to share the 3rd party > library support. Many user select one RTOS just because it support the > library he/she want to use in box. We need catch up here to compete > with other RTOS. > > > >> > 4. how do you think about adding tls support to netutils/webclient? > > >> > > > >> > > >> I think it is better to create the mbedtls as a separated "library" > > >> (note the quotes) instead of mixing it directly inside webclient, > > >> because it could make it easier to users to use mbedtls on their web > > >> applications. But, of course, it should be nice to have an option to > > >> compile the webclient with the mbedtls "library" support. There are > > >> some examples of "libraries" and applications on NuttX apps, i.e.: > > >> gpsutils/minmea/minmea.c and an application using it: examples/gps. > > >> > > > > > > Yes, mbedtls is better to integrate as a library, and then any builtin > > > or 3rd party apps can utilize it. > > > > > > > I suppose this is the way you did at Xiaomi, right? > > > > BR, > > > > Alan
crypto api again (was: Re: mbedtls)
Le 22/05/2020 à 17:00, Takashi Yamamoto a écrit : On Fri, May 22, 2020 at 7:26 PM Sebastien Lorquet wrote: Hello Le 22/05/2020 à 10:05, Takashi Yamamoto a écrit : can you explain what's "real nuttx code"? For me, code specifically written for NuttX with good integration and performance. Different from a third-party library. i'm afraid that a third-party library is likely a better choice for things like tls. Probably not, my company is already working in the domain of security and we will have some testing to ensure things work. Yes I know it's bad to roll your own crypto but it's not rolling crypto, it's rolling known algorithms, so these can be tested and fixed. To finish with, the security envelope of a normal IoT SoC is pretty bad so already. If you get physical access you can put break points at the right places and do whatever you want. So the goal is more compactness and integration. We will not be as comprehensive as mbedtls probably, but we will do it well for sure. The customer that ordered it is a large french company that does not sh*t on security. Domain is industrial, not iot/startup/customer. Moreover mbedtls comes with a full crypto lib which will be duplicated if something else in the system requires cryptography, and these lib wont take advantage of any crypto hardware that might be available in a particular SoC. Using a backend crypto library improves modularity. The makefile glue is OK for NuttX contribution. Crypto is a directory that exists in some personal forks of NuttX and is (IIRC) used by Xiaomi with probably many changes, but it is not integrated yet. (your remark made me believe it had been already) It is intended to provide a PKCS#11 like library that any app can use and any board can extend with new algs, including hardware implemented. If you are interested in a crypto API we can talk about that and discuss what is already done and designed, no need to fully reinvent anything. i'm interested. It's here: https://bitbucket.org/slorquet/nuttx/src/crypto/crypto/ Still a legacy nuttx, not migrated to apache stuff yet. You can see the suggested API here. it's based on IOCTL and chardevs https://bitbucket.org/slorquet/nuttx/src/crypto/include/nuttx/crypto/ioctl.h constant definitions https://bitbucket.org/slorquet/nuttx/src/crypto/include/nuttx/crypto/manager.h "OS side" crypto module operations (kind of service provider API) https://bitbucket.org/slorquet/nuttx/src/crypto/include/nuttx/crypto/module.h chardev interface https://bitbucket.org/slorquet/nuttx/src/crypto/crypto/manager.c Implementation of module manager https://bitbucket.org/slorquet/nuttx/src/crypto/crypto/libmanager.c Module designed to test the behaviour https://bitbucket.org/slorquet/nuttx/src/crypto/crypto/softmodule.c cryptoapps is a repo that can be cloned in a working APPS repository. new folder is automatically detected by the build system, this is what you can do for mbedtls porting. https://bitbucket.org/slorquet/cryptoapps/src/master/ user-side of the API that calls the chardev: https://bitbucket.org/slorquet/cryptoapps/src/master/libcrypto/ openssl-like test tool used during development https://bitbucket.org/slorquet/cryptoapps/src/master/ct/ export should be linked as crypto in apps/include to provide headers to other apps. It is extensively documented with comments. The great question was : how to make this API available to user space? My initial development was based on a character device because it was very simple and had probably the less impact on performance. I know that gregory would prefer something else, possibly a kind of socket like netlink. I think it's bloat to require the network stack for simple straightforward stuff like this, and situation was left on this lack of solution the last time I remember. I dont know how things are now. is the char device still unacceptable? is netlink the preferred solution? Is something else possible? I dont know. Sebastien
Re: mbedtls
On Fri, May 22, 2020 at 7:26 PM Sebastien Lorquet wrote: > > Hello > > Le 22/05/2020 à 10:05, Takashi Yamamoto a écrit : > > can you explain what's "real nuttx code"? > > For me, code specifically written for NuttX with good integration and > performance. Different from a third-party library. i'm afraid that a third-party library is likely a better choice for things like tls. > > The makefile glue is OK for NuttX contribution. > > Crypto is a directory that exists in some personal forks of NuttX and is > (IIRC) used by Xiaomi with probably many changes, but it is not > integrated yet. (your remark made me believe it had been already) > > It is intended to provide a PKCS#11 like library that any app can use > and any board can extend with new algs, including hardware implemented. > > If you are interested in a crypto API we can talk about that and discuss > what is already done and designed, no need to fully reinvent anything. i'm interested. > > Sebastien >
Re: mbedtls
Hi Daniel, Yes, I think an option is to create an apps/thirdparty folder to follow with Xiang idea. BR, Alan On 5/22/20, Daniel Pereira Carvalho wrote: > What about a new 3rd party folder? > > Em sex, 22 de mai de 2020 09:41, Alan Carvalho de Assis > escreveu: > >> Hi Xiang, >> >> On 5/22/20, Xiang Xiao wrote: >> sic >> > >> > But mbedtls can be used in more context than HTTPS/TLS like security >> > boot, OTA and TEE, it doesn't make sense to put into netutils. A >> > central folder(e.g. external) for 3rd party is a better choice >> > because: >> >> The external folder is used for other purpose (to test user own code). >> Not it is even in the .gitignore. >> And since the code will be there already, it is better to keep the way >> NuttX already to it for external application. >> >> > 1.New user can find what already provide by NuttX quickly before start >> > porting >> >> Normally new users will look inside menuconfig before looking the >> code, so it is not an appealing reason. >> >> > 2.Help PMC check LICENSE file reflect the truth >> >> It doesn't better since the code is not distributed inside NuttX. >> >> > 3.Follow other project practice >> > >> >> Hmm, so I think I didn't get it correctly from start. Maybe your idea >> is to keep the complete code inside an apps/external or >> apps/thirdparty folder, is it? >> If this is the idea, maybe in this case other option is to have an >> apps-external or thirdparty repository to avoid the apps/ repository >> becoming too big with code from external projects. >> >> >> > 4. how do you think about adding tls support to netutils/webclient? >> >> > >> >> >> >> I think it is better to create the mbedtls as a separated "library" >> >> (note the quotes) instead of mixing it directly inside webclient, >> >> because it could make it easier to users to use mbedtls on their web >> >> applications. But, of course, it should be nice to have an option to >> >> compile the webclient with the mbedtls "library" support. There are >> >> some examples of "libraries" and applications on NuttX apps, i.e.: >> >> gpsutils/minmea/minmea.c and an application using it: examples/gps. >> >> >> > >> > Yes, mbedtls is better to integrate as a library, and then any builtin >> > or 3rd party apps can utilize it. >> > >> >> I suppose this is the way you did at Xiaomi, right? >> >> BR, >> >> Alan >> >
Re: mbedtls
On Fri, May 22, 2020 at 8:41 PM Alan Carvalho de Assis wrote: > > Hi Xiang, > > On 5/22/20, Xiang Xiao wrote: > sic > > > > But mbedtls can be used in more context than HTTPS/TLS like security > > boot, OTA and TEE, it doesn't make sense to put into netutils. A > > central folder(e.g. external) for 3rd party is a better choice > > because: > > The external folder is used for other purpose (to test user own code). > Not it is even in the .gitignore. > And since the code will be there already, it is better to keep the way > NuttX already to it for external application. > We don't need put Makefile/Kconfig into apps/external directly. Like Chao's suggestion, we can create a new apache-nuttx-external git to manage the porting. People can link apps/external to apache-nuttx-external or their own version. > > 1.New user can find what already provide by NuttX quickly before start > > porting > > Normally new users will look inside menuconfig before looking the > code, so it is not an appealing reason. > Even with menuconfig, user need dig into several level to find, e.g.: Application Configuration->Grahpics Support->Littlev Graphic Libray(LVGL) Considering we have more than 1000 Kconfig options, the new user is hard to find the library he/she want from Kconfig quickly. > > 2.Help PMC check LICENSE file reflect the truth > > It doesn't better since the code is not distributed inside NuttX. > > > 3.Follow other project practice > > > > Hmm, so I think I didn't get it correctly from start. Maybe your idea > is to keep the complete code inside an apps/external or > apps/thirdparty folder, is it? No, just Makefile/Kconfig, but we need a system way to layout 3rd party library if you consider how to find them quickly after we port 100+ libraries which very likely happen after one or two years. > If this is the idea, maybe in this case other option is to have an > apps-external or thirdparty repository to avoid the apps/ repository > becoming too big with code from external projects. > It's very important to have a common place to share the 3rd party library support. Many user select one RTOS just because it support the library he/she want to use in box. We need catch up here to compete with other RTOS. > >> > 4. how do you think about adding tls support to netutils/webclient? > >> > > >> > >> I think it is better to create the mbedtls as a separated "library" > >> (note the quotes) instead of mixing it directly inside webclient, > >> because it could make it easier to users to use mbedtls on their web > >> applications. But, of course, it should be nice to have an option to > >> compile the webclient with the mbedtls "library" support. There are > >> some examples of "libraries" and applications on NuttX apps, i.e.: > >> gpsutils/minmea/minmea.c and an application using it: examples/gps. > >> > > > > Yes, mbedtls is better to integrate as a library, and then any builtin > > or 3rd party apps can utilize it. > > > > I suppose this is the way you did at Xiaomi, right? > > BR, > > Alan
Re: mbedtls
Hi Greg, On 5/22/20, Gregory Nutt wrote: > >>> 2. if yes, which repository is appropriate? apps? >> Yes, apps of course. >> >>> 3. if apps, in which directory? netutils? crypto? >> Although crypto could be an option (but it doesn't exist inside apps/ >> yet), I think netutils/ is a better option. > > I think we should use a new apps/crypto. There will be other userspace > crypto support in the future, I am sure. Perhaps, Intel's TinyCrypt > cryptographic library, for example. I don't think it all belows under > netutils, does it? > Yes, I was only focusing on mbedtls for HTTPS application, but as Xiang pointed it coud be used for other applications. So yes, it is better to be inside apps/crypto. BR, Alan
Re: mbedtls
What about a new 3rd party folder? Em sex, 22 de mai de 2020 09:41, Alan Carvalho de Assis escreveu: > Hi Xiang, > > On 5/22/20, Xiang Xiao wrote: > sic > > > > But mbedtls can be used in more context than HTTPS/TLS like security > > boot, OTA and TEE, it doesn't make sense to put into netutils. A > > central folder(e.g. external) for 3rd party is a better choice > > because: > > The external folder is used for other purpose (to test user own code). > Not it is even in the .gitignore. > And since the code will be there already, it is better to keep the way > NuttX already to it for external application. > > > 1.New user can find what already provide by NuttX quickly before start > > porting > > Normally new users will look inside menuconfig before looking the > code, so it is not an appealing reason. > > > 2.Help PMC check LICENSE file reflect the truth > > It doesn't better since the code is not distributed inside NuttX. > > > 3.Follow other project practice > > > > Hmm, so I think I didn't get it correctly from start. Maybe your idea > is to keep the complete code inside an apps/external or > apps/thirdparty folder, is it? > If this is the idea, maybe in this case other option is to have an > apps-external or thirdparty repository to avoid the apps/ repository > becoming too big with code from external projects. > > >> > 4. how do you think about adding tls support to netutils/webclient? > >> > > >> > >> I think it is better to create the mbedtls as a separated "library" > >> (note the quotes) instead of mixing it directly inside webclient, > >> because it could make it easier to users to use mbedtls on their web > >> applications. But, of course, it should be nice to have an option to > >> compile the webclient with the mbedtls "library" support. There are > >> some examples of "libraries" and applications on NuttX apps, i.e.: > >> gpsutils/minmea/minmea.c and an application using it: examples/gps. > >> > > > > Yes, mbedtls is better to integrate as a library, and then any builtin > > or 3rd party apps can utilize it. > > > > I suppose this is the way you did at Xiaomi, right? > > BR, > > Alan >
Re: mbedtls
Hi Xiang, On 5/22/20, Xiang Xiao wrote: sic > > But mbedtls can be used in more context than HTTPS/TLS like security > boot, OTA and TEE, it doesn't make sense to put into netutils. A > central folder(e.g. external) for 3rd party is a better choice > because: The external folder is used for other purpose (to test user own code). Not it is even in the .gitignore. And since the code will be there already, it is better to keep the way NuttX already to it for external application. > 1.New user can find what already provide by NuttX quickly before start > porting Normally new users will look inside menuconfig before looking the code, so it is not an appealing reason. > 2.Help PMC check LICENSE file reflect the truth It doesn't better since the code is not distributed inside NuttX. > 3.Follow other project practice > Hmm, so I think I didn't get it correctly from start. Maybe your idea is to keep the complete code inside an apps/external or apps/thirdparty folder, is it? If this is the idea, maybe in this case other option is to have an apps-external or thirdparty repository to avoid the apps/ repository becoming too big with code from external projects. >> > 4. how do you think about adding tls support to netutils/webclient? >> > >> >> I think it is better to create the mbedtls as a separated "library" >> (note the quotes) instead of mixing it directly inside webclient, >> because it could make it easier to users to use mbedtls on their web >> applications. But, of course, it should be nice to have an option to >> compile the webclient with the mbedtls "library" support. There are >> some examples of "libraries" and applications on NuttX apps, i.e.: >> gpsutils/minmea/minmea.c and an application using it: examples/gps. >> > > Yes, mbedtls is better to integrate as a library, and then any builtin > or 3rd party apps can utilize it. > I suppose this is the way you did at Xiaomi, right? BR, Alan
Re: mbedtls
On Fri, May 22, 2020 at 7:51 PM Alan Carvalho de Assis wrote: > > Hi Takashi-san, > > On 5/22/20, Takashi Yamamoto wrote: > > hi, > > > > i'm working on mbedtls Makefile/Kconfig glue for NuttX. > > right now, it downloads and uses the mbedtls source code from > > the upstream as it is. (similarly to what netutils/cjson does) > > > > questions: > > > > 1. if we decide to contribute it, is there a chance to be accepted by > > NuttX? > > Yes, mbedtls should be a great contribution. > Many users want to use NuttX with HTTPS/TLS support and will spend > time doing this port themselves. > > > 2. if yes, which repository is appropriate? apps? > > Yes, apps of course. > > > 3. if apps, in which directory? netutils? crypto? > > Although crypto could be an option (but it doesn't exist inside apps/ > yet), I think netutils/ is a better option. > But mbedtls can be used in more context than HTTPS/TLS like security boot, OTA and TEE, it doesn't make sense to put into netutils. A central folder(e.g. external) for 3rd party is a better choice because: 1.New user can find what already provide by NuttX quickly before start porting 2.Help PMC check LICENSE file reflect the truth 3.Follow other project practice > > 4. how do you think about adding tls support to netutils/webclient? > > > > I think it is better to create the mbedtls as a separated "library" > (note the quotes) instead of mixing it directly inside webclient, > because it could make it easier to users to use mbedtls on their web > applications. But, of course, it should be nice to have an option to > compile the webclient with the mbedtls "library" support. There are > some examples of "libraries" and applications on NuttX apps, i.e.: > gpsutils/minmea/minmea.c and an application using it: examples/gps. > Yes, mbedtls is better to integrate as a library, and then any builtin or 3rd party apps can utilize it. > BR, > > Alan
Re: mbedtls
BTW, Xiaomi already port many 3rd party library(include mbedtls) and can share the result to community to avoid the duplicated work. On Fri, May 22, 2020 at 7:51 PM Alan Carvalho de Assis wrote: > > Hi Takashi-san, > > On 5/22/20, Takashi Yamamoto wrote: > > hi, > > > > i'm working on mbedtls Makefile/Kconfig glue for NuttX. > > right now, it downloads and uses the mbedtls source code from > > the upstream as it is. (similarly to what netutils/cjson does) > > > > questions: > > > > 1. if we decide to contribute it, is there a chance to be accepted by > > NuttX? > > Yes, mbedtls should be a great contribution. > Many users want to use NuttX with HTTPS/TLS support and will spend > time doing this port themselves. > > > 2. if yes, which repository is appropriate? apps? > > Yes, apps of course. > > > 3. if apps, in which directory? netutils? crypto? > > Although crypto could be an option (but it doesn't exist inside apps/ > yet), I think netutils/ is a better option. > > > 4. how do you think about adding tls support to netutils/webclient? > > > > I think it is better to create the mbedtls as a separated "library" > (note the quotes) instead of mixing it directly inside webclient, > because it could make it easier to users to use mbedtls on their web > applications. But, of course, it should be nice to have an option to > compile the webclient with the mbedtls "library" support. There are > some examples of "libraries" and applications on NuttX apps, i.e.: > gpsutils/minmea/minmea.c and an application using it: examples/gps. > > BR, > > Alan
Re: mbedtls
Hi Takashi-san, On 5/22/20, Takashi Yamamoto wrote: > hi, > > i'm working on mbedtls Makefile/Kconfig glue for NuttX. > right now, it downloads and uses the mbedtls source code from > the upstream as it is. (similarly to what netutils/cjson does) > > questions: > > 1. if we decide to contribute it, is there a chance to be accepted by > NuttX? Yes, mbedtls should be a great contribution. Many users want to use NuttX with HTTPS/TLS support and will spend time doing this port themselves. > 2. if yes, which repository is appropriate? apps? Yes, apps of course. > 3. if apps, in which directory? netutils? crypto? Although crypto could be an option (but it doesn't exist inside apps/ yet), I think netutils/ is a better option. > 4. how do you think about adding tls support to netutils/webclient? > I think it is better to create the mbedtls as a separated "library" (note the quotes) instead of mixing it directly inside webclient, because it could make it easier to users to use mbedtls on their web applications. But, of course, it should be nice to have an option to compile the webclient with the mbedtls "library" support. There are some examples of "libraries" and applications on NuttX apps, i.e.: gpsutils/minmea/minmea.c and an application using it: examples/gps. BR, Alan
Re: mbedtls
Hello Le 22/05/2020 à 10:05, Takashi Yamamoto a écrit : can you explain what's "real nuttx code"? For me, code specifically written for NuttX with good integration and performance. Different from a third-party library. The makefile glue is OK for NuttX contribution. Crypto is a directory that exists in some personal forks of NuttX and is (IIRC) used by Xiaomi with probably many changes, but it is not integrated yet. (your remark made me believe it had been already) It is intended to provide a PKCS#11 like library that any app can use and any board can extend with new algs, including hardware implemented. If you are interested in a crypto API we can talk about that and discuss what is already done and designed, no need to fully reinvent anything. Sebastien
Re: mbedtls
On Fri, May 22, 2020 at 4:12 PM Takashi Yamamoto wrote: > > On Fri, May 22, 2020 at 4:52 PM Sebastien Lorquet > wrote: > > > > Hello, > > > > I have seriously slowed down my nuttx contributions because of the > > apache turmoil but I am still reading this list and will have to work on > > this topic at one point. > > Yes, the transition phase make chaos, but the first Apache NuttX official release(9.0.0) annaunce at May 15th: https://lists.apache.org/thread.html/rf7678c2a47c71ba9acb2c4a5392cea75d936a44f32d49f4f287b4aa9%40%3Cdev.nuttx.apache.org%3E So it's time to come back and try/improve the Apache workflow. > > See my opinions below. > > > > Sebastien > > > > Le 22/05/2020 à 09:41, Takashi Yamamoto a écrit : > > > hi, > > > > > > i'm working on mbedtls Makefile/Kconfig glue for NuttX. > > > right now, it downloads and uses the mbedtls source code from > > > the upstream as it is. (similarly to what netutils/cjson does) > > > > > > questions: > > > > > > 1. if we decide to contribute it, is there a chance to be accepted by > > > NuttX? > > No. NuttX does not include alive projects. > > i'm not suggesting to include the whole mbedtls code in nuttx repo. > just a Makefile/Kconfig glue. > Yes, the download may be the only method to support the 3rd party code after we join Apache Foundation even the package has the compatible license or stop the active development since Apache Foundation has the more strict license requirement. > > > 2. if yes, which repository is appropriate? apps? > > > > HTTPS implementation should be a lib in apps that uses a common TLS > > socket library. which should be replaceable. > > > > At first, make it use mbedts, or other, then later, have this replaced > > by real nuttx code. > > can you explain what's "real nuttx code"? > > > > > > 3. if apps, in which directory? netutils? crypto? > > > > Crypto is a crypto framework for basic crypto operations. I didnt know > > that it had been upstreamed. > > > > Yes, this folder could provide resources for a tls implementation. It is > > intended to be a modular crypto framework like a compact pkcs#11. > > by "crypto", i meant a new directory. > i guess you are talking about some project i'm not aware of, > which happens to use the same directory name. right? > How about we put all 3rd party library to external folder like Android or TizenRT: https://android.googlesource.com/platform/external/ https://github.com/Samsung/TizenRT/tree/master/external This approach make we can identify the 3rd party code and license more quickly. > > > > > 4. how do you think about adding tls support to netutils/webclient? > > > > Please make the TLS implementation replaceable. At one point NuttX will > > get a built it TLS. > > > > A customer has formally ordered this feature so I will be paid to > > develop it, but my schedule is loaded and I dont know when I will > > complete this. > > > > I understand that no one can wait for this to happen before having TLS, > > so mbedTLS is a good temporary option. > > > > But please anyone integrating TLS in NuttX, please provide options and > > hooks to replace the implementation. > > > > I believe the interface should be a user lib that provides TLS sockets > > as in openssl or gnutls. > > do you mean openssl BIO and mbedtls mbedtls_ssl_read/mbedtls_ssl_write/etc? > (i don't know gnutls api) > > > > > It looks like a low-level interface with known semantics that could be > > started with a downloaded mbedtls and then easily replaced with a native > > nuttx solution based on what is in the crypto folder. > > > > Sebastien > > > >
Re: mbedtls
On Fri, May 22, 2020 at 4:52 PM Sebastien Lorquet wrote: > > Hello, > > I have seriously slowed down my nuttx contributions because of the > apache turmoil but I am still reading this list and will have to work on > this topic at one point. > > See my opinions below. > > Sebastien > > Le 22/05/2020 à 09:41, Takashi Yamamoto a écrit : > > hi, > > > > i'm working on mbedtls Makefile/Kconfig glue for NuttX. > > right now, it downloads and uses the mbedtls source code from > > the upstream as it is. (similarly to what netutils/cjson does) > > > > questions: > > > > 1. if we decide to contribute it, is there a chance to be accepted by NuttX? > No. NuttX does not include alive projects. i'm not suggesting to include the whole mbedtls code in nuttx repo. just a Makefile/Kconfig glue. > > 2. if yes, which repository is appropriate? apps? > > HTTPS implementation should be a lib in apps that uses a common TLS > socket library. which should be replaceable. > > At first, make it use mbedts, or other, then later, have this replaced > by real nuttx code. can you explain what's "real nuttx code"? > > > 3. if apps, in which directory? netutils? crypto? > > Crypto is a crypto framework for basic crypto operations. I didnt know > that it had been upstreamed. > > Yes, this folder could provide resources for a tls implementation. It is > intended to be a modular crypto framework like a compact pkcs#11. by "crypto", i meant a new directory. i guess you are talking about some project i'm not aware of, which happens to use the same directory name. right? > > > 4. how do you think about adding tls support to netutils/webclient? > > Please make the TLS implementation replaceable. At one point NuttX will > get a built it TLS. > > A customer has formally ordered this feature so I will be paid to > develop it, but my schedule is loaded and I dont know when I will > complete this. > > I understand that no one can wait for this to happen before having TLS, > so mbedTLS is a good temporary option. > > But please anyone integrating TLS in NuttX, please provide options and > hooks to replace the implementation. > > I believe the interface should be a user lib that provides TLS sockets > as in openssl or gnutls. do you mean openssl BIO and mbedtls mbedtls_ssl_read/mbedtls_ssl_write/etc? (i don't know gnutls api) > > It looks like a low-level interface with known semantics that could be > started with a downloaded mbedtls and then easily replaced with a native > nuttx solution based on what is in the crypto folder. > > Sebastien > >
Re: mbedtls
Hello, I have seriously slowed down my nuttx contributions because of the apache turmoil but I am still reading this list and will have to work on this topic at one point. See my opinions below. Sebastien Le 22/05/2020 à 09:41, Takashi Yamamoto a écrit : hi, i'm working on mbedtls Makefile/Kconfig glue for NuttX. right now, it downloads and uses the mbedtls source code from the upstream as it is. (similarly to what netutils/cjson does) questions: 1. if we decide to contribute it, is there a chance to be accepted by NuttX? No. NuttX does not include alive projects. 2. if yes, which repository is appropriate? apps? HTTPS implementation should be a lib in apps that uses a common TLS socket library. which should be replaceable. At first, make it use mbedts, or other, then later, have this replaced by real nuttx code. 3. if apps, in which directory? netutils? crypto? Crypto is a crypto framework for basic crypto operations. I didnt know that it had been upstreamed. Yes, this folder could provide resources for a tls implementation. It is intended to be a modular crypto framework like a compact pkcs#11. 4. how do you think about adding tls support to netutils/webclient? Please make the TLS implementation replaceable. At one point NuttX will get a built it TLS. A customer has formally ordered this feature so I will be paid to develop it, but my schedule is loaded and I dont know when I will complete this. I understand that no one can wait for this to happen before having TLS, so mbedTLS is a good temporary option. But please anyone integrating TLS in NuttX, please provide options and hooks to replace the implementation. I believe the interface should be a user lib that provides TLS sockets as in openssl or gnutls. It looks like a low-level interface with known semantics that could be started with a downloaded mbedtls and then easily replaced with a native nuttx solution based on what is in the crypto folder. Sebastien
