events.nuttx.apache.org

[Takashi Yamamoto]

- the email address works...@nuttx.org mentioned on
https://events.nuttx.apache.org/ seems dead.

- i wonder if the online attendance registration on the page is working.
  i think i registered myself a few days ago. but i have not noticed
"event notifications and links for the event" in my inbox.

Re: stack issue when using littlefs (was Re: littlefs broken)

[Takashi Yamamoto]

On Tue, Mar 19, 2024 at 8:01 PM Sebastien Lorquet  wrote:
>
> Damn, that was a stack issue, but not in littlefs itself. or is it? idk.
>
>
> This is a useful "bug" to know: Littlefs uses A LOT of stack.
>
> The issue was nsh. it is configured with a 2048 bytes stack by default,
> and increasing it to 8192 did nothing, which lead me to a deep rabbit
> hole at 1 am yesterday, and critiques that were not required this time.
>
>
> However as in X-files, the truth was elsewhere.
>
> The boot task stack size is configured by CONFIG_INIT_STACKSIZE and not
> by CONFIG_NSH_STACKSIZE
>
> Good to know...
>
> But this works on sim:nsh (I checked) so this problem cannot be detected
> in CI.
>
> NuttX is fine this time, except the discrepancy of littlefs version
> between cmake and make remains.
>
> Could the default stack size of tasks be customized per architecture in
> kconfig files? here 2048 was ok for the sim (x86_64) but not for a stm32f4

FYI, sim doesn't really honor the user specified stack size.
grep SIM_STACKSIZE_ADJUSTMENT if you are interested.

>
> Thanks for pointing me to the sim.
>
> Sebastien
>
>
> Le 19/03/2024 à 07:50, Sebastien Lorquet a écrit :
> > hi Tomek
> >
> > I'll have a try and report.
> >
> > Sebastien
> >
> > On 3/19/24 01:36, Tomek CEDRO wrote:
> >> Hey there Sebastien!
> >>
> >> Sorry to hear that :-(
> >>
> >> Would it be possible to try those tests in SIM ?
> >>
> >> If yes are results the same?
> >>
> >> This could be included into CI tests with a SIM if that helps..?
> >>
> >> --
> >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: bl808 status?

[Takashi Yamamoto]

ok. thank you for the info.
hopefully i will have some time to spend on these boards next month.

On Thu, Mar 9, 2023 at 2:22 AM Brennan Ashton  wrote:
>
> I do have a lot of changes in a local branch, but have not had much time to
> focus on this. The early stage bring up is not well documented and fairly
> challenging.  You can find my notes here as well.
>
> https://btashton.github.io/bl808-notes/
>
> If you would like to collaborate on this that would be awesome!
>
> --Brennan
>
> On Wed, Mar 8, 2023, 8:48 AM Takashi Yamamoto 
> wrote:
>
> > hi,
> >
> > i recently received a few small boxes labelled "Sipeed M1S Dock"
> > and i'm interested in nuttx support of the board.
> > google suggested me Brennan's wip tree.
> > https://github.com/btashton/incubator-nuttx/tree/bl808/bringup
> > Brennan, is it the latest? or do you have any unpushed changes?
> >

bl808 status?

[Takashi Yamamoto]

hi,

i recently received a few small boxes labelled "Sipeed M1S Dock"
and i'm interested in nuttx support of the board.
google suggested me Brennan's wip tree.
https://github.com/btashton/incubator-nuttx/tree/bl808/bringup
Brennan, is it the latest? or do you have any unpushed changes?

recent WASM build stuff

[Takashi Yamamoto]

hi,

let me repeat my concerns about the recent addition of WASM module
build support here
as i think it warrants a ML discussion.
https://github.com/apache/nuttx-apps/pull/1609#issuecomment-1460411089

honestly speaking, i feel the feature is halfly-baked at best. maybe
it's a misfeature.

* i feel that building wasm modules is not a job of nuttx-apps unless
it involves something very nuttx-specific. is there something like
that planned? what's that?
* CONFIG_BENCHMARK_COREMARK=y enables both of wasm module build and
nuttx-native build of the app. i guess they should be controllable
independently.
* it's awkward to prefer wamr-specific libc implementation over
wasi-libc. especially when you use wasi-sdk.

Re: [VOTE] Apache NuttX 12.0.0 RC0 release

[Takashi Yamamoto]

i guess we need to make a decision about time_t signedness.

references:
https://github.com/apache/nuttx/pull/4693
https://github.com/apache/nuttx/pull/7115
https://github.com/apache/nuttx/pull/7975

On Mon, Dec 19, 2022 at 4:22 PM Alin Jerpelea  wrote:
>
> Hello all,
> Apache NuttX 12.0.0 RC0 has been staged under [1] and it's
> time to vote on accepting it for release.
> Voting will be open for 72hr.
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1 are
> required to pass.
>
> The Apache requirements for approving a release can be found here [3]
> "Before voting +1 [P]PMC members are required to download the signed
> source code package, compile it as provided, and test the resulting
> executable on their own platform, along with also verifying that the
> package meets the requirements of the ASF policy on releases."
>
> A document to walk through some of this process has been published on
> our project wiki and can be found here [4].
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [4])
> [ ] -1 reject (explanation required)
>
> Thank you all,
> Alin Jerpelea
>
> SCM Information:
>   Release tag: nuttx-12.0.0-RC0
>   Hash for the release nuttx tag: 874031bbf644c24e44c5b6af990a0c0c45d86ed3
>   Hash for the release nuttx-apps tag: 
> 5592e38253bc74c65f4d105f837d8bc048ac1859
>
> [1] https://dist.apache.org/repos/dist/dev/nuttx/12.0.0-RC0/
> [2] 
> https://raw.githubusercontent.com/apache/nuttx/nuttx-12.0.0-RC0/ReleaseNotes
> [3] https://www.apache.org/dev/release.html#approving-a-release
> [4] 
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release

Re: is CODE keyword still used?

[Takashi Yamamoto]

On Thu, Jan 27, 2022 at 1:57 AM Alan Carvalho de Assis
 wrote:
>
> Sorry Petro, I missed that files!
>
> Maybe Greg could explain why it is missing or if it is not necessary.

i'm interested in the answer to this.

