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
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