>
> Should be nice if we could find a wait to instruct the compiler (or
> the building system) to include the typedefed CODE to the pointer
> functions automatically, but I don't know if it is possible.
>
> BR,
>
> Alan
>
> On 1/26/22, Petro Karashchenko  wrote:
> > Hello Alan,
> >
> > Maybe you misread the header file. Here are few examples of what is in
> > include/nuttx/fs/fs.h
> > struct file_operations
> > {
> >   /* The device driver open method differs from the mountpoint open method
> > */
> >
> >   int (*open)(FAR struct file *filep);
> >
> >   /* The following methods must be identical in signature and position
> >* because the struct file_operations and struct mountp_operations are
> >* treated like unions.
> >*/
> >
> >   int (*close)(FAR struct file *filep);
> >   ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
> >   ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> >size_t buflen);
> >   off_t   (*seek)(FAR struct file *filep, off_t offset, int whence);
> >   int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
> >
> >   /* The two structures need not be common after this point */
> >
> >   int (*poll)(FAR struct file *filep, struct pollfd *fds, bool setup);
> > #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> >   int (*unlink)(FAR struct inode *inode);
> > #endif
> > };
> >
> > struct block_operations
> > {
> >   int (*open)(FAR struct inode *inode);
> >   int (*close)(FAR struct inode *inode);
> >   ssize_t (*read)(FAR struct inode *inode, FAR unsigned char *buffer,
> > blkcnt_t start_sector, unsigned int nsectors);
> >   ssize_t (*write)(FAR struct inode *inode, FAR const unsigned char
> > *buffer,
> > blkcnt_t start_sector, unsigned int nsectors);
> >   int (*geometry)(FAR struct inode *inode, FAR struct geometry
> >   *geometry);
> >   int (*ioctl)(FAR struct inode *inode, int cmd, unsigned long arg);
> > #ifndef CONFIG_DISABLE_PSEUDOFS_OPERATIONS
> >   int (*unlink)(FAR struct inode *inode);
> > #endif
> > };
> >
> > struct mountpt_operations
> > {
> >   /* The mountpoint open method differs from the driver open method
> >* because it receives (1) the inode that contains the mountpoint
> >* private data, (2) the relative path into the mountpoint, and (3)
> >* information to manage privileges.
> >*/
> >
> >   int (*open)(FAR struct file *filep, FAR const char *relpath,
> > int oflags, mode_t mode);
> >
> >   /* The following methods must be identical in signature and position
> >* because the struct file_operations and struct mountpt_operations are
> >* treated like unions.
> >*/
> >
> >   int (*close)(FAR struct file *filep);
> >   ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
> >   ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
> > size_t buflen);
> >   off_t   (*seek)(FAR struct file *filep, off_t offset, int whence);
> >   int (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
> >
> >   /* The two structures need not be common after this point. The following
> >* are extended methods needed to deal with the unique needs of mounted
> >* file systems.
> >*
> >* Additional open-file-specific mountpoint operations:
> >*/
> >
> >   int (*sync)(FAR struct file *filep);
> >   int (*dup)(FAR const struct file *oldp, FAR struct file *newp);
> >   int (*fstat)(FAR const struct file *filep, FAR struct stat *buf);
> >   int (*fchstat)(FAR const struct file *filep,
> >  FAR const struct stat *buf, int flags);
> >   int (*truncate)(FAR struct file *filep, off_t length);
> >
> >   /* Directory operations */
> >
> >   int (*opendir)(FAR struct inode *mountpt, FAR const char *relpath,
> > FAR struct fs_dirent_s *dir);
> >   int (*closedir)(FAR struct inode *mountpt,
> > FAR struct fs_dirent_s *dir);
> >   int (*readdir)(FAR struct inode *mountpt,
> > FAR struct fs_dirent_s *dir);
> >   int (*rewinddir)(FAR struct inode *mountpt,
> > FAR struct fs_dirent_s *dir);
> >
> >   /* General volume-related mountpoint operations: */
> >
> >   int (*bind)(FAR struct inode *blkdriver, FAR const void *data,
> > FAR void **handle);
> >   int (*unbind)(FAR void *handle, FAR struct inode **blkdriver,
> > unsigned int flags);
> >   int (*statfs)(FAR struct inode *mountpt, FAR struct statfs *buf);
> >
> >   /* Operations on paths */
> >
> >   int (*unlink)(FAR struct inode *mountpt, FAR const char *relpath);
> >   int (*mkdir)(FAR struct inode *mountpt, FAR c

Re: is CODE keyword still used?

[Takashi Yamamoto]

i guess that a problem is the semantics of CODE/FAR/NEAR is not very
well documented.

On Thu, Jan 27, 2022 at 5:21 AM Gregory Nutt  wrote:
>
> >
> >> Should be nice if we could find a wait to instruct the compiler (or
> >> the building system) to include the typedefed CODE to the pointer
> >> functions automatically, but I don't know if it is possible.
> >>
> >> I think you are all making risky irresponsible changes to fix something
> > that is not broken.
> >
>
> Also, I don't think that you can assume that a pointed-at function resides
> in code ROM.  Couldn't it also reside in RAM?  I could imagine having FAR
> function pointers and CODE function pointers and we should not limit the
> support.

do you mean they would be "void (CODE *f)(void)" and "void (FAR *f)(void)"
respectively?

Re: NET_TCP_SPLIT removal

[Takashi Yamamoto]

hi,

> I am not 100% sure of this, but I still think that it would be better to
> remove the unbuffered TCP send logic rather than remove the packet split
> logic.

personally i have no objection against the removal of unbuffered send.

but i can understand if someone objects it.
for some situations, maybe for an MSS-aware app, unbuffered send can
work better.

> I don't see how removing the split makes the unbuffered send
> better.

it reduces the code and makes it easier to maintain.

NET_TCP_SPLIT removal

[Takashi Yamamoto]

hi,

i submitted a PR to remove NET_TCP_SPLIT.
https://github.com/apache/incubator-nuttx/pull/4660

i'm posting this here because a feature removal should be reviewed by
wider audience.
especially, if you are relying on it, please speak up.

Re: FreeBSD / BSD

[Takashi Yamamoto]

On Fri, Oct 8, 2021 at 2:25 PM Tomasz CEDRO  wrote:
>
> On Fri, Oct 8, 2021 at 6:45 AM Takashi Yamamoto wrote:
> >
> > On Fri, Oct 8, 2021 at 12:51 PM Tomasz CEDRO wrote:
> > >
> > > On Fri, Oct 8, 2021 at 5:15 AM Tomasz CEDRO wrote:
> > > > On Fri, Oct 8, 2021 at 4:47 AM Nathan Hartman  wrote:
> > > > > There is a NuttX Tools repo at
> > > > > https://bitbucket.org/nuttx/tools/downloads/
> > > > >
> > > > > I think I built the kconfig-frontends from there a long time ago.
> > > >
> > > > Thank you for this hint I will try to build that on my FreeBSD. I
> > > > could not find kconfig sources :-)
> > >
> > > `kconfig-frontends-4.11.0.1` does not build on FreeBSD:
> > >
> > >   CC   libs/parser/libs_parser_libkconfig_parser_la-yconf.lo
> > > In file included from libs/parser/yconf.c:252:
> > > libs/parser/hconf.gperf:153:1: error: conflicting types for 
> > > 'kconf_id_lookup'
> > > kconf_id_lookup (register const char *str, register unsigned int len)
> > > ^
> > > libs/parser/hconf.gperf:12:31: note: previous declaration is here
> > > static const struct kconf_id *kconf_id_lookup(register const char
> > > *str, register GPERF_LEN_TYPE len);
> > >   ^
> > > libs/parser/hconf.gperf:40:44: warning: static variable
> > > 'kconf_id_strings_contents' is used in an inline function with
> > > external linkage [-Wstatic-in-inline]
> > >   register const char *s = o + kconf_id_strings;
> > >^
> > > libs/parser/hconf.gperf:145:43: note: expanded from macro 
> > > 'kconf_id_strings'
> > > #define kconf_id_strings ((const char *) &kconf_id_strings_contents)
> > >   ^
> > > libs/parser/hconf.gperf:147:1: note: use 'static' to give inline
> > > function 'kconf_id_lookup' internal linkage
> > >
> > > There is `gperf-3.1` package installed.
> > >
> > >
> > > Can anyone point me to the official `kconfig-frontends` website and
> > > source code repository?
> > >
> > > I can find 28 repositories on GitHub all seems to be outdated forks:
> > > https://github.com/search?q=kconfig-frontends
> > >
> > >
> > > One of them is 
> > > https://github.com/NuttX/tools/tree/master/kconfig-frontends,
> > > where I find:
> > >
> > > This is a snapshot of the kconfig-frontends version 4.11.0.1 tarball taken
> > > from http://ymorin.is-a-geek.org/projects/kconfig-frontends.
> > >
> > > But that server does not respond.
> > >
> > >
> > > Another finding is https://github.com/espressif/kconfig-frontends but
> > > that is explicitly a modified version so its a different tool with the
> > > same name.
> > >
> > >
> > > I hope NuttX does not have a critical dependency on abandoned
> > > unmaintained tool ?
> >
> > i guess "we are maintaining the fork by ourselves" is a better
> > description of the current situation.
> > as it can be built for macOS. i guess it isn't too difficult to port
> > it to FreeBSD.
>
> Porting to FreeBSD was my first intention, no problem with that, but
> then where do I even send patches if "maintenance" is just keeping old
> bz2 package somewhere out there. Sorry, this is not the serious way to
> go, this tool seems abandoned and you should consider abandoning it
> too.
>
> "Works for me after I patched 38 packages that took me 18 days and
> works only on my local machine"^TM makes me think "do not touch that
> project"^TM :-)
>
>
> > i think kconfiglib is a better tool in general. at least it's
> > definitely easier for someone new to nuttx to start with.
> > but it seems for some people python dependency is not acceptable.
> > maybe we can support the both? how others think?
>
> Anything that has live community, source code repository, and is
> proven effective in other projects will be better :-)
>
> There are some `*.py` files in `nuttx/tools/` already so why Python
> could be a blocker?

because kconfig is a more critical tool than these .py files?

i don't remember who told me python was not acceptable.
hopefully he will read this and explain us.

> From my experience Python is the best way to
> provide platform independent tools in most cases.
>
>
> This is my "first contact" with NuttX. That could provide a valuable
> feedback for you guys. I played before with FreeRTOS, ARM MBED, and
> Zephyr RTOS, all of them provide Fire-and-Forget experience that is
> crucial for business. There is no point in using solution that
> requires +10x more time to setup than work on the target project. Sure
> I can invest some time in developing the tools but first I need to get
> at least one working product to prove that tool is worth the time and
> effort :-)
>
> I don't want to sound rude, but on Zephyr I just got from scratch
> working example for ESP32-C3 under 5 minutes, that proves I can
> implement my project using that tool set even though it may require
> some additional work.
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: FreeBSD / BSD

[Takashi Yamamoto]

On Fri, Oct 8, 2021 at 12:51 PM Tomasz CEDRO  wrote:
>
> On Fri, Oct 8, 2021 at 5:15 AM Tomasz CEDRO wrote:
> > On Fri, Oct 8, 2021 at 4:47 AM Nathan Hartman  wrote:
> > > There is a NuttX Tools repo at
> > > https://bitbucket.org/nuttx/tools/downloads/
> > >
> > > I think I built the kconfig-frontends from there a long time ago.
> >
> > Thank you for this hint I will try to build that on my FreeBSD. I
> > could not find kconfig sources :-)
>
> `kconfig-frontends-4.11.0.1` does not build on FreeBSD:
>
>   CC   libs/parser/libs_parser_libkconfig_parser_la-yconf.lo
> In file included from libs/parser/yconf.c:252:
> libs/parser/hconf.gperf:153:1: error: conflicting types for 'kconf_id_lookup'
> kconf_id_lookup (register const char *str, register unsigned int len)
> ^
> libs/parser/hconf.gperf:12:31: note: previous declaration is here
> static const struct kconf_id *kconf_id_lookup(register const char
> *str, register GPERF_LEN_TYPE len);
>   ^
> libs/parser/hconf.gperf:40:44: warning: static variable
> 'kconf_id_strings_contents' is used in an inline function with
> external linkage [-Wstatic-in-inline]
>   register const char *s = o + kconf_id_strings;
>^
> libs/parser/hconf.gperf:145:43: note: expanded from macro 'kconf_id_strings'
> #define kconf_id_strings ((const char *) &kconf_id_strings_contents)
>   ^
> libs/parser/hconf.gperf:147:1: note: use 'static' to give inline
> function 'kconf_id_lookup' internal linkage
>
> There is `gperf-3.1` package installed.
>
>
> Can anyone point me to the official `kconfig-frontends` website and
> source code repository?
>
> I can find 28 repositories on GitHub all seems to be outdated forks:
> https://github.com/search?q=kconfig-frontends
>
>
> One of them is https://github.com/NuttX/tools/tree/master/kconfig-frontends,
> where I find:
>
> This is a snapshot of the kconfig-frontends version 4.11.0.1 tarball taken
> from http://ymorin.is-a-geek.org/projects/kconfig-frontends.
>
> But that server does not respond.
>
>
> Another finding is https://github.com/espressif/kconfig-frontends but
> that is explicitly a modified version so its a different tool with the
> same name.
>
>
> I hope NuttX does not have a critical dependency on abandoned
> unmaintained tool ?

i guess "we are maintaining the fork by ourselves" is a better
description of the current situation.
as it can be built for macOS. i guess it isn't too difficult to port
it to FreeBSD.

i think kconfiglib is a better tool in general. at least it's
definitely easier for someone new to nuttx to start with.
but it seems for some people python dependency is not acceptable.
maybe we can support the both? how others think?

>
>
> I need to deliver a result to my client in a form where they clone a
> git repo, bootstrap one script, and build the firmware ready to use.
> Is it possible with NuttX? It can be done with Zephyr.
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: ESP32-C3 RISC-V

[Takashi Yamamoto]

> I can see some "bashisms" in the shell scripts, did you consider using
> raw /bin/sh or is it too much work and `bash` is the best way already?
> I am asking because on Linux `/bin/sh` is `/bin/bash` while on BSD
> `/bin/sh` is /bin/sh` while `bash` is the optional package :-)

i consider using bash-only features in a script with /bin/sh shebang is a bug.
please feel free to contribute patches, either to avoid bashism or to
fix shebang.

Re: Support for disk full detection using LittleFS

[Takashi Yamamoto]

On Fri, May 28, 2021 at 9:21 PM Flavio Castro Alves Filho
 wrote:
>
> Hello,
>
> I am using LittleFS to store information on an external dataflash.
>
> I need to know if the memory is full. I saw that the nsh provides the
> df command, which as far as I understood is a cat for /proc/fs/usage
> file.
>
> In my code, I could see the LFS message indicating LFS_ERR_NOSPC,
> which is an error message indicating no more space when writing files.
> But the return from the fwrite call is OK (indicating the number of
> written bytes) :-|

if your FILE is buffered, you may just need fflush or fclose and check
the error.
in that case, it's an expected behavior.

otherwise, sounds like a bug in the OS.

>
> Is /proc/fs/usage available for LittleFS? Is there any way to get the
> disk space programmatically?
>
> Best regards,
>
> Flavio
>
> --
> Flavio de Castro Alves Filho
>
> flavio.al...@gmail.com
> Twitter: http://twitter.com/#!/fraviofii
> LinkedIn profile: www.linkedin.com/in/flaviocastroalves

Re: spiffs (in)compatilibity

[Takashi Yamamoto]

On Tue, Dec 22, 2020 at 8:08 AM Gregory Nutt  wrote:
>
>
> >> The version in NuttX is based off an older version of SPIFFS (before all
> >> of the security related changes) and may have incompatibilities with the
> >> current SPIFFS.
> > do you remember which exact version of SPIFFS it was?
> You will find all of that information in fs/spiffs/README.md

it seems like a copy of https://github.com/pellepl/spiffs/blob/master/README.md
do you mean it was 0.3.7?

Re: spiffs (in)compatilibity

[Takashi Yamamoto]

hi,

On Mon, Dec 21, 2020 at 10:11 PM Gregory Nutt  wrote:
>
> The version in NuttX is based off an older version of SPIFFS (before all
> of the security related changes) and may have incompatibilities with the
> current SPIFFS.

do you remember which exact version of SPIFFS it was?

>
> On 12/20/2020 11:26 PM, Takashi Yamamoto wrote:
> > hi,
> >
> > a question: is the nuttx implementation of spiffs diverted intentionally 
> > from
> > other implementations? or is it just a bug?
> >
> > background:
> > i needed the following changes to use spiffs images from mkspiffs and
> > spiffsgen.py.
> > https://github.com/apache/incubator-nuttx/pull/2572
>
>

spiffs (in)compatilibity

[Takashi Yamamoto]

hi,

a question: is the nuttx implementation of spiffs diverted intentionally from
other implementations? or is it just a bug?

background:
i needed the following changes to use spiffs images from mkspiffs and
spiffsgen.py.
https://github.com/apache/incubator-nuttx/pull/2572

Re: official nuttx-ci-linux image

[Takashi Yamamoto]

On Fri, Aug 7, 2020 at 9:38 AM Brennan Ashton  wrote:
>
> On Thu, Aug 6, 2020, 4:35 PM Takashi Yamamoto 
> wrote:
>
> > On Thu, Aug 6, 2020 at 11:57 PM Brennan Ashton
> >  wrote:
> > >
> > > On Thu, Aug 6, 2020, 4:03 AM Takashi Yamamoto
> > 
> > > wrote:
> > >
> > > > hi,
> > > >
> > > > the docker image used by the CI (nuttx-ci-linux) is useful for other
> > > > purposes.
> > > > but as far as i know, it isn't pullable publicly.
> > > >
> > > > right now, i'm building and pushing it to docker hub for my own
> > > > consumption.
> > > > https://hub.docker.com/repository/docker/yamt/nuttx-ci-linux
> > > > i think it's worth to provide an equivalent officially as a project.
> > > >
> > > > how do you think?
> > > >
> > >
> > > The image is already publicly available.  This is how the CI system uses
> > it
> > > including Jenkins
> > >
> > > https://github.com/apache/incubator-nuttx-testing/packages/159581
> >
> > spacetanuki% docker pull
> > docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
> > Error response from daemon: Get
> >
> > https://docker.pkg.github.com/v2/apache/incubator-nuttx-testing/nuttx-ci-linux/manifests/latest
> > :
> > no basic auth credentials
> > spacetanuki%
> >
> > what credential should i use for public consumption?
> >
>
>
> You have to use your GitHub credentials or token even for public ones
> unfortunately.
>
> https://docs.github.com/en/packages/using-github-packages-with-your-projects-ecosystem/configuring-docker-for-use-with-github-packages
>
> There is a long ticket of people complaining about this restriction. It's
> also why we have the extra login step in our CI run.

a token with read:packages worked. thank you.

>
> https://github.community/t/docker-pull-from-public-github-package-registry-fail-with-no-basic-auth-credentials-error/16358

heh. i may add my complaint there.

now, i have a variation of my original suggestion.
in addition to github packages, how about pushing the image to a less
broken public registry as well? eg. docker hub

>
> --Brennan

Re: official nuttx-ci-linux image

[Takashi Yamamoto]

On Thu, Aug 6, 2020 at 11:57 PM Brennan Ashton
 wrote:
>
> On Thu, Aug 6, 2020, 4:03 AM Takashi Yamamoto 
> wrote:
>
> > hi,
> >
> > the docker image used by the CI (nuttx-ci-linux) is useful for other
> > purposes.
> > but as far as i know, it isn't pullable publicly.
> >
> > right now, i'm building and pushing it to docker hub for my own
> > consumption.
> > https://hub.docker.com/repository/docker/yamt/nuttx-ci-linux
> > i think it's worth to provide an equivalent officially as a project.
> >
> > how do you think?
> >
>
> The image is already publicly available.  This is how the CI system uses it
> including Jenkins
>
> https://github.com/apache/incubator-nuttx-testing/packages/159581

spacetanuki% docker pull
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
Error response from daemon: Get
https://docker.pkg.github.com/v2/apache/incubator-nuttx-testing/nuttx-ci-linux/manifests/latest:
no basic auth credentials
spacetanuki%

what credential should i use for public consumption?

>
> --Brennan
>
> >

official nuttx-ci-linux image

[Takashi Yamamoto]

hi,

the docker image used by the CI (nuttx-ci-linux) is useful for other purposes.
but as far as i know, it isn't pullable publicly.

right now, i'm building and pushing it to docker hub for my own consumption.
https://hub.docker.com/repository/docker/yamt/nuttx-ci-linux
i think it's worth to provide an equivalent officially as a project.

how do you think?

Re: api stability in apps/netutils/webclient

[Takashi Yamamoto]

On Wed, Jun 3, 2020 at 4:23 AM Alan Carvalho de Assis  wrote:
>
> Hi Takashi,
>
> Do you think it could be possible to create a HTTP REST framework for
> NuttX similar to Ulfius:
>
> https://babelouest.github.io/ulfius/
>
> https://www.hackster.io/babelouest/http-rest-framework-in-c-for-embedded-systems-d34b0c
>
> It should be very useful feature.

do you mean the particular api? or its feature set?
anyway i can't think of any reason it's impossible for nuttx.

in case you are asking if i volunteer to create such a rich framework,
no, i don't. (sorry!)

>
> BR,
>
> Alan
>
> On 5/29/20, Takashi Yamamoto  wrote:
> > hi,
> >
> > On Fri, May 29, 2020 at 11:53 PM Sebastien Lorquet 
> > wrote:
> >>
> >> I think the web client could be rewritten to benefit from the curl port
> >> I started a while a go, which is available upstream:
> >>
> >> https://github.com/apache/incubator-nuttx-apps/tree/master/netutils/libcurl4nx
> >>
> >> Improving this curl port would benefit any app using it, not just the
> >> web client.
> >
> > i have looked at libcurl4n before i decided to use webclient.
> > my problem with libcurl4nx were:
> >
> > * weird name :-)
> > * it looked even less mature and incomplete than webclient.
> > * no users as far as i know.
> > * "easy" api was not that attractive. i hope it were "multi" api.
> > * it looked like an abandoned project. (i guess i was wrong on this
> > point as apparently you still care.)
> >
> > btw, is it a curl port?
> > i thought it was an independent project with a similar api.
> >
> >>
> >> Sebastien
> >>
> >> Le 29/05/2020 à 08:23, Takashi Yamamoto a écrit :
> >> > hi,
> >> >
> >> > On Fri, May 29, 2020 at 7:00 AM Gregory Nutt 
> >> > wrote:
> >> >>
> >> >>> i want to add some stuff to apps/netutils/webclient.
> >> >>> for example,
> >> >>>
> >> >>> * ability to report http status to the caller
> >> >>> * ability to add some request headers
> >> >>> * put
> >> >>> * other content-type for post
> >> >>> * tls
> >> >>>
> >> >>> a question: how much api stability is expected for this?
> >> >> Of course we would like the code to be stable in the sense that it
> >> >> continues to behave correctly; I assume that you would carefully
> >> >> verify
> >> >> new features. But I think by stable you are referring to a fixed API.
> >> >> I
> >> >> don't think that is necessary either.  This is not a standard
> >> >> interface
> >> >> and it is not even documented.  People using non-standard,
> >> >> undocumented
> >> >> interfaces need to accept that they are subject to change without
> >> >> notice.
> >> >>
> >> >> A good explanation in comments of how to get legacy behavior I think
> >> >> is
> >> >> sufficient.  Do other people agree with that?
> >> >>
> >> >>> can i just add extra arguments to wget() etc?
> >> >>> or should i keep wget() intact and introduce a new set of symbols?
> >> >> I don't see any problems with extending wget().   We should do that
> >> >> wisely.  Perhaps it would be better if wget took a structure as an
> >> >> argument rather than a long, long parameter list.  I would personally
> >> >> prefer to see one wget() rather than the old wget() with a new wget2()
> >> >> which is the same but with different parameters.
> >> >>
> >> >> All current usage of wget() should be modified to use any changes that
> >> >> you make to the interface.  I find only examples/wget/ and nshlib/.
> >> >> Is
> >> >> that everything?
> >> > right now i'm thinking
> >> > 1. introduce something like the following. keep wget() etc as wrappers
> >> > of this in the meantime
> >> > 2. once things get stable, inline the existing users of wget() etc in
> >> > the tree, like examples/wget, one-by-one
> >> > 3. consider removing wget() etc
> >> >
> >> > struct webclient_context
> >> > {
> >> >  /* request parameters */
> >> >
> >> >  FAR const char *method;
> >> >  FAR const char *url;
> >> >  FAR const char * FAR const *headers;
> >> >  unsigned int *nheaders;
> >> >
> >> >  /* other parameters */
> >> >
> >> >  FAR char *buffer;
> >> >  int buflen;
> >> >  wget_callback_t callback,
> >> >  FAR void *callback_arg;
> >> >  FAR const struct webclient_tls_ops *tls_ops;
> >> >  FAR void *tls_ctx;
> >> >
> >> >  /* result */
> >> >
> >> >  int http_status;
> >> > };
> >> >
> >> > struct webclient_context ctx;
> >> > webclient_set_defaults(&ctx);
> >> > ctx.method = "GET";
> >> > ctx.url = "..."
> >> > :
> >> > ret = webclient_perform(&ctx);
> >

Re: api stability in apps/netutils/webclient

[Takashi Yamamoto]

On Fri, May 29, 2020 at 3:23 PM Takashi Yamamoto  wrote:
>
> hi,
>
> On Fri, May 29, 2020 at 7:00 AM Gregory Nutt  wrote:
> >
> >
> > > i want to add some stuff to apps/netutils/webclient.
> > > for example,
> > >
> > > * ability to report http status to the caller
> > > * ability to add some request headers
> > > * put
> > > * other content-type for post
> > > * tls
> > >
> > > a question: how much api stability is expected for this?
> >
> > Of course we would like the code to be stable in the sense that it
> > continues to behave correctly; I assume that you would carefully verify
> > new features. But I think by stable you are referring to a fixed API.  I
> > don't think that is necessary either.  This is not a standard interface
> > and it is not even documented.  People using non-standard, undocumented
> > interfaces need to accept that they are subject to change without notice.
> >
> > A good explanation in comments of how to get legacy behavior I think is
> > sufficient.  Do other people agree with that?
> >
> > > can i just add extra arguments to wget() etc?
> > > or should i keep wget() intact and introduce a new set of symbols?
> >
> > I don't see any problems with extending wget().   We should do that
> > wisely.  Perhaps it would be better if wget took a structure as an
> > argument rather than a long, long parameter list.  I would personally
> > prefer to see one wget() rather than the old wget() with a new wget2()
> > which is the same but with different parameters.
> >
> > All current usage of wget() should be modified to use any changes that
> > you make to the interface.  I find only examples/wget/ and nshlib/.  Is
> > that everything?
>
> right now i'm thinking
> 1. introduce something like the following. keep wget() etc as wrappers
> of this in the meantime

PR for this step: https://github.com/apache/incubator-nuttx-apps/pull/333

> 2. once things get stable, inline the existing users of wget() etc in
> the tree, like examples/wget, one-by-one
> 3. consider removing wget() etc
>
> struct webclient_context
> {
> /* request parameters */
>
> FAR const char *method;
> FAR const char *url;
> FAR const char * FAR const *headers;
> unsigned int *nheaders;
>
> /* other parameters */
>
> FAR char *buffer;
> int buflen;
> wget_callback_t callback,
> FAR void *callback_arg;
> FAR const struct webclient_tls_ops *tls_ops;
> FAR void *tls_ctx;
>
> /* result */
>
> int http_status;
> };
>
> struct webclient_context ctx;
> webclient_set_defaults(&ctx);
> ctx.method = "GET";
> ctx.url = "..."
> :
> ret = webclient_perform(&ctx);

ftw/fts

[Takashi Yamamoto]

hi,

does anyone know ftw/nftw, fts, or similar libraries for nuttx?
https://pubs.opengroup.org/onlinepubs/9699919799/functions/nftw.html
https://netbsd.gw.com/cgi-bin/man-cgi?fts++NetBSD-current

dirname_r?

[Takashi Yamamoto]

hi,

i'm using FLAT memory model.
i want to use dirname() in my app.
but there seems to be no safe way to use static-buffer returning
functions like this
unless you have very tight control on what you run on your system.
am i correct?
i think it makes sense for nuttx to provide non-standard reentrant versions
of these functions. (say, dirname_r(). macOS has it.)
how do you think?

Re: api stability in apps/netutils/webclient

[Takashi Yamamoto]

hi,

On Fri, May 29, 2020 at 11:53 PM Sebastien Lorquet  wrote:
>
> I think the web client could be rewritten to benefit from the curl port
> I started a while a go, which is available upstream:
>
> https://github.com/apache/incubator-nuttx-apps/tree/master/netutils/libcurl4nx
>
> Improving this curl port would benefit any app using it, not just the
> web client.

i have looked at libcurl4n before i decided to use webclient.
my problem with libcurl4nx were:

* weird name :-)
* it looked even less mature and incomplete than webclient.
* no users as far as i know.
* "easy" api was not that attractive. i hope it were "multi" api.
* it looked like an abandoned project. (i guess i was wrong on this
point as apparently you still care.)

btw, is it a curl port?
i thought it was an independent project with a similar api.

>
> Sebastien
>
> Le 29/05/2020 à 08:23, Takashi Yamamoto a écrit :
> > hi,
> >
> > On Fri, May 29, 2020 at 7:00 AM Gregory Nutt  wrote:
> >>
> >>> i want to add some stuff to apps/netutils/webclient.
> >>> for example,
> >>>
> >>> * ability to report http status to the caller
> >>> * ability to add some request headers
> >>> * put
> >>> * other content-type for post
> >>> * tls
> >>>
> >>> a question: how much api stability is expected for this?
> >> Of course we would like the code to be stable in the sense that it
> >> continues to behave correctly; I assume that you would carefully verify
> >> new features. But I think by stable you are referring to a fixed API.  I
> >> don't think that is necessary either.  This is not a standard interface
> >> and it is not even documented.  People using non-standard, undocumented
> >> interfaces need to accept that they are subject to change without notice.
> >>
> >> A good explanation in comments of how to get legacy behavior I think is
> >> sufficient.  Do other people agree with that?
> >>
> >>> can i just add extra arguments to wget() etc?
> >>> or should i keep wget() intact and introduce a new set of symbols?
> >> I don't see any problems with extending wget().   We should do that
> >> wisely.  Perhaps it would be better if wget took a structure as an
> >> argument rather than a long, long parameter list.  I would personally
> >> prefer to see one wget() rather than the old wget() with a new wget2()
> >> which is the same but with different parameters.
> >>
> >> All current usage of wget() should be modified to use any changes that
> >> you make to the interface.  I find only examples/wget/ and nshlib/.  Is
> >> that everything?
> > right now i'm thinking
> > 1. introduce something like the following. keep wget() etc as wrappers
> > of this in the meantime
> > 2. once things get stable, inline the existing users of wget() etc in
> > the tree, like examples/wget, one-by-one
> > 3. consider removing wget() etc
> >
> > struct webclient_context
> > {
> >  /* request parameters */
> >
> >  FAR const char *method;
> >  FAR const char *url;
> >  FAR const char * FAR const *headers;
> >  unsigned int *nheaders;
> >
> >  /* other parameters */
> >
> >  FAR char *buffer;
> >  int buflen;
> >  wget_callback_t callback,
> >  FAR void *callback_arg;
> >  FAR const struct webclient_tls_ops *tls_ops;
> >  FAR void *tls_ctx;
> >
> >  /* result */
> >
> >  int http_status;
> > };
> >
> > struct webclient_context ctx;
> > webclient_set_defaults(&ctx);
> > ctx.method = "GET";
> > ctx.url = "..."
> > :
> > ret = webclient_perform(&ctx);

Re: api stability in apps/netutils/webclient

[Takashi Yamamoto]

hi,

On Fri, May 29, 2020 at 7:00 AM Gregory Nutt  wrote:
>
>
> > i want to add some stuff to apps/netutils/webclient.
> > for example,
> >
> > * ability to report http status to the caller
> > * ability to add some request headers
> > * put
> > * other content-type for post
> > * tls
> >
> > a question: how much api stability is expected for this?
>
> Of course we would like the code to be stable in the sense that it
> continues to behave correctly; I assume that you would carefully verify
> new features. But I think by stable you are referring to a fixed API.  I
> don't think that is necessary either.  This is not a standard interface
> and it is not even documented.  People using non-standard, undocumented
> interfaces need to accept that they are subject to change without notice.
>
> A good explanation in comments of how to get legacy behavior I think is
> sufficient.  Do other people agree with that?
>
> > can i just add extra arguments to wget() etc?
> > or should i keep wget() intact and introduce a new set of symbols?
>
> I don't see any problems with extending wget().   We should do that
> wisely.  Perhaps it would be better if wget took a structure as an
> argument rather than a long, long parameter list.  I would personally
> prefer to see one wget() rather than the old wget() with a new wget2()
> which is the same but with different parameters.
>
> All current usage of wget() should be modified to use any changes that
> you make to the interface.  I find only examples/wget/ and nshlib/.  Is
> that everything?

right now i'm thinking
1. introduce something like the following. keep wget() etc as wrappers
of this in the meantime
2. once things get stable, inline the existing users of wget() etc in
the tree, like examples/wget, one-by-one
3. consider removing wget() etc

struct webclient_context
{
/* request parameters */

FAR const char *method;
FAR const char *url;
FAR const char * FAR const *headers;
unsigned int *nheaders;

/* other parameters */

FAR char *buffer;
int buflen;
wget_callback_t callback,
FAR void *callback_arg;
FAR const struct webclient_tls_ops *tls_ops;
FAR void *tls_ctx;

/* result */

int http_status;
};

struct webclient_context ctx;
webclient_set_defaults(&ctx);
ctx.method = "GET";
ctx.url = "..."
:
ret = webclient_perform(&ctx);

api stability in apps/netutils/webclient

[Takashi Yamamoto]

hi,

i want to add some stuff to apps/netutils/webclient.
for example,

* ability to report http status to the caller
* ability to add some request headers
* put
* other content-type for post
* tls

a question: how much api stability is expected for this?
can i just add extra arguments to wget() etc?
or should i keep wget() intact and introduce a new set of symbols?

Re: FAR for pointer to pointer

[Takashi Yamamoto]

On Tue, May 26, 2020 at 8:05 PM Alan Carvalho de Assis
 wrote:
>
> man strtoul

my question was about FAR.
strtoul is just an example.

>
> On 5/25/20, Takashi Yamamoto  wrote:
> > hi,
> >
> > our strtoul prototype is:
> >
> > unsigned long strtoul(FAR const char *nptr, FAR char **endptr, int
> > base);
> >
> > why shouldn't they be like, say, "FAR char * FAR * endptr"?
> >

FAR for pointer to pointer

[Takashi Yamamoto]

hi,

our strtoul prototype is:

unsigned long strtoul(FAR const char *nptr, FAR char **endptr, int base);

why shouldn't they be like, say, "FAR char * FAR * endptr"?

Re: kconfig (Re: mbedtls)

[Takashi Yamamoto]

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)

[Takashi Yamamoto]

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)

[Takashi Yamamoto]

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

[Takashi Yamamoto]

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
>

kconfig (Re: mbedtls)

[Takashi Yamamoto]

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

[Takashi Yamamoto]

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

Re: mbedtls

[Takashi Yamamoto]

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

[Takashi Yamamoto]

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

mbedtls

[Takashi Yamamoto]

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?
2. if yes, which repository is appropriate? apps?
3. if apps, in which directory? netutils? crypto?
4. how do you think about adding tls support to netutils/webclient?

intel64

[Takashi Yamamoto]

hi,

this is just a curious question.
why do we use the name "intel64" for qemu things?
i thought it was from qemu, but qemu seems to use x86_64 or amd64.
i think "amd64" is more commonly used as it's from amd.
do we want to help intel marketing for some reasons?

CONFIG_SMP_IDLETHREAD_STACKSIZE vs CONFIG_IDLETHREAD_STACKSIZE

[Takashi Yamamoto]

hi,

these configs have the following default values:

  CONFIG_SMP_IDLETHREAD_STACKSIZE=2048
  CONFIG_IDLETHREAD_STACKSIZE=1024

is there any rationale of these values?
the kconfig help text seems to suggest the opposite; the SMP one
should be smaller.

broken CI

[Takashi Yamamoto]

hi,

is anyone already looking at these failures?

https://github.com/apache/incubator-nuttx/pull/607/checks?check_run_id=526302981


Configuration/Tool: pcduino-a10/nsh,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL

Configuring...
/bin/sh: 1: /__w/incubator-nuttx/incubator-nuttx/nuttx/tools/mkdeps: not found
/bin/sh: 1: /__w/incubator-nuttx/incubator-nuttx/nuttx/tools/mkdeps: not found
/bin/sh: 1: /__w/incubator-nuttx/incubator-nuttx/nuttx/tools/mkdeps: not found
/bin/sh: 1: /__w/incubator-nuttx/incubator-nuttx/nuttx/tools/mkdeps: not found
/bin/sh: 1: /__w/incubator-nuttx/incubator-nuttx/nuttx/tools/mkdeps: not found

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Takashi Yamamoto]

On Thu, Mar 19, 2020 at 10:12 PM Gregory Nutt  wrote:
>
>
> > depending on CONFIG_CAN_PASS_STRUCTS,
> > mallinfo has a different prototype.
> >
> > #ifdef CONFIG_CAN_PASS_STRUCTS
> > struct mallinfo mallinfo(void);
> > #else
> > int  mallinfo(FAR struct mallinfo *info);
> > #endif
> >
> > and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS
> > for this even in APPDIR.
> > i'd like to suggest to simplify this by always using
> > "int mallinfo(FAR struct mallinfo *info);" version.
> >
> > or, even "void mallinfo(FAR struct mallinfo *info);" because it
> > doesn't return any errors.
>
> We should not do that.  There are contemporary toolchains that do not
> support passing structures or unions.  Currently on the SDCC compiler
> cannot pass structures.  SDCC is one variant of similar compilers
> focusing on small MCUs.  I imagine that the others have similar
> limitations.  Currently SDCC is used only with z80 but there has been
> talk of using it with other architectures as well, but those have not
> gone anywhere.
>
> Certainly, removing support for SDCC and related compiles would close a
> lot of door for not reason other than your personal preference.  Certain
> the CONFIG_CAN_PASS_STRUCTS is ugly but it serves a real purpose for the
> community.  Your proposal serves no purpose other than you personal
> preference.

i'm not suggesting to remove SDCC support or whatever.
my proposal is the opposite.
always use the conservative prototype.

>
> It is worth re-considering the INVIOLABLES.txt which all committers are
> expected to uphold:
>
> All Users Matter
> 
>
>o All support must apply equally to all supported platforms.  At
> present
>  this includes Linux, Windows MSYS, Windows Cygwin, Windows Ubuntu,
>  Windows native, macOS, Solaris, and FreeBSD.  No tool/environment
>  solutions will be considered that limit the usage of NuttX on
> any of
>  the supported platforms.
>o Inclusive rather than exclusive.
>o *Hobbyists are valued users of the OS* including retro
> computing hobbyists
>  * and DIY “Maker” hobbyists.
>o Supported toolchains:  GCC, Clang, *SDCC*, ZiLOG ZDS-II (c89), IAR.
>  Others?
>o No changes to build system should limit use of NuttX by any user.
>o *Simplifying things for one user does not justify excluding
> another user.*
>o *We should seek to expand the NuttX user base, not to limit it
> for**
>  reasons of preference or priority.*
>o *We must resist the pull to make NuttX into a Linux-only,
> GCC-only, and**
>  ARM-only solution.*
>
> I think we must think less about ourselves and less about our own
> project environment, and more about the community.
>
> Greg
>

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Takashi Yamamoto]

On Thu, Mar 19, 2020 at 7:59 PM Xiang Xiao  wrote:
>
> On Thu, Mar 19, 2020 at 6:39 PM Takashi Yamamoto
>  wrote:
> >
> > do you feel the returning-structure version less uglier?
>
> Yes, returning-structure is a bad design in most case, but we can't
> change mallinfo prototype since it is defined by other OS:
> http://man7.org/linux/man-pages/man3/mallinfo.3.html

i wasn't aware of that implementation. thank you.
i'm skeptical about the usefulness of the compatibility with it though.
it's non-standard anyway.

>
> > my feeling is the opposite.
> > after all, it's a matter of taste i guess.
> >
>
> I mean the code contained #ifdef/#endif is more uglier than other.
> there are many place conditioned by CAN_PASS_STRUCTS, mallinfo is just
> one of case. It's better to fix all places instead.
>
> > On Thu, Mar 19, 2020 at 7:22 PM Xiang Xiao  
> > wrote:
> > >
> > > But, should we support the aged compiler to make the code ugly? I
> > > prefer to remove CAN_PASS_STRUCTS option and clean up the whole code
> > > base.
> > >
> > > On Thu, Mar 19, 2020 at 2:41 PM Takashi Yamamoto
> > >  wrote:
> > > >
> > > > hi,
> > > >
> > > > depending on CONFIG_CAN_PASS_STRUCTS,
> > > > mallinfo has a different prototype.
> > > >
> > > > #ifdef CONFIG_CAN_PASS_STRUCTS
> > > > struct mallinfo mallinfo(void);
> > > > #else
> > > > int  mallinfo(FAR struct mallinfo *info);
> > > > #endif
> > > >
> > > > and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS
> > > > for this even in APPDIR.
> > > > i'd like to suggest to simplify this by always using
> > > > "int mallinfo(FAR struct mallinfo *info);" version.
> > > >
> > > > or, even "void mallinfo(FAR struct mallinfo *info);" because it
> > > > doesn't return any errors.
> > > >
> > > > how do you think?

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Takashi Yamamoto]

do you feel the returning-structure version less uglier?
my feeling is the opposite.
after all, it's a matter of taste i guess.

On Thu, Mar 19, 2020 at 7:22 PM Xiang Xiao  wrote:
>
> But, should we support the aged compiler to make the code ugly? I
> prefer to remove CAN_PASS_STRUCTS option and clean up the whole code
> base.
>
> On Thu, Mar 19, 2020 at 2:41 PM Takashi Yamamoto
>  wrote:
> >
> > hi,
> >
> > depending on CONFIG_CAN_PASS_STRUCTS,
> > mallinfo has a different prototype.
> >
> > #ifdef CONFIG_CAN_PASS_STRUCTS
> > struct mallinfo mallinfo(void);
> > #else
> > int  mallinfo(FAR struct mallinfo *info);
> > #endif
> >
> > and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS
> > for this even in APPDIR.
> > i'd like to suggest to simplify this by always using
> > "int mallinfo(FAR struct mallinfo *info);" version.
> >
> > or, even "void mallinfo(FAR struct mallinfo *info);" because it
> > doesn't return any errors.
> >
> > how do you think?

mallinfo and CONFIG_CAN_PASS_STRUCTS

[Takashi Yamamoto]

hi,

depending on CONFIG_CAN_PASS_STRUCTS,
mallinfo has a different prototype.

#ifdef CONFIG_CAN_PASS_STRUCTS
struct mallinfo mallinfo(void);
#else
int  mallinfo(FAR struct mallinfo *info);
#endif

and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS
for this even in APPDIR.
i'd like to suggest to simplify this by always using
"int mallinfo(FAR struct mallinfo *info);" version.

or, even "void mallinfo(FAR struct mallinfo *info);" because it
doesn't return any errors.

how do you think?

Re: Should we relax precheck a little bit?

[Takashi Yamamoto]

we basically prevent changes on files unless you can fix all nxstyle
issues in them.
i don't think it's a good idea.

i believe that there can be changes more important than style fixes.
in addition to -r option you suggested,
i'd suggest to make precheck separate from other (IMO more important)
checks like build tests
so that reviewers can choose to "ignore" nxstyle errors after inspecting them.

On Sun, Mar 8, 2020 at 3:11 AM Xiang Xiao  wrote:
>
> Hi all,
> The precheck ensure the whole file content comform to the coding
> style, this strategy has several problems:
> 1.Many source file in mainline already violate the coding style
> 2.nxstyle frequently generate the false alarm in the current stage
> How about we let precheck just ensure the modified line don't violate
> the coding standards?
> I am asking this question because:
> 1.The change in PR 471 has a very good shape:
>  https://github.com/apache/incubator-nuttx/pull/471/files
>but the whole file precheck complain there are many errors:
>  
> https://github.com/apache/incubator-nuttx/pull/471/checks?check_run_id=492244725
>It is unfair to require the contributor to fix the issue not made by them.
> 2.Most PR will fail at precheck stage due to item 1 and then block the
> more important build test.
>
> Thanks
> Xiang

Re: Should we relax precheck a little bit?

[Takashi Yamamoto]

On Tue, Mar 10, 2020 at 3:43 PM Xiang Xiao  wrote:
>
> On Tue, Mar 10, 2020 at 1:17 AM Gregory Nutt  wrote:
> >
> >
> > > - Fixing the entire file we touch helps makes things better overall 
> > > even
> > > though its painful in the short run.
> > > - Having a tool that produces accurate style recommendations is very
> > > important— it's hard to know what to fix and what not to fix if the 
> > > tool
> > > doesn't give accurate messages.
> >
> > I don't know how long it will take, but these two things converging is
> > the keep to ending the pain permanently:  Fixing non-compliant files and
> > improving the tools.
> >
> > I think we should at least wait a little while.  If it takes too long
> > and does not converge to a reasonable solution in the near future, we
> > can revisit this.
>
> Ok, let's wait for sometime to see the result. Since the workflow
> isn't lockdown yet, but the precheck is running for each PR now, I
> would suggest that PR must pass the precheck before merging to ensure
> the basic quality.

do you have any suggestions what to do with this PR?
https://github.com/apache/incubator-nuttx/pull/533
all nxstyle errors are known and explained in the commit message.

>
> >
> > > - Making the tool only look at the differences seems complicated and 
> > > not
> > > what we want in the long run.
> >
> > nxstyle does already support this option:
> >
> > $ tools/nxstyle.exe -h
> > nxstyle version 0.01
> >
> > Usage:  nxstyle [-m ] [-v ] [-r ] 
> >  nxstyle -h this help
> >  nxstyle -v  where level is
> > 0 - no output
> > 1 - PASS/FAIL
> > 2 - output each line (default)
> >
> > The -r option specifies a range of line numbers to test.
> >
> > So it is not complicated for nxstyle (CI logic would need some
> > extension, however).  The real question is whether we should do that
> > rather than if it is difficult to do.
> >
>
> CI logic is also ready now, we just need pass -r to checkpatch.sh
> which will generate the list of start/count for nxstyle to just cover
> the modified lines.
>
> >
> >

Re: Re: Should we relax precheck a little bit?

[Takashi Yamamoto]

On Mon, Mar 9, 2020 at 6:09 AM Peter Van Der Perk
 wrote:
>
> Hi Adam,
>
> I've been trying to make a clang-format for NuttX however I did run in some 
> nasty bugs with clang-format.
> Mostly the inconsistent spacing caused by preprocessor directives (#ifdef) 
> etc.
> I've filed a bug on the LLVM bugtracker 
> (https://bugs.llvm.org/show_bug.cgi?id=44843) unfortunely I didn't get any 
> response.
> Please find below the clang-format I've used, I would say it's 80% done.
> But it's mostly that NXStyle requires special things that clang-format 
> doesn’t provide.

can you give me an example of special things?

>
> ---
> AccessModifierOffset: -6
> AlignAfterOpenBracket: Align
> AlignConsecutiveAssignments: 'true'
> AlignConsecutiveDeclarations: 'false'
> AlignEscapedNewlines: DontAlign
> AlignTrailingComments: 'true'
> AllowShortFunctionsOnASingleLine: None
> AllowShortIfStatementsOnASingleLine: 'false'
> AllowShortLoopsOnASingleLine: 'false'
> AlwaysBreakAfterDefinitionReturnType: None
> AlwaysBreakAfterReturnType: AllDefinitions
> BreakBeforeBinaryOperators: None
> BraceWrapping:
>   AfterCaseLabel:  true
>   AfterClass:  true
>   AfterControlStatement: true
>   AfterEnum:   true
>   AfterFunction:   true
>   AfterNamespace:  true
>   AfterObjCDeclaration: true
>   AfterStruct: true
>   AfterUnion:  true
>   BeforeCatch: true
>   BeforeElse:  true
>   IndentBraces:true
>   SplitEmptyFunction: true
>   SplitEmptyRecord: true
>   SplitEmptyNamespace: true
> BreakBeforeBraces: Custom
> ColumnLimit: 77
> CommentPragmas: '^ IWYU pragma:'
> ConstructorInitializerIndentWidth: '0'
> ContinuationIndentWidth: 2
> IncludeIsMainRegex: (Test)?$
> IndentPPDirectives: AfterHash
> IndentWidth: '2'
> JavaScriptQuotes: Leave
> MaxEmptyLinesToKeep: 2
> NamespaceIndentation: None
> ObjCBlockIndentWidth: '3'
> PenaltyBreakBeforeFirstCallParameter: '32'
> PenaltyBreakComment: 0
> PenaltyBreakFirstLessLess: '44'
> PenaltyBreakString: 838
> PenaltyExcessCharacter: '399916'
> PenaltyReturnTypeOnItsOwnLine: 30
> PointerAlignment: Right
> ReflowComments: 'true'
> SortIncludes: 'false'
> SpaceAfterCStyleCast: 'false'
> SpaceBeforeAssignmentOperators: 'true'
> SpaceBeforeParens: ControlStatements
> SpaceInEmptyParentheses: 'false'
> SpacesBeforeTrailingComments: 1
> SpacesInCStyleCastParentheses: 'false'
> SpacesInParentheses: 'false'
> SpacesInSquareBrackets: 'false'
> Standard: Cpp11
> TabWidth: '4'
> UseTab: Never
> ...
>
> > Thanks David. I'll try your approach. If there are some things that don't 
> > quite work with Clang-Format (I already found a few) I'll see about adding 
> > a fixup script pass at the end, or contributing some rules back to Clang.
> >
> > I'll try your idea about combining all the files under sched into a set.
> >
> > When you said you got 95% of the way there, do you have a .clang-format 
> > file that I could use as a starting point? If so that would help me start 
> > where you left off.
> >
> >cheers
> >adam

Re: Should we relax precheck a little bit?

[Takashi Yamamoto]

On Sun, Mar 8, 2020 at 9:30 AM Gregory Nutt  wrote:
>
>
> > Since there's no current maintainer for nxstyle... What would people think
> > about trying Clang-Format ?
> >
> > It's a well-used tool (LLVM, Google, Chromium, Mozilla, Webkit, and
> > Microsoft ), and
> > can be configured for many different style guides... it should be possible
> > to configure it for NuttX's style guide. Or at least get close.
> >
> > If there's interest, I can take a shot at trying to configure it using the
> > NuttX style guide. If we went that direction, we'd have another tool to
> > install. But then we'd only have to maintain a configuration, and we'd be
> > joining a big community who are all using this same tool.
> >
> > What do you think?
>
> We have already tried indent, astyle, and uncrustify and were not happy
> with them.  There are starts already in tools/.  Of those, indent
> probably works the same.
>
> A tool that produces absolutely perfect output would be useful. But even
> the tiniest of bugs make the tool useless.
>
> My guess is that you will fail.  Everyone else has.  So cannot in good
> faith encourage you.
>
> But if you create the perfect tool that does everything 100% correctly,
> I suppose you would be a hero.  The acceptance test is this:
>
> You run the program against all .c and .h files under sched and the
> output is 100% compatible with the input you win.  One byte different
> you lose.  Hundreds hours have gone into this challenge and all have failed.

assuming that a tool has --try-run/--check-only,
i suppose it doesn't need to be that perfect to replace nxstyle.

>
> Greg

dlopen for I/D separated platform

[Takashi Yamamoto]

hi,

i want to make dlopen work on esp32. [1]
right now, nuttx just does malloc to allocate memory to load text.
however, it can't work on esp32, where instruction and data are separated.
i guess it would be the most straightforward to introduce another
"heap" instance for text.
(according to esp32 document, word-aligned data access to instruction
memory works.)
i'm wondering if there's a more elegant way. any ideas?

[1] draft PR: https://github.com/apache/incubator-nuttx/pull/447

squashing commits or not

[Takashi Yamamoto]

hi,

it seems that in nuttx it's common to squash commits when merging pull requests.

i'd like to suggest _not_ to do that because:
* it makes cherry-pick/backport/revert cumbersome
* larger changes are more difficult to read/understand

on the other hand, i can think of only little benefit.
* aesthetic reasons?
* marginally save the repo size growth?

how do you think?

Re: how to build userspace for CONFIG_BUILD_KERNEL

[Takashi Yamamoto]

hi,

On Wed, Feb 26, 2020 at 1:36 PM Xiang Xiao  wrote:
>
> For kernel build, all symbols need be resolved:
> 1.We need add libapps.a into LDLIBS to resolve nsh_*, which remove
> accidentally in commit 4ee39e208048f075860

it removed only "ifneq ($(CONFIG_BUILD_KERNEL),y)" block.
it should not affect KERNEL build, should it?

> 2.LDLIBS should contain libproxy.a to resolve sched_*,  and libc.a for
> fprintf, but these library should in LDLIBS automatically.
>
> Thanks
> Xiang
>
> On Wed, Feb 26, 2020 at 11:23 AM Takashi Yamamoto
>  wrote:
> >
> > hi,
> >
> > how can i build userspace for CONFIG_BUILD_KERNEL?
> >
> > using sama5d4-ek:knsh config,
> > i tried "make TOPDIR=$(pwd) APPDIR=$(pwd)/../apps -C ../apps install".
> > it generated some binaries like the following.
> > but i don't see how it will get nsh_consolemain etc.
> >
> > spacetanuki% nm ../apps/bin/init
> > 00c0 B _ebss
> > 00c0 D _edata
> > 00c0 N _edtors
> > 00c0 N _enoinit
> > 00bf R _erodata
> > 0098 T _etext
> > 00c0 B _sbss
> > 00c0 N _sctors
> > 00bf D _sdata
> > 00c0 N _sdtors
> > 00c0 N _snoinit
> > 0098 R _srodata
> >  T _stext
> >  U fprintf
> >  T main
> >  U nsh_consolemain
> >  U nsh_initialize
> >  U sched_getparam
> >  U sched_getstreams
> >  U sched_setparam
> > spacetanuki%

how to build userspace for CONFIG_BUILD_KERNEL

[Takashi Yamamoto]

hi,

how can i build userspace for CONFIG_BUILD_KERNEL?

using sama5d4-ek:knsh config,
i tried "make TOPDIR=$(pwd) APPDIR=$(pwd)/../apps -C ../apps install".
it generated some binaries like the following.
but i don't see how it will get nsh_consolemain etc.

spacetanuki% nm ../apps/bin/init
00c0 B _ebss
00c0 D _edata
00c0 N _edtors
00c0 N _enoinit
00bf R _erodata
0098 T _etext
00c0 B _sbss
00c0 N _sctors
00bf D _sdata
00c0 N _sdtors
00c0 N _snoinit
0098 R _srodata
 T _stext
 U fprintf
 T main
 U nsh_consolemain
 U nsh_initialize
 U sched_getparam
 U sched_getstreams
 U sched_setparam
spacetanuki%

Re: Build is broken

[Takashi Yamamoto]

may i assume you are using linux?

here's a fix i tested on ubuntu.
https://github.com/apache/incubator-nuttx-apps/pull/95/commits/adb08a2634ef8df99d509a472e28a7907f73210d

On Sat, Feb 22, 2020 at 1:21 AM David Sidrane  wrote:
>
> This is what I did:
>
> For apps and nuttx git fetch nuttx
> For apps and nuttx git checkout master
> For apps and nuttx git reset -hard nuttx/master
>
> make distclean
> ./tools/configure.sh  imxrt1060-evk:nsh
> make oldconfig
> make
>
> The results are as shown.
>
> Why are we changed the build system without testing on braches?
>
> David
>
> -Original Message-
> From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
> Sent: Friday, February 21, 2020 7:17 AM
> To: dev@nuttx.apache.org
> Subject: Re: Build is broken
>
> On Fri, Feb 21, 2020 at 10:13 AM David Sidrane 
> wrote:
>
> >  Build is broken
> >
> > Build is broken
> >
> > And the output looks very ODD - any ideas on what happened?
>
>
>
> Have you tried make distclean, reconfigure, retry build?
>
> If so, could you run a bisect since the last good known build and identify
> the offending commit?
>
> Thanks
> Nathan

Re: userspace/kernel isolation question

[Takashi Yamamoto]

On Fri, Feb 21, 2020 at 10:29 PM Gregory Nutt  wrote:
>
>
> > while looking at PROTECTED build,
> > i noticed that it was trivial for userspace code to bypass the
> > protection and access kernel memory.
> > eg. by passing kernel pointer to system calls.
> > and it seems that it isn't the only way for userspace to trick the kernel.
> I am not clear how that would work.  The system call itself it through
> an interrtupt handler and only a syscall number is attached.  But, yes,
> there is no checking of system call arguments if that is what you are
> referring to.
>
> Greg

i meant that, if userspace wants to read some kernel memory, it can pass
the kernel pointer to eg. write system call as the buffer argument,
and then read the contents of the file.
my question was if these kinds of checks were for some reasons considered
unnecessary for nuttx.

Re: Build is broken

[Takashi Yamamoto]

it seems --no-print-directory/--print-directory controls these outputs.
do you have any MAKEFLAGS set?
or maybe different builds of make might come with different defaults.
(i'm using the one from macOS)
i'm afraid i can't investigate this until Tue.
please feel free to revert my changes in the meantime.
sorry for the inconvenience.

On Sat, Feb 22, 2020 at 12:25 AM Takashi Yamamoto  wrote:
>
> it's likely because of
> https://github.com/apache/incubator-nuttx-apps/commit/5cb020c70f14b2ff766c96da87c3c4bfd32c
> i suspect APPOBJS variable contains some garbage output from make
> itself. like "make[2]: Leaving directory"
>
> On Sat, Feb 22, 2020 at 12:13 AM David Sidrane  
> wrote:
> >
> >  Build is broken
> >
> > Build is broken
> >
> > And the output looks very ODD - any ideas on what happened?
> >
> > Leaving directory
> > '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform'
> >
> > arm-none-eabi-ar rcs
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/libapps.a  make[1]:
> > Entering directory '/home/david_s5/src/PX4/repos/mainline/NuttX/apps'
> > make[2]: Entering directory
> > '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib'
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_init.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_parse.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_console.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_script.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_system.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_command.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_fscmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_ddcmd.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_proccmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_mmcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_timcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_envcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_syscmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_dbgcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_session.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_fsutils.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_builtin.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_mntcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_consolemain.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_test.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> > make[2]: Leaving directory
> > '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib' make[2]: Entering
> > directory '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin'
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin/builtin_list.home.david_s5.src.PX4.repos.mainline.NuttX.apps.builtin.o
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin/exec_builtin.home.david_s5.src.PX4.repos.mainline.NuttX.apps.builtin.o
> > make[2]: Leaving directory
> > '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin' make[2]:
> > Entering directory
> > '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline'
> > /home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline/readline.home.david_s5.src.PX4.repos.mainline.NuttX.apps.system.readline.o
> > /home/david_s5/src/PX4/repos/mainline/Nut

Re: Build is broken

[Takashi Yamamoto]

it's likely because of
https://github.com/apache/incubator-nuttx-apps/commit/5cb020c70f14b2ff766c96da87c3c4bfd32c
i suspect APPOBJS variable contains some garbage output from make
itself. like "make[2]: Leaving directory"

On Sat, Feb 22, 2020 at 12:13 AM David Sidrane  wrote:
>
>  Build is broken
>
> Build is broken
>
> And the output looks very ODD - any ideas on what happened?
>
> Leaving directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform'
>
> arm-none-eabi-ar rcs
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/libapps.a  make[1]:
> Entering directory '/home/david_s5/src/PX4/repos/mainline/NuttX/apps'
> make[2]: Entering directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib'
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_init.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_parse.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_console.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_script.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_system.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_command.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_fscmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_ddcmd.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_proccmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_mmcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_timcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_envcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_syscmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_dbgcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_session.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_fsutils.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_builtin.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_mntcmds.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_consolemain.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib/nsh_test.home.david_s5.src.PX4.repos.mainline.NuttX.apps.nshlib.o
> make[2]: Leaving directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/nshlib' make[2]: Entering
> directory '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin'
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin/builtin_list.home.david_s5.src.PX4.repos.mainline.NuttX.apps.builtin.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin/exec_builtin.home.david_s5.src.PX4.repos.mainline.NuttX.apps.builtin.o
> make[2]: Leaving directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/builtin' make[2]:
> Entering directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline'
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline/readline.home.david_s5.src.PX4.repos.mainline.NuttX.apps.system.readline.o
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline/readline_common.home.david_s5.src.PX4.repos.mainline.NuttX.apps.system.readline.o
> make[2]: Leaving directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/readline' make[2]:
> Entering directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/nsh'
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/nsh/nsh_main.home.david_s5.src.PX4.repos.mainline.NuttX.apps.system.nsh.o
> make[2]: Leaving directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/system/nsh' make[2]:
> Entering directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform'
> /home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform/dummy.home.david_s5.src.PX4.repos.mainline.NuttX.apps.platform.o
> make[2]: Leaving directory
> '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform' make[1]:
> Leaving directory '/home/david_s5/src/PX4/repos/mainline/NuttX/apps'
>
> arm-none-eab

userspace/kernel isolation question

[Takashi Yamamoto]

hi,

while looking at PROTECTED build,
i noticed that it was trivial for userspace code to bypass the
protection and access kernel memory.
eg. by passing kernel pointer to system calls.
and it seems that it isn't the only way for userspace to trick the kernel.

are these by design? eg. not a problem for what nuttx is intended for.
or bug/overlook/todo/nice-to-have?

background: i'm familiar with "full-sized" operating systems like bsd.
but i'm new to nuttx.

CONFIG_BUILD_KERNEL questions

[Takashi Yamamoto]

hi,

what's the status of CONFIG_BUILD_KERNEL?
it seems only sama5 has the necessary up_ functions. is this right?
is there a way to run on emulators like qemu?

thank you

Re: dev board recommendation?

[Takashi Yamamoto]

i'll try it and tell you a result when/if i have a chance.

On Thu, Feb 13, 2020 at 12:31 PM Ishikawa, Masayuki (SHES)
 wrote:
>
> I think the settings look very basic. So it should work.
> But I'm not sure if GS2200 has any problems with AR9223 Wi-Fi chip.
> Can you try another Wi-Fi router which does not have AR9223 chip?
>
> On 2020/02/12 16:56, "Takashi Yamamoto"  
> wrote:
>
> hi,
>
> what settings do you have in mind?
>
> the wifi router is in the same room, a few meters away from the board.
> the smart person managing the network told me:
> Wireles N fixed on channel 5 (20MHz width), AP in WMM Mode, Short
> Preamble, WPA2 PSK (CCMP) encryption, with "key reinstallation (KRACK)
> countermeasures" enabled
> it is OpenWrt 18.06.3 firmware using Atheros AR9223 wifi chip
>
>
> On Wed, Feb 12, 2020 at 1:09 PM Ishikawa, Masayuki (SHES)
>  wrote:
> >
> > Or what happens if you move GS2200M near the Wi-Fi router?
> >
> >
> > On 2020/02/12 13:02, "Ishikawa, Masayuki (SHES)" 
>  wrote:
> >
> > Thanks for the details.
> >
> > I think it's a GS2200M firmware issue.
> > Could you tell me a product name of the Wi-Fi router?
> > And the issue might be mitigated if you change Wi-Fi router 
> settings.
> >
> >
> > On 2020/02/12 12:32, "Takashi Yamamoto" 
>  wrote:
> >
> > On Tue, Feb 11, 2020 at 1:40 PM Ishikawa, Masayuki (SHES)
> >  wrote:
> > >
> > > Yamamoto-san,
> > >
> > > Could you tell me what kind of network applications you
> > > are trying with Spresense + GS2200M?
> >
> > for now, just a mqtt client.
> > (i know gs2200m has some mqtt functionalities. but i'm not 
> going to use it)
> >
> > >
> > > Also, are you using a Wi-Fi router or directly connecting to
> > > a PC in AP mode? I'd like to know about your network
> > > environment.
> >
> > i'm using station mode. connecting to the existing AP. using 
> WPA2.
> > it sometimes work, sometimes not.
> >
> > when it doesn't work, usually AT+WA gets ERROR response. ("WLAN
> > CONNECT ERROR" if you raise log level of gs2200m)
> > it's somehow mitigated by the following change.
> > 
> https://github.com/apache/incubator-nuttx-apps/commit/2f4b309b1b9faad87788d0668617b07bcfbca305
> >
> > occasiionally AT+WA even timeouts (SPI_TIMEOUT) and it causes
> > assertion failures in the following AT commands because the 
> driver
> > and gs2200m are now out of sync. i guess the driver should 
> reset the
> > chip after giving up waiting for it.
> >
> > even when it's working, tcp connections are occasionally 
> dropped.
> > usually it recovers if i tcp-reconnect. i haven't investigated 
> this
> > symptom.
> >
> > >
> > > On 2020/02/11 1:20, "Takashi Yamamoto" 
>  wrote:
> > >
> > > Thank you.
> > > It looks like the same board as I have.
> > > For me I feel it works 30% of the time.
> > > I wonder what's the difference.
> > >
> > > On Tue, Feb 11, 2020, 01:10 Alin Jerpelea 
>  wrote:
> > >
> > > > I am using this one
> > > >
> > > > 
> https://www.chip1stop.com/SWE/en/product/detail?partId=IDYC-001&mpn=iS110B&keyword=spresense&zaikoFlg=false&partSameFlg=false
> > > >
> > > > On Mon, Feb 10, 2020 at 5:06 PM Xiang Xiao 
> 
> > > > wrote:
> > > >
> > > > > Ubuntu 18.04 run on VirtualBox with NAT. For me, I 
> just spend the time
> > > > > with the hardware my project will use or the 
> simulator.
> > > > >
> > > > > On Mon, Feb 10, 2020 at 11:53 PM Takashi Yamamoto
> > > > >  wrote:
> >

Re: dev board recommendation?

[Takashi Yamamoto]

hi,

what settings do you have in mind?

the wifi router is in the same room, a few meters away from the board.
the smart person managing the network told me:
Wireles N fixed on channel 5 (20MHz width), AP in WMM Mode, Short
Preamble, WPA2 PSK (CCMP) encryption, with "key reinstallation (KRACK)
countermeasures" enabled
it is OpenWrt 18.06.3 firmware using Atheros AR9223 wifi chip


On Wed, Feb 12, 2020 at 1:09 PM Ishikawa, Masayuki (SHES)
 wrote:
>
> Or what happens if you move GS2200M near the Wi-Fi router?
>
>
> On 2020/02/12 13:02, "Ishikawa, Masayuki (SHES)" 
>  wrote:
>
> Thanks for the details.
>
> I think it's a GS2200M firmware issue.
> Could you tell me a product name of the Wi-Fi router?
> And the issue might be mitigated if you change Wi-Fi router settings.
>
>
> On 2020/02/12 12:32, "Takashi Yamamoto"  
> wrote:
>
> On Tue, Feb 11, 2020 at 1:40 PM Ishikawa, Masayuki (SHES)
>  wrote:
> >
> > Yamamoto-san,
> >
> > Could you tell me what kind of network applications you
> > are trying with Spresense + GS2200M?
>
> for now, just a mqtt client.
> (i know gs2200m has some mqtt functionalities. but i'm not going to 
> use it)
>
> >
> > Also, are you using a Wi-Fi router or directly connecting to
> > a PC in AP mode? I'd like to know about your network
> > environment.
>
> i'm using station mode. connecting to the existing AP. using WPA2.
> it sometimes work, sometimes not.
>
> when it doesn't work, usually AT+WA gets ERROR response. ("WLAN
> CONNECT ERROR" if you raise log level of gs2200m)
> it's somehow mitigated by the following change.
> 
> https://github.com/apache/incubator-nuttx-apps/commit/2f4b309b1b9faad87788d0668617b07bcfbca305
>
> occasiionally AT+WA even timeouts (SPI_TIMEOUT) and it causes
> assertion failures in the following AT commands because the driver
> and gs2200m are now out of sync. i guess the driver should reset the
> chip after giving up waiting for it.
>
> even when it's working, tcp connections are occasionally dropped.
> usually it recovers if i tcp-reconnect. i haven't investigated this
> symptom.
>
> >
> > On 2020/02/11 1:20, "Takashi Yamamoto" 
>  wrote:
> >
> > Thank you.
> > It looks like the same board as I have.
> > For me I feel it works 30% of the time.
> > I wonder what's the difference.
> >
> > On Tue, Feb 11, 2020, 01:10 Alin Jerpelea  
> wrote:
> >
> > > I am using this one
> > >
> > > 
> https://www.chip1stop.com/SWE/en/product/detail?partId=IDYC-001&mpn=iS110B&keyword=spresense&zaikoFlg=false&partSameFlg=false
> > >
> > > On Mon, Feb 10, 2020 at 5:06 PM Xiang Xiao 
> 
> > > wrote:
> > >
> > > > Ubuntu 18.04 run on VirtualBox with NAT. For me, I just 
> spend the time
> > > > with the hardware my project will use or the simulator.
> > > >
> > > > On Mon, Feb 10, 2020 at 11:53 PM Takashi Yamamoto
> > > >  wrote:
> > > > >
>     >     > > > which host os are you using?
> > > > >
> > > > > On Tue, Feb 11, 2020 at 12:46 AM Xiang Xiao 
>  > > >
> > > > wrote:
> > > > > >
> > > > > > We use sim which work very well and stable, all
> > > > > > TCP/IP(IP[v6]/ICMP[v6]/UDP/DHCP/DNS/NTP/TCP/TELNET) 
> stack can run in
> > > > > > this virtual environment.
> > > > > >
> > > > > > On Mon, Feb 10, 2020 at 11:41 PM Takashi Yamamoto
> > > > > >  wrote:
> > > > > > >
> > > > > > > hi,
> > > > > > >
> > > > > > > i'm working on some apps which need network 
> connectivity.
> > > > > > > does anyone have a recommendation of a board for 
> development on
> > > which
> > > > > > > i can run nuttx reliably with network? (wifi or 
> ethernet)
> > > > > > > either a real board i can purchase, or 
> emulators/simulators.
> > > > > > >
> > > > > > > right now i'm using spresense and gs2200m-based wifi 
> board.
> > > > > > > https://developer.sony.com/develop/spresense
> > > > > > > https://idy-design.com/product/is110b.html
> > > > > > > but i feel this wifi board is quite unreliable.
> > > > > > > while it might be fun to fix it, unfortunately i have 
> to
> > > concentrate
> > > > > > > on my app rather than the wifi driver in the meantime.
> > > > > > >
> > > > > > > thank you.
> > > >
> > >
> >
> >
>
>
>
>

Re: dev board recommendation?

[Takashi Yamamoto]

On Tue, Feb 11, 2020 at 1:40 PM Ishikawa, Masayuki (SHES)
 wrote:
>
> Yamamoto-san,
>
> Could you tell me what kind of network applications you
> are trying with Spresense + GS2200M?

for now, just a mqtt client.
(i know gs2200m has some mqtt functionalities. but i'm not going to use it)

>
> Also, are you using a Wi-Fi router or directly connecting to
> a PC in AP mode? I'd like to know about your network
> environment.

i'm using station mode. connecting to the existing AP. using WPA2.
it sometimes work, sometimes not.

when it doesn't work, usually AT+WA gets ERROR response. ("WLAN
CONNECT ERROR" if you raise log level of gs2200m)
it's somehow mitigated by the following change.
https://github.com/apache/incubator-nuttx-apps/commit/2f4b309b1b9faad87788d0668617b07bcfbca305

occasiionally AT+WA even timeouts (SPI_TIMEOUT) and it causes
assertion failures in the following AT commands because the driver
and gs2200m are now out of sync. i guess the driver should reset the
chip after giving up waiting for it.

even when it's working, tcp connections are occasionally dropped.
usually it recovers if i tcp-reconnect. i haven't investigated this
symptom.

>
> On 2020/02/11 1:20, "Takashi Yamamoto"  wrote:
>
> Thank you.
> It looks like the same board as I have.
> For me I feel it works 30% of the time.
> I wonder what's the difference.
>
> On Tue, Feb 11, 2020, 01:10 Alin Jerpelea  wrote:
>
> > I am using this one
> >
> > 
> https://www.chip1stop.com/SWE/en/product/detail?partId=IDYC-001&mpn=iS110B&keyword=spresense&zaikoFlg=false&partSameFlg=false
> >
> > On Mon, Feb 10, 2020 at 5:06 PM Xiang Xiao 
> > wrote:
> >
> > > Ubuntu 18.04 run on VirtualBox with NAT. For me, I just spend the time
> > > with the hardware my project will use or the simulator.
> > >
> > > On Mon, Feb 10, 2020 at 11:53 PM Takashi Yamamoto
> > >  wrote:
> > > >
> > > > which host os are you using?
> > > >
> > > > On Tue, Feb 11, 2020 at 12:46 AM Xiang Xiao 
>  > >
>     > > wrote:
> > > > >
> > > > > We use sim which work very well and stable, all
> > > > > TCP/IP(IP[v6]/ICMP[v6]/UDP/DHCP/DNS/NTP/TCP/TELNET) stack can run 
> in
> > > > > this virtual environment.
> > > > >
> > > > > On Mon, Feb 10, 2020 at 11:41 PM Takashi Yamamoto
> > > > >  wrote:
> > > > > >
> > > > > > hi,
> > > > > >
> > > > > > i'm working on some apps which need network connectivity.
> > > > > > does anyone have a recommendation of a board for development on
> > which
> > > > > > i can run nuttx reliably with network? (wifi or ethernet)
> > > > > > either a real board i can purchase, or emulators/simulators.
> > > > > >
> > > > > > right now i'm using spresense and gs2200m-based wifi board.
> > > > > > https://developer.sony.com/develop/spresense
> > > > > > https://idy-design.com/product/is110b.html
> > > > > > but i feel this wifi board is quite unreliable.
> > > > > > while it might be fun to fix it, unfortunately i have to
> > concentrate
> > > > > > on my app rather than the wifi driver in the meantime.
> > > > > >
> > > > > > thank you.
> > >
> >
>
>

Re: dev board recommendation?

[Takashi Yamamoto]

Thank you.
It looks like the same board as I have.
For me I feel it works 30% of the time.
I wonder what's the difference.

On Tue, Feb 11, 2020, 01:10 Alin Jerpelea  wrote:

> I am using this one
>
> https://www.chip1stop.com/SWE/en/product/detail?partId=IDYC-001&mpn=iS110B&keyword=spresense&zaikoFlg=false&partSameFlg=false
>
> On Mon, Feb 10, 2020 at 5:06 PM Xiang Xiao 
> wrote:
>
> > Ubuntu 18.04 run on VirtualBox with NAT. For me, I just spend the time
> > with the hardware my project will use or the simulator.
> >
> > On Mon, Feb 10, 2020 at 11:53 PM Takashi Yamamoto
> >  wrote:
> > >
> > > which host os are you using?
> > >
> > > On Tue, Feb 11, 2020 at 12:46 AM Xiang Xiao  >
> > wrote:
> > > >
> > > > We use sim which work very well and stable, all
> > > > TCP/IP(IP[v6]/ICMP[v6]/UDP/DHCP/DNS/NTP/TCP/TELNET) stack can run in
> > > > this virtual environment.
> > > >
> > > > On Mon, Feb 10, 2020 at 11:41 PM Takashi Yamamoto
> > > >  wrote:
> > > > >
> > > > > hi,
> > > > >
> > > > > i'm working on some apps which need network connectivity.
> > > > > does anyone have a recommendation of a board for development on
> which
> > > > > i can run nuttx reliably with network? (wifi or ethernet)
> > > > > either a real board i can purchase, or emulators/simulators.
> > > > >
> > > > > right now i'm using spresense and gs2200m-based wifi board.
> > > > > https://developer.sony.com/develop/spresense
> > > > > https://idy-design.com/product/is110b.html
> > > > > but i feel this wifi board is quite unreliable.
> > > > > while it might be fun to fix it, unfortunately i have to
> concentrate
> > > > > on my app rather than the wifi driver in the meantime.
> > > > >
> > > > > thank you.
> >
>

Re: dev board recommendation?

[Takashi Yamamoto]

are you using the same wifi board as i am?
https://idy-design.com/product/is110b.html
spresense itself work great for me. the wifi board is not.

On Tue, Feb 11, 2020 at 12:57 AM Alin Jerpelea  wrote:
>
> Hi
>
> I do not know how stable are other boards but I can recommend the spresense
> board since I am working on it and the WiFi implementation seems to be
> stable
>
> //Alin
>
> On Mon, Feb 10, 2020, 16:53 Takashi Yamamoto 
> wrote:
>
> > which host os are you using?
> >
> > On Tue, Feb 11, 2020 at 12:46 AM Xiang Xiao 
> > wrote:
> > >
> > > We use sim which work very well and stable, all
> > > TCP/IP(IP[v6]/ICMP[v6]/UDP/DHCP/DNS/NTP/TCP/TELNET) stack can run in
> > > this virtual environment.
> > >
> > > On Mon, Feb 10, 2020 at 11:41 PM Takashi Yamamoto
> > >  wrote:
> > > >
> > > > hi,
> > > >
> > > > i'm working on some apps which need network connectivity.
> > > > does anyone have a recommendation of a board for development on which
> > > > i can run nuttx reliably with network? (wifi or ethernet)
> > > > either a real board i can purchase, or emulators/simulators.
> > > >
> > > > right now i'm using spresense and gs2200m-based wifi board.
> > > > https://developer.sony.com/develop/spresense
> > > > https://idy-design.com/product/is110b.html
> > > > but i feel this wifi board is quite unreliable.
> > > > while it might be fun to fix it, unfortunately i have to concentrate
> > > > on my app rather than the wifi driver in the meantime.
> > > >
> > > > thank you.
> >

Re: dev board recommendation?

[Takashi Yamamoto]

which host os are you using?

On Tue, Feb 11, 2020 at 12:46 AM Xiang Xiao  wrote:
>
> We use sim which work very well and stable, all
> TCP/IP(IP[v6]/ICMP[v6]/UDP/DHCP/DNS/NTP/TCP/TELNET) stack can run in
> this virtual environment.
>
> On Mon, Feb 10, 2020 at 11:41 PM Takashi Yamamoto
>  wrote:
> >
> > hi,
> >
> > i'm working on some apps which need network connectivity.
> > does anyone have a recommendation of a board for development on which
> > i can run nuttx reliably with network? (wifi or ethernet)
> > either a real board i can purchase, or emulators/simulators.
> >
> > right now i'm using spresense and gs2200m-based wifi board.
> > https://developer.sony.com/develop/spresense
> > https://idy-design.com/product/is110b.html
> > but i feel this wifi board is quite unreliable.
> > while it might be fun to fix it, unfortunately i have to concentrate
> > on my app rather than the wifi driver in the meantime.
> >
> > thank you.

Re: how to port things from spresense sdk

[Takashi Yamamoto]

On Tue, Feb 11, 2020 at 12:34 AM Gregory Nutt  wrote:
>
>
> > How about we host the active project porting on github.com/nuttx? so
> > the community could share the work.
> The ideal solution would be to have the Pahu MQTT support NuttX natively
> in their code.  Then you do not have to port it at all.  We don't want
> responsibility for maintaining forks of other people's code.  It is a
> large effort that takes a lifetime commitment.  We have never done a
> good job trying that in the past.

i agree it's ideal.
is there a "canonical" way for a software to have native nuttx support?
like having the top-level "debian" directory for debian packaging stuff.

dev board recommendation?

[Takashi Yamamoto]

hi,

i'm working on some apps which need network connectivity.
does anyone have a recommendation of a board for development on which
i can run nuttx reliably with network? (wifi or ethernet)
either a real board i can purchase, or emulators/simulators.

right now i'm using spresense and gs2200m-based wifi board.
https://developer.sony.com/develop/spresense
https://idy-design.com/product/is110b.html
but i feel this wifi board is quite unreliable.
while it might be fun to fix it, unfortunately i have to concentrate
on my app rather than the wifi driver in the meantime.

thank you.

predefined platform C macro

[Takashi Yamamoto]

hi,

i'm looking for something like __Darwin__, __Linux__, etc for nuttx
so that i can have something like the following in my app.

#ifdef __NuttX__
#include 
#endif

i found some Make.defs defining -D__NuttX__.
is it commonly used?

how to port things from spresense sdk

[Takashi Yamamoto]

hi,

I wanted to use mqtt on nuttx.
I found a nuttx port of paho.mqtt.embedded-c in spresense sdk. [1]
I modified it for my nuttx $(APPDIR)/external.
you can find it here: https://github.com/yamt/mqtt_nuttx
while it worked, i'm not quite happy with having a fork like this.
can anyone suggest a better way? thank you.

[1] https://github.com/sonydevworld/spresense/tree/master/externals/mqtt