RE: NXView

[Nakamura, Yuuichi (Sony)]

Thanks for detailed comment. I'll study streams.h to apply it for the note data 
interface.

> -Original Message-
> From: Gregory Nutt 
> Sent: Thursday, July 2, 2020 11:05 AM
> To: dev@nuttx.apache.org
> Subject: Re: NXView
> 
> 
> > It's a reasonable function partitioning. How about we define an interface 
> > like
> syslog_channel_s between note and driver? So we can plug in the different
> transport like syslog.
> 
> The correct way to redirect streams within the OS is to use NuttX stream
> interfaces.  Forget about systlog channels.  That is not relevant here.
> 
> NuttX stream interfaces are defined in include/nuttx/streams.h. you would need
> to create an oustream and "inherits" from struct lib_outstream_s.  There are
> several examples of custom outstreams in that header file, but you will 
> create a
> custom one for the ram log.  You will need one that manages the circular ram
> buffer and whatever other special properties.  Please follow the examples in 
> that
> header file.
> 
> This is the universal way of redirecting byte streams within the OS. there 
> are many
> examples since they are used in all cases.  A good example is
> libs/libc/stdio/lib_libvsprintf.c.  That implements all of the family of 
> printf-like
> functions including printf, fprintf, dprintf, sprintf, snprintf, asprintf, 
> etc.  It uses
> an outstream to send the formatted data to the correct recipient:
> 
> int lib_vsprintf(FAR struct lib_outstream_s *stream,
>   FAR const IPTR char *fmt, va_list ap)
> 
> Functions like printf, fprintf, dprintf, sprintf, snprintf, asprintf, etc 
> then just setup
> the outstream instance and call lib_vsprintf().
> 
> The architecture should consist of a encoder that converts the sched_note call
> data to a byte stream by serializing/marshaling a packed data structure.  It
> should then use a global outstream to send the data.  Each "client" of the
> encoder should provide the global outstream and handle the data sent to 
> "client"
> byte-by-byte.  The syslog is only one of many possible "clients" for the 
> encoded
> data so you should not focus on that.
> 
> The byte-by-byte transfer may be too inefficient.  You could come up with a
> similar interface that transfers multiple bytes of data at a time (the full 
> packed
> data in one transfer) -- like write() vs fputc().  That will probably be 
> necessary
> for performance reasons.
> 
> 

Re: From 8.2 to 9.x??

[Brennan Ashton]

You are probably asking about the "tools" repo where you can find
kconfig-frontends and other utilities? Because those are not really
part of the OS but are rather utilities for building it and many of
them have GPL or other licenses that are not compatible with Apache,
they are still hosted on bitbucket.  There have been very few changes
in them since 8.2 and you can use master.
https://bitbucket.org/nuttx/tools

If you use the 9.1 release make sure to use the "releases/9.1" branch
in both the os and apps repository.

--Brennan

On Wed, Jul 1, 2020 at 10:39 PM Disruptive Solutions
 wrote:
>
> I scanned through the wiki off 9.1 and could it be I am missing "tools" as
> a package which is used in previous releases?
>
> Maybe it is best, as a dev/user, I just have to try and clone the 9.1
> branch (apps and nuttx) and see if my apps and drivers (which have some
> fixes in 8.2) are working and that I can still build and configure Nuttx
> like I was used to do. And that my board and apps are still working.
>
> Op do 2 jul. 2020 01:51 schreef Brennan Ashton :
>
> > In addition to what Anthony said I would recommend trying to base your
> > port off of the
> > releases/9.1 branch, there is an RC1 release right now that I would
> > expect to be the next release or very close to it.
> >
> > --Brennan
> >
> > On Wed, Jul 1, 2020 at 4:46 PM Anthony Merlino 
> > wrote:
> > >
> > > >
> > > > I just went through this with my codebase. All in all, it hasn't been
> > too
> > > > bad.
> > >
> > >
> > > I shouldn't have said that. All in all, it has been a breeze. Sure a few
> > > minor snags, but that's unavoidable.
> > >
> > > I have been waiting for the dust to settle down...
> > > >
> > >
> > > I really should be giving a big thank you to those who have been kicking
> > up
> > > the proverbially dust in the first place. Things are looking good!
> > >
> > >
> > > On Wed, Jul 1, 2020 at 7:40 PM Anthony Merlino 
> > > wrote:
> > >
> > > > Ben,
> > > >
> > > > I just went through this with my codebase. All in all, it hasn't been
> > too
> > > > bad.
> > > >
> > > > I think most of your answers can be found:
> > > >
> > > > here for 9.0
> > > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.0
> > > > and here for 9.1
> > > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1
> > > >
> > > > I'll point out a few of the issues I hit:
> > > >
> > > > I had problems with not having any heap allocated because of this
> > change:
> > > >
> > > >
> > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-RenameEXTRADEFINEStoEXTRAFLAGS
> > > >
> > > >
> > > > I also was using the set command inside of a script that I was running
> > > > using  the sh command.
> > > > As Greg pointed out for me:
> > > >
> > > > The sh command now behaves like the bash 'sh' command... it does modify
> > > >> the environment of the caller.  The old behavior of 'sh' is now called
> > > >> 'source'.  So this should work:
> > > >>
> > > >> echo "set TEST hello" >> /mnt/sdcard0/env.nsh
> > > >> source /mnt/sdcard0/env.nsh
> > > >>
> > > >> sh and source now conform to OpenGroup.org standards.
> > > >>
> > > >
> > > >
> > > > Hope this helps and best of luck.
> > > >
> > > >
> > > > On Wed, Jul 1, 2020 at 7:25 PM Disruptive Solutions <
> > > > disruptivesolution...@gmail.com> wrote:
> > > >
> > > >> I have been waiting for the dust to settle down... I am still using
> > 8.2
> > > >> (BSD). Is it ready to go and migratie to a 9.x version? Is this still
> > the
> > > >> incubator Github? Are there "user changes" which I have to know? Make
> > > >> menuconfig still works? Are drivers ported and tested? Can I migratie
> > > >> easily? Etc etc
> > > >>
> > > >> Thanks
> > > >> Ben
> > > >>
> > > >
> >

Re: From 8.2 to 9.x??

[Disruptive Solutions]

I scanned through the wiki off 9.1 and could it be I am missing "tools" as
a package which is used in previous releases?

Maybe it is best, as a dev/user, I just have to try and clone the 9.1
branch (apps and nuttx) and see if my apps and drivers (which have some
fixes in 8.2) are working and that I can still build and configure Nuttx
like I was used to do. And that my board and apps are still working.

Op do 2 jul. 2020 01:51 schreef Brennan Ashton :

> In addition to what Anthony said I would recommend trying to base your
> port off of the
> releases/9.1 branch, there is an RC1 release right now that I would
> expect to be the next release or very close to it.
>
> --Brennan
>
> On Wed, Jul 1, 2020 at 4:46 PM Anthony Merlino 
> wrote:
> >
> > >
> > > I just went through this with my codebase. All in all, it hasn't been
> too
> > > bad.
> >
> >
> > I shouldn't have said that. All in all, it has been a breeze. Sure a few
> > minor snags, but that's unavoidable.
> >
> > I have been waiting for the dust to settle down...
> > >
> >
> > I really should be giving a big thank you to those who have been kicking
> up
> > the proverbially dust in the first place. Things are looking good!
> >
> >
> > On Wed, Jul 1, 2020 at 7:40 PM Anthony Merlino 
> > wrote:
> >
> > > Ben,
> > >
> > > I just went through this with my codebase. All in all, it hasn't been
> too
> > > bad.
> > >
> > > I think most of your answers can be found:
> > >
> > > here for 9.0
> > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.0
> > > and here for 9.1
> > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1
> > >
> > > I'll point out a few of the issues I hit:
> > >
> > > I had problems with not having any heap allocated because of this
> change:
> > >
> > >
> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-RenameEXTRADEFINEStoEXTRAFLAGS
> > >
> > >
> > > I also was using the set command inside of a script that I was running
> > > using  the sh command.
> > > As Greg pointed out for me:
> > >
> > > The sh command now behaves like the bash 'sh' command... it does modify
> > >> the environment of the caller.  The old behavior of 'sh' is now called
> > >> 'source'.  So this should work:
> > >>
> > >> echo "set TEST hello" >> /mnt/sdcard0/env.nsh
> > >> source /mnt/sdcard0/env.nsh
> > >>
> > >> sh and source now conform to OpenGroup.org standards.
> > >>
> > >
> > >
> > > Hope this helps and best of luck.
> > >
> > >
> > > On Wed, Jul 1, 2020 at 7:25 PM Disruptive Solutions <
> > > disruptivesolution...@gmail.com> wrote:
> > >
> > >> I have been waiting for the dust to settle down... I am still using
> 8.2
> > >> (BSD). Is it ready to go and migratie to a 9.x version? Is this still
> the
> > >> incubator Github? Are there "user changes" which I have to know? Make
> > >> menuconfig still works? Are drivers ported and tested? Can I migratie
> > >> easily? Etc etc
> > >>
> > >> Thanks
> > >> Ben
> > >>
> > >
>

Build failed in Jenkins: NuttX-Nightly-Build #208

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 307.73 KB...]
  Building NuttX...
  Normalize sim/minibasic

Configuration/Tool: sim/tcpblaster

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
--2020-07-02 05:28:18--  
https://github.com/ARMmbed/littlefs/archive/v2.2.1.tar.gz
Resolving github.com (github.com)... 192.30.255.113
Connecting to github.com (github.com)|192.30.255.113|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/ARMmbed/littlefs/tar.gz/v2.2.1 [following]
--2020-07-02 05:28:19--  
https://codeload.github.com/ARMmbed/littlefs/tar.gz/v2.2.1
Resolving codeload.github.com (codeload.github.com)... 192.30.255.120
Connecting to codeload.github.com (codeload.github.com)|192.30.255.120|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-gzip]
Saving to: 'littlefs/v2.2.1.tar.gz'

v2.2.1.tar.gz   [<=> ]   0  --.-KB/s   
v2.2.1.tar.gz   [ <=>] 111.57K  --.-KB/sin 0.01s   

2020-07-02 05:28:19 (7.43 MB/s) - 'littlefs/v2.2.1.tar.gz' saved [114250]

  Normalize sim/tcpblaster

Configuration/Tool: sim/touchscreen

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/touchscreen

Configuration/Tool: sim/bas

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/bas

Configuration/Tool: sim/mtdpart

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/mtdpart

Configuration/Tool: sim/spiffs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/spiffs

Configuration/Tool: sim/ustream

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/ustream

Configuration/Tool: sim/userfs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/userfs

Configuration/Tool: sim/rpproxy

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
--2020-07-02 05:31:20--  
https://github.com/OpenAMP/libmetal/archive/v2020.04.0.zip
Resolving github.com (github.com)... 192.30.255.113
Connecting to github.com (github.com)|192.30.255.113|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/OpenAMP/libmetal/zip/v2020.04.0 
[following]
--2020-07-02 05:31:20--  
https://codeload.github.com/OpenAMP/libmetal/zip/v2020.04.0
Resolving codeload.github.com (codeload.github.com)... 192.30.255.120
Connecting to codeload.github.com (codeload.github.com)|192.30.255.120|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
Saving to: 'libmetal.zip'

libmetal.zip[<=> ]   0  --.-KB/s   
libmetal.zip[ <=>] 375.15K  --.-KB/sin 0.06s   

2020-07-02 05:31:20 (6.56 MB/s) - 'libmetal.zip' saved [384158]

--2020-07-02 05:31:21--  
https://github.com/OpenAMP/open-amp/archive/v2020.04.0.zip
Resolving github.com (github.com)... 192.30.255.112
Connecting to github.com (github.com)|192.30.255.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: 

RE: NXView

[Xiang Xiao]

Yes, lib_outstream_s is a better candidate.
BTW, the buffer may always need before the hardware transport driver finish the 
initialization otherwise the important initial activity will lost.

> -Original Message-
> From: Gregory Nutt 
> Sent: Thursday, July 2, 2020 10:05 AM
> To: dev@nuttx.apache.org
> Subject: Re: NXView
> 
> 
> > It's a reasonable function partitioning. How about we define an interface 
> > like syslog_channel_s between note and driver? So we can
> plug in the different transport like syslog.
> 
> The correct way to redirect streams within the OS is to use NuttX stream 
> interfaces.  Forget about systlog channels.  That is not
> relevant here.
> 
> NuttX stream interfaces are defined in include/nuttx/streams.h. you would 
> need to create an oustream and "inherits" from struct
> lib_outstream_s.  There are several examples of custom outstreams in that 
> header file, but you will create a custom one for the ram
> log.  You will need one that manages the circular ram buffer and whatever 
> other special properties.  Please follow the examples in that
> header file.
> 
> This is the universal way of redirecting byte streams within the OS. there 
> are many examples since they are used in all cases.  A good
> example is libs/libc/stdio/lib_libvsprintf.c.  That implements all of the 
> family of printf-like functions including printf, fprintf, dprintf,
> sprintf, snprintf, asprintf, etc.  It uses an outstream to send the formatted 
> data to the correct recipient:
> 
> int lib_vsprintf(FAR struct lib_outstream_s *stream,
>   FAR const IPTR char *fmt, va_list ap)
> 
> Functions like printf, fprintf, dprintf, sprintf, snprintf, asprintf, etc 
> then just setup the outstream instance and call lib_vsprintf().
> 
> The architecture should consist of a encoder that converts the sched_note 
> call data to a byte stream by serializing/marshaling a
> packed data structure.  It should then use a global outstream to send the 
> data.  Each "client" of the encoder should provide the global
> outstream and handle the data sent to "client" byte-by-byte.  The syslog is 
> only one of many possible "clients" for the encoded data
> so you should not focus on that.
> 
> The byte-by-byte transfer may be too inefficient.  You could come up with a 
> similar interface that transfers multiple bytes of data at a
> time (the full packed data in one transfer) -- like write() vs fputc().  That 
> will probably be necessary for performance reasons.
> 
> 

Re: NXView

[Gregory Nutt]

It's a reasonable function partitioning. How about we define an interface like 
syslog_channel_s between note and driver? So we can plug in the different 
transport like syslog.


The correct way to redirect streams within the OS is to use NuttX stream 
interfaces.  Forget about systlog channels.  That is not relevant here.


NuttX stream interfaces are defined in include/nuttx/streams.h. you 
would need to create an oustream and "inherits" from struct 
lib_outstream_s.  There are several examples of custom outstreams in 
that header file, but you will create a custom one for the ram log.  You 
will need one that manages the circular ram buffer and whatever other 
special properties.  Please follow the examples in that header file.


This is the universal way of redirecting byte streams within the OS.  
there are many examples since they are used in all cases.  A good 
example is libs/libc/stdio/lib_libvsprintf.c.  That implements all of 
the family of printf-like functions including printf, fprintf, dprintf, 
sprintf, snprintf, asprintf, etc.  It uses an outstream to send the 
formatted data to the correct recipient:


   int lib_vsprintf(FAR struct lib_outstream_s *stream,
 FAR const IPTR char *fmt, va_list ap)

Functions like printf, fprintf, dprintf, sprintf, snprintf, asprintf, 
etc then just setup the outstream instance and call lib_vsprintf().


The architecture should consist of a encoder that converts the 
sched_note call data to a byte stream by serializing/marshaling a packed 
data structure.  It should then use a global outstream to send the 
data.  Each "client" of the encoder should provide the global outstream 
and handle the data sent to "client" byte-by-byte.  The syslog is only 
one of many possible "clients" for the encoded data so you should not 
focus on that.


The byte-by-byte transfer may be too inefficient.  You could come up 
with a similar interface that transfers multiple bytes of data at a time 
(the full packed data in one transfer) -- like write() vs fputc().  That 
will probably be necessary for performance reasons.

RE: NXView

[Nakamura, Yuuichi (Sony)]

Thanks for your comment.
Then it may be better to separate the buffer management logic into another file 
like sched_note_buffer.c.
I'll try it.

> -Original Message-
> From: Xiang Xiao 
> Sent: Wednesday, July 1, 2020 10:54 PM
> To: dev@nuttx.apache.org
> Subject: RE: NXView
> 
> It's a reasonable function partitioning. How about we define an interface like
> syslog_channel_s between note and driver? So we can plug in the different
> transport like syslog.
> 
> > -Original Message-
> > From: Nakamura, Yuuichi (Sony) 
> > Sent: Wednesday, July 1, 2020 3:01 PM
> > To: dev@nuttx.apache.org
> > Cc: Nakamura, Yuuichi (Sony) 
> > Subject: RE: NXView
> >
> > Hi all,
> >
> > After merging my syscall instrumentation patch into
> > feature/syscall-instrumentation branch, I had considered how to incorporate
> my task trace support into the mainline.
> >
> > Currently sched_note.c has the codes to generate notes and buffer
> management functions.
> > notes are generated all the time if configured to be enabled.
> > (attached fig.1)
> >
> > In task tracer, I add the filter logic for some note types, and all notes 
> > have to be
> enabled explicitly.
> > The buffer management functions are also used by the task tracer, but the
> hardware solution doesn't require them.
> >
> > So, I propose the new configuration
> CONFIG_SCHED_INSTRUMENTATION_FILTER in sched_note.c.
> > CONFIG_SCHED_INSTRUMENTATION_FILTER only enables the filter logic in
> each note types.
> > And change CONFIG_SCHED_INSTRUMENTATION_BUFFER to make enable
> only buffer management logic, not note generation.
> > (attached fig.2)
> >
> > If hardware solution needs only filter logic, by enabling
> > CONFIG_SCHED_INSTRUMENTATION_FILTER and disabling
> CONFIG_SCHED_INSTRUMENTATION_BUFFER can realize it.
> > sched_note_add() (previously note_add() static function in
> > sched_note.c) is called when some kernel instrumentation event occured
> > and it can be implemented to send the note data to the external
> > hardware device. (attached fig.3)
> >
> > The task tracer defines both CONFIG_SCHED_INSTRUMENTATION_FILTER
> and CONFIG_SCHED_INSTRUMENTATION_BUFFER.
> > And if only CONFIG_SCHED_INSTRUMENTATION_BUFFER is defined, the
> existing sched_note specification remains.
> >
> > How about this proposal ?
> > I'm fixing my task trace code as the patch of existing sched_note.c and
> note_driver.c.
> > After that, I'd like to send new pull request to 
> > feature/syscall-instrumentation
> branch for the review.
> >
> > Thanks,
> > Yuuichi Nakamura
> >
> > > -Original Message-
> > > From: Nakamura, Yuuichi (Sony)
> > > Sent: Wednesday, June 17, 2020 2:43 PM
> > > To: dev@nuttx.apache.org
> > > Cc: Nakamura, Yuuichi (Sony) 
> > > Subject: RE: NXView
> > >
> > > Thanks for valuable comments.
> > > I have no objection to your advice that overlapping the similar
> > > implementation should be avoided.
> > > Let me make change the current implementation into the extension of
> > > the existing codes, and if there are any problems in extending, please 
> > > let me
> discuss again.
> > >
> > > Regarding to another issue, the place of the application side code,
> > > it is because I have wanted to implement  trace cmd ""
> > > It gets the trace while executing the specified command line like
> > > "time" command of nsh.
> > > It requires nsh_parse() nshlib internal API.
> > >
> > > Thanks,
> > > Yuuichi Nakamura
> > >
> > > > -Original Message-
> > > > From: Gregory Nutt 
> > > > Sent: Wednesday, June 17, 2020 11:13 AM
> > > > To: dev@nuttx.apache.org
> > > > Subject: Re: NXView
> > > >
> > > >
> > > > > The major differences are:
> > > > >
> > > > > - Different trace data format between the accumulated data in
> > > > > the memory and
> > > > /dev/tracer output
> > > > >It is because to reduce the trace data size in the memory.
> > > > > The accumulated
> > > > data contains packed (not aligned) values and
> > > > >task is recorded by its PID, not the name. The correspondence
> > > > > between PID
> > > > and task name string is hold in the separated task name buffer.
> > > > >On the other hand, the output from /dev/tracer contains
> > > > > aligned words and
> > > > contains the task name string for each trace entries.
> > > > >It is because easy to handle the data by the application code
> > > > > (nsh trace
> > > > command).
> > > >
> > > > That is a trivial difference and there are some misconceptions.
> > > >
> > > > The structures can be packed by simply adding the packed attribute
> > > > to the structures.  That does not justify a redesign.
> > > >
> > > > The current implementation does *not* use the task name, it uses
> > > > the pid.  The task name is provided only when the task is created.
> > > > The provides the associated between pid and name. Thereafter only the 
> > > > pid
> is uses.
> > > >
> > > > Your implementation has two much overlap and should not come
> > > > upstream as a separate implementation.  

Re: From 8.2 to 9.x??

[Brennan Ashton]

In addition to what Anthony said I would recommend trying to base your
port off of the
releases/9.1 branch, there is an RC1 release right now that I would
expect to be the next release or very close to it.

--Brennan

On Wed, Jul 1, 2020 at 4:46 PM Anthony Merlino  wrote:
>
> >
> > I just went through this with my codebase. All in all, it hasn't been too
> > bad.
>
>
> I shouldn't have said that. All in all, it has been a breeze. Sure a few
> minor snags, but that's unavoidable.
>
> I have been waiting for the dust to settle down...
> >
>
> I really should be giving a big thank you to those who have been kicking up
> the proverbially dust in the first place. Things are looking good!
>
>
> On Wed, Jul 1, 2020 at 7:40 PM Anthony Merlino 
> wrote:
>
> > Ben,
> >
> > I just went through this with my codebase. All in all, it hasn't been too
> > bad.
> >
> > I think most of your answers can be found:
> >
> > here for 9.0
> > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.0
> > and here for 9.1
> > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1
> >
> > I'll point out a few of the issues I hit:
> >
> > I had problems with not having any heap allocated because of this change:
> >
> > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-RenameEXTRADEFINEStoEXTRAFLAGS
> >
> >
> > I also was using the set command inside of a script that I was running
> > using  the sh command.
> > As Greg pointed out for me:
> >
> > The sh command now behaves like the bash 'sh' command... it does modify
> >> the environment of the caller.  The old behavior of 'sh' is now called
> >> 'source'.  So this should work:
> >>
> >> echo "set TEST hello" >> /mnt/sdcard0/env.nsh
> >> source /mnt/sdcard0/env.nsh
> >>
> >> sh and source now conform to OpenGroup.org standards.
> >>
> >
> >
> > Hope this helps and best of luck.
> >
> >
> > On Wed, Jul 1, 2020 at 7:25 PM Disruptive Solutions <
> > disruptivesolution...@gmail.com> wrote:
> >
> >> I have been waiting for the dust to settle down... I am still using 8.2
> >> (BSD). Is it ready to go and migratie to a 9.x version? Is this still the
> >> incubator Github? Are there "user changes" which I have to know? Make
> >> menuconfig still works? Are drivers ported and tested? Can I migratie
> >> easily? Etc etc
> >>
> >> Thanks
> >> Ben
> >>
> >

Re: From 8.2 to 9.x??

[Anthony Merlino]

>
> I just went through this with my codebase. All in all, it hasn't been too
> bad.


I shouldn't have said that. All in all, it has been a breeze. Sure a few
minor snags, but that's unavoidable.

I have been waiting for the dust to settle down...
>

I really should be giving a big thank you to those who have been kicking up
the proverbially dust in the first place. Things are looking good!


On Wed, Jul 1, 2020 at 7:40 PM Anthony Merlino 
wrote:

> Ben,
>
> I just went through this with my codebase. All in all, it hasn't been too
> bad.
>
> I think most of your answers can be found:
>
> here for 9.0
> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.0
> and here for 9.1
> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1
>
> I'll point out a few of the issues I hit:
>
> I had problems with not having any heap allocated because of this change:
>
> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-RenameEXTRADEFINEStoEXTRAFLAGS
>
>
> I also was using the set command inside of a script that I was running
> using  the sh command.
> As Greg pointed out for me:
>
> The sh command now behaves like the bash 'sh' command... it does modify
>> the environment of the caller.  The old behavior of 'sh' is now called
>> 'source'.  So this should work:
>>
>> echo "set TEST hello" >> /mnt/sdcard0/env.nsh
>> source /mnt/sdcard0/env.nsh
>>
>> sh and source now conform to OpenGroup.org standards.
>>
>
>
> Hope this helps and best of luck.
>
>
> On Wed, Jul 1, 2020 at 7:25 PM Disruptive Solutions <
> disruptivesolution...@gmail.com> wrote:
>
>> I have been waiting for the dust to settle down... I am still using 8.2
>> (BSD). Is it ready to go and migratie to a 9.x version? Is this still the
>> incubator Github? Are there "user changes" which I have to know? Make
>> menuconfig still works? Are drivers ported and tested? Can I migratie
>> easily? Etc etc
>>
>> Thanks
>> Ben
>>
>

Re: From 8.2 to 9.x??

[Anthony Merlino]

Ben,

I just went through this with my codebase. All in all, it hasn't been too
bad.

I think most of your answers can be found:

here for 9.0
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.0
and here for 9.1
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1

I'll point out a few of the issues I hit:

I had problems with not having any heap allocated because of this change:
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-RenameEXTRADEFINEStoEXTRAFLAGS


I also was using the set command inside of a script that I was running
using  the sh command.
As Greg pointed out for me:

The sh command now behaves like the bash 'sh' command... it does modify
> the environment of the caller.  The old behavior of 'sh' is now called
> 'source'.  So this should work:
>
> echo "set TEST hello" >> /mnt/sdcard0/env.nsh
> source /mnt/sdcard0/env.nsh
>
> sh and source now conform to OpenGroup.org standards.
>


Hope this helps and best of luck.


On Wed, Jul 1, 2020 at 7:25 PM Disruptive Solutions <
disruptivesolution...@gmail.com> wrote:

> I have been waiting for the dust to settle down... I am still using 8.2
> (BSD). Is it ready to go and migratie to a 9.x version? Is this still the
> incubator Github? Are there "user changes" which I have to know? Make
> menuconfig still works? Are drivers ported and tested? Can I migratie
> easily? Etc etc
>
> Thanks
> Ben
>

From 8.2 to 9.x??

[Disruptive Solutions]

I have been waiting for the dust to settle down... I am still using 8.2
(BSD). Is it ready to go and migratie to a 9.x version? Is this still the
incubator Github? Are there "user changes" which I have to know? Make
menuconfig still works? Are drivers ported and tested? Can I migratie
easily? Etc etc

Thanks
Ben

Re: Help with Apache Github Invite

[Anthony Merlino]

Justin,

According to Github, I have 2FA enabled. It's been enabled for months. As
has my linking of ASF and Github user name.

You need to wait until you have been added to the ASF gitHub account before
> doing the last step.
>

What are you calling the last step? What do I have to do to be added to the
ASF github account? I thought I had done everything I was supposed to do.

Best,
Anthony






On Wed, Jul 1, 2020 at 7:04 PM Justin Mclean 
wrote:

> HI,
>
> You need to wait until you have been added to the ASF gitHub account
> before doing the last step. The usual issue is not setting up 2FA.
>
> Thanks,
> Justin

Re: Help with Apache Github Invite

[Justin Mclean]

HI,

You need to wait until you have been added to the ASF gitHub account before 
doing the last step. The usual issue is not setting up 2FA.

Thanks,
Justin

Re: Help with Apache Github Invite

[Abdelatif Guettouche]

The necessary steps are here:
https://cwiki.apache.org/confluence/display/NUTTX/Accessing+Apache+GitHub+as+a+Committer

On Wed, Jul 1, 2020 at 10:52 PM Brennan Ashton
 wrote:
>
> Anthony,
> Have you been able to use this and do you see the three checkboxes?
> https://gitbox.apache.org/setup/
>
> On Wed, Jul 1, 2020 at 2:42 PM Anthony Merlino  wrote:
> >
> > Hi,
> >
> > I still can't seem to get an invite from the Apache Github account, despite
> > having 2FA enabled on Github, and linking my Github user name through the
> > self-service portal. I have had this problem since we moved to Apache, but
> > I haven't needed access until now.
> >
> > Who is the right person to ask with help getting the Github invite? Is this
> > a us...@infra.apache.org type of request?
> >
> > Thanks,
> > Anthony

Re: Help with Apache Github Invite

[Brennan Ashton]

Anthony,
Have you been able to use this and do you see the three checkboxes?
https://gitbox.apache.org/setup/

On Wed, Jul 1, 2020 at 2:42 PM Anthony Merlino  wrote:
>
> Hi,
>
> I still can't seem to get an invite from the Apache Github account, despite
> having 2FA enabled on Github, and linking my Github user name through the
> self-service portal. I have had this problem since we moved to Apache, but
> I haven't needed access until now.
>
> Who is the right person to ask with help getting the Github invite? Is this
> a us...@infra.apache.org type of request?
>
> Thanks,
> Anthony

Re: Help with Apache Github Invite

[Gregory Nutt]

I still can't seem to get an invite from the Apache Github account, despite
having 2FA enabled on Github, and linking my Github user name through the
self-service portal. I have had this problem since we moved to Apache, but
I haven't needed access until now.

Who is the right person to ask with help getting the Github invite? Is this
a us...@infra.apache.org type of request?


I don't know who can help.  I had problems the first time I tried and 
found, for me, the secret was that I has to log off from github then log 
back in after I did the configuration.  I don't think you can configure 
the 2-factor login while you are logged in.

Help with Apache Github Invite

[Anthony Merlino]

Hi,

I still can't seem to get an invite from the Apache Github account, despite
having 2FA enabled on Github, and linking my Github user name through the
self-service portal. I have had this problem since we moved to Apache, but
I haven't needed access until now.

Who is the right person to ask with help getting the Github invite? Is this
a us...@infra.apache.org type of request?

Thanks,
Anthony

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release

[Gregory Nutt]

Comparing with V9.0:

NuttX 9.0

$ arm-none-eabi-size nuttx
textdata bss dec hex filename
   68624 1042496   71224   11638 nuttx


NuttShell (NSH) NuttX-9.0.0
nsh> free
  total   used   freelargest
Umem:   192976   7536 185440 125248
nsh>


--


NuttX 9.1 RC1

$ arm-none-eabi-size nuttx
text   data bss dec hex filename
   694681042476   72048   11970 nuttx


NuttShell (NSH) NuttX-9.1.0
nsh> free
  total   used   freelargest
Umem:   192992   7536 185456 125264
nsh>
So the FLASH footprint still grew by about 800 bytes.  If that trend 
continues indefinitely it will be quite a large OS in the future. 
Although that is still quite a lot is is more palatable than before.

Re: CAN driver and critical section use

[Gregory Nutt]

I wonder if it is right to call nxsem_wait while in critical section?
Yes, it is fine to do that.  The OS will exit the critical section while 
waiting.

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release

[Alan Carvalho de Assis]

Hi Brennan,

My vote: +1

Tested on STM32F4Discovery.

Comparing with V9.0:

NuttX 9.0

$ arm-none-eabi-size nuttx
   textdata bss dec hex filename
  68624 1042496   71224   11638 nuttx


NuttShell (NSH) NuttX-9.0.0
nsh> free
 total   used   freelargest
Umem:   192976   7536 185440 125248
nsh>


--


NuttX 9.1 RC1

$ arm-none-eabi-size nuttx
   textdata bss dec hex filename
  69468 1042476   72048   11970 nuttx


NuttShell (NSH) NuttX-9.1.0
nsh> free
 total   used   freelargest
Umem:   192992   7536 185456 125264
nsh>

Good work guys!

BR,

Alan

On 6/30/20, Brennan Ashton  wrote:
> Hello all,
> Apache NuttX (Incubating) 9.1.0 has been staged under [1] and it's time
> to vote on accepting it for release. If approved we will seek final
> release approval from the IPMC. Voting will be open for 72hr.  This RC
> replaces RC0 which was never released due to several bugs found durring
> the voting period.
>
> Because this project targets embedded systems there is more complexity
> involved in the build process. Two starting points:
>  * README.txt -- This is found in the Apache NuttX source and is
> extensive.
>  * Unofficial NuttX Companion -- Located at [3], this is a currently
> unofficial
>opinionated guide maintained by some of the project committers.
>
> 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 [4]
> "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 [5].
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [5])
> [ ] -1 reject (explanation required)
>
> Thank you all,
> Brennan Ashton
>
> SCM Information:
>   Release tag: releases/9.1.0-RC1
>   Hash for the release incubating-nuttx tag:
> 201f920c3b5de64e0eb8c8a76a50ae2fcc4f6a2e
>   Hash for the release incubating-nuttx-apps tag:
> d483748923d4ad77e0d1f98158548b75f65b9a77
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.1.0-RC1/
> [2]
> https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-9.1.0-RC1/ReleaseNotes
> [3] https://nuttx-companion.readthedocs.io/en/latest/
> [4] https://www.apache.org/dev/release.html#approving-a-release
> [5]
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
>
>

CAN driver and critical section use

[Oleg Evseev]

Hi all,

I wonder if it is right to call nxsem_wait while in critical section?

Regardless of the answer I also wonder why can_read() and can_write()
enter_critical_section before accessing the received FIFO, but can_poll
doesn't?

Can this be related to getting into DEBUGASSERT(pholder != NULL) in
function nxsem_allocholder in file semaphore/sem_holder.c while in poll on
can?

-- 
With regards, Oleg.

script to validate NuttX release candidates

[Adam Feuer]

Hi,

In case anyone's interested, I created a script to validate NuttX release
candidates, it automates some of the steps described in Validating a staged
release
.
It downloads the files, checks the SHA512 and GPG signatures, and checks
required files.

You still need to manually configure, build, and install the release.

https://github.com/apache/incubator-nuttx/pull/1349

-adam
-- 
Adam Feuer 

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release

[Adam Feuer]

+1

Ran through the release checklist, SHAs ok, GPG sigs ok, required files
there.
I built nuttx for SAMA5D2-XULT (SAMA5D27) and loaded it, it boots and works
ok.

-adam

On Wed, Jul 1, 2020 at 4:41 AM Jerpelea, Alin 
wrote:

> Hi,
>
> +1 from me
>
>   *
> hashes match
>   *
> LICENSE, DISCLAIMER and NOTICE exist
>   *
> build spresense board and seems ok
>
>
> 
> Från: Abdelatif Guettouche 
> Skickat: den 1 juli 2020 14:35
> Till: dev@nuttx.apache.org 
> Ämne: Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release
>
> Hi,
> +1 for me, I checked:
> - Incubating in name
> - Signatures and hashes for both TARs are OK
> - LICENSE, DISCLAIMER and NOTICE exist
> - Can build from source.
>
> Thank you for your work, Brennan!
>
> On Tue, Jun 30, 2020 at 6:58 AM Brennan Ashton 
> wrote:
> >
> > Hello all,
> > Apache NuttX (Incubating) 9.1.0 has been staged under [1] and it's time
> > to vote on accepting it for release. If approved we will seek final
> > release approval from the IPMC. Voting will be open for 72hr.  This RC
> > replaces RC0 which was never released due to several bugs found durring
> > the voting period.
> >
> > Because this project targets embedded systems there is more complexity
> > involved in the build process. Two starting points:
> >  * README.txt -- This is found in the Apache NuttX source and is
> > extensive.
> >  * Unofficial NuttX Companion -- Located at [3], this is a currently
> > unofficial
> >opinionated guide maintained by some of the project committers.
> >
> > 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 [4]
> > "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 [5].
> >
> > [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> > items in [5])
> > [ ] -1 reject (explanation required)
> >
> > Thank you all,
> > Brennan Ashton
> >
> > SCM Information:
> >   Release tag: releases/9.1.0-RC1
> >   Hash for the release incubating-nuttx tag:
> > 201f920c3b5de64e0eb8c8a76a50ae2fcc4f6a2e
> >   Hash for the release incubating-nuttx-apps tag:
> > d483748923d4ad77e0d1f98158548b75f65b9a77
> >
> > [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dist.apache.org_repos_dist_dev_incubator_nuttx_9.1.0-2DRC1_=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=Y0tSVm2CF-YebYBa823UNd7hJ2Vi2A5SUAyhWnv7Gdw=
> > [2]
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_apache_incubator-2Dnuttx_nuttx-2D9.1.0-2DRC1_ReleaseNotes=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=kEH1URCIGyAHMk5iogYe3ClMSPUc9tZeH3Itlo6qoec=
> > [3]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__nuttx-2Dcompanion.readthedocs.io_en_latest_=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=iQ6KKFX9DmtiP-AEudIAsYhxIJScMFaP4WIMfF1PL08=
> > [4]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.apache.org_dev_release.html-23approving-2Da-2Drelease=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=g0xT5Mh8tFdW2MrZsQqjGDm15xIH7hxFJuVD1BZXQjg=
> > [5]
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_NUTTX_Validating-2Ba-2Bstaged-2BRelease=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=VeCYBTgAJpnIOqLZJYfNtIinMUYYiApT3UWeP91kuxs=
> >
>


-- 
Adam Feuer 

RE: NXView

[Xiang Xiao]

It's a reasonable function partitioning. How about we define an interface like 
syslog_channel_s between note and driver? So we can plug in the different 
transport like syslog.

> -Original Message-
> From: Nakamura, Yuuichi (Sony) 
> Sent: Wednesday, July 1, 2020 3:01 PM
> To: dev@nuttx.apache.org
> Cc: Nakamura, Yuuichi (Sony) 
> Subject: RE: NXView
> 
> Hi all,
> 
> After merging my syscall instrumentation patch into 
> feature/syscall-instrumentation branch, I had considered how to incorporate my
> task trace support into the mainline.
> 
> Currently sched_note.c has the codes to generate notes and buffer management 
> functions.
> notes are generated all the time if configured to be enabled. (attached fig.1)
> 
> In task tracer, I add the filter logic for some note types, and all notes 
> have to be enabled explicitly.
> The buffer management functions are also used by the task tracer, but the 
> hardware solution doesn't require them.
> 
> So, I propose the new configuration CONFIG_SCHED_INSTRUMENTATION_FILTER in 
> sched_note.c.
> CONFIG_SCHED_INSTRUMENTATION_FILTER only enables the filter logic in each 
> note types.
> And change CONFIG_SCHED_INSTRUMENTATION_BUFFER to make enable only buffer 
> management logic, not note generation.
> (attached fig.2)
> 
> If hardware solution needs only filter logic, by enabling 
> CONFIG_SCHED_INSTRUMENTATION_FILTER and disabling
> CONFIG_SCHED_INSTRUMENTATION_BUFFER can realize it.
> sched_note_add() (previously note_add() static function in sched_note.c) is 
> called when some kernel instrumentation event occured
> and it can be implemented to send the note data to the external hardware 
> device. (attached fig.3)
> 
> The task tracer defines both CONFIG_SCHED_INSTRUMENTATION_FILTER and 
> CONFIG_SCHED_INSTRUMENTATION_BUFFER.
> And if only CONFIG_SCHED_INSTRUMENTATION_BUFFER is defined, the existing 
> sched_note specification remains.
> 
> How about this proposal ?
> I'm fixing my task trace code as the patch of existing sched_note.c and 
> note_driver.c.
> After that, I'd like to send new pull request to 
> feature/syscall-instrumentation branch for the review.
> 
> Thanks,
> Yuuichi Nakamura
> 
> > -Original Message-
> > From: Nakamura, Yuuichi (Sony)
> > Sent: Wednesday, June 17, 2020 2:43 PM
> > To: dev@nuttx.apache.org
> > Cc: Nakamura, Yuuichi (Sony) 
> > Subject: RE: NXView
> >
> > Thanks for valuable comments.
> > I have no objection to your advice that overlapping the similar
> > implementation should be avoided.
> > Let me make change the current implementation into the extension of
> > the existing codes, and if there are any problems in extending, please let 
> > me discuss again.
> >
> > Regarding to another issue, the place of the application side code, it
> > is because I have wanted to implement  trace cmd ""
> > It gets the trace while executing the specified command line like
> > "time" command of nsh.
> > It requires nsh_parse() nshlib internal API.
> >
> > Thanks,
> > Yuuichi Nakamura
> >
> > > -Original Message-
> > > From: Gregory Nutt 
> > > Sent: Wednesday, June 17, 2020 11:13 AM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: NXView
> > >
> > >
> > > > The major differences are:
> > > >
> > > > - Different trace data format between the accumulated data in the
> > > > memory and
> > > /dev/tracer output
> > > >It is because to reduce the trace data size in the memory. The
> > > > accumulated
> > > data contains packed (not aligned) values and
> > > >task is recorded by its PID, not the name. The correspondence
> > > > between PID
> > > and task name string is hold in the separated task name buffer.
> > > >On the other hand, the output from /dev/tracer contains aligned
> > > > words and
> > > contains the task name string for each trace entries.
> > > >It is because easy to handle the data by the application code
> > > > (nsh trace
> > > command).
> > >
> > > That is a trivial difference and there are some misconceptions.
> > >
> > > The structures can be packed by simply adding the packed attribute
> > > to the structures.  That does not justify a redesign.
> > >
> > > The current implementation does *not* use the task name, it uses the
> > > pid.  The task name is provided only when the task is created.  The
> > > provides the associated between pid and name. Thereafter only the pid is 
> > > uses.
> > >
> > > Your implementation has two much overlap and should not come
> > > upstream as a separate implementation.  Extensions and improvements
> > > to the existing implementation are welcome, however.
> > >
> > > Greg

Re: Board report due by July 1st

[Abdelatif Guettouche]

> Thanks, the changes look good. I'm away from my computer today; could you
> submit the report?

I did so.  We've still got time to change anything if need be.


On Wed, Jul 1, 2020 at 12:54 PM Nathan Hartman  wrote:
>
> On Wed, Jul 1, 2020 at 7:23 AM Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
>
> > Hi,
> >
> > I filled in some blanks.  The report is due today but we still have
> > some time for last minute changes.
>
>
> Thanks, the changes look good. I'm away from my computer today; could you
> submit the report?
>
> Thanks!
> Nathan

Re: Board report due by July 1st

[Nathan Hartman]

On Wed, Jul 1, 2020 at 7:23 AM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> Hi,
>
> I filled in some blanks.  The report is due today but we still have
> some time for last minute changes.


Thanks, the changes look good. I'm away from my computer today; could you
submit the report?

Thanks!
Nathan

Sv: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release

[Jerpelea, Alin]

Hi,

+1 from me

  *
hashes match
  *
LICENSE, DISCLAIMER and NOTICE exist
  *
build spresense board and seems ok



Från: Abdelatif Guettouche 
Skickat: den 1 juli 2020 14:35
Till: dev@nuttx.apache.org 
Ämne: Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release

Hi,
+1 for me, I checked:
- Incubating in name
- Signatures and hashes for both TARs are OK
- LICENSE, DISCLAIMER and NOTICE exist
- Can build from source.

Thank you for your work, Brennan!

On Tue, Jun 30, 2020 at 6:58 AM Brennan Ashton  wrote:
>
> Hello all,
> Apache NuttX (Incubating) 9.1.0 has been staged under [1] and it's time
> to vote on accepting it for release. If approved we will seek final
> release approval from the IPMC. Voting will be open for 72hr.  This RC
> replaces RC0 which was never released due to several bugs found durring
> the voting period.
>
> Because this project targets embedded systems there is more complexity
> involved in the build process. Two starting points:
>  * README.txt -- This is found in the Apache NuttX source and is
> extensive.
>  * Unofficial NuttX Companion -- Located at [3], this is a currently
> unofficial
>opinionated guide maintained by some of the project committers.
>
> 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 [4]
> "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 [5].
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [5])
> [ ] -1 reject (explanation required)
>
> Thank you all,
> Brennan Ashton
>
> SCM Information:
>   Release tag: releases/9.1.0-RC1
>   Hash for the release incubating-nuttx tag:
> 201f920c3b5de64e0eb8c8a76a50ae2fcc4f6a2e
>   Hash for the release incubating-nuttx-apps tag:
> d483748923d4ad77e0d1f98158548b75f65b9a77
>
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dist.apache.org_repos_dist_dev_incubator_nuttx_9.1.0-2DRC1_=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=Y0tSVm2CF-YebYBa823UNd7hJ2Vi2A5SUAyhWnv7Gdw=
> [2]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_apache_incubator-2Dnuttx_nuttx-2D9.1.0-2DRC1_ReleaseNotes=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=kEH1URCIGyAHMk5iogYe3ClMSPUc9tZeH3Itlo6qoec=
> [3] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__nuttx-2Dcompanion.readthedocs.io_en_latest_=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=iQ6KKFX9DmtiP-AEudIAsYhxIJScMFaP4WIMfF1PL08=
> [4] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.apache.org_dev_release.html-23approving-2Da-2Drelease=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=g0xT5Mh8tFdW2MrZsQqjGDm15xIH7hxFJuVD1BZXQjg=
> [5]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_NUTTX_Validating-2Ba-2Bstaged-2BRelease=DwIBaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE=wCjDPfVu4jsGF5DRTbrxss5BggITyWdmP3EyHlWz9GA=VeCYBTgAJpnIOqLZJYfNtIinMUYYiApT3UWeP91kuxs=
>

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release

[Abdelatif Guettouche]

Hi,
+1 for me, I checked:
- Incubating in name
- Signatures and hashes for both TARs are OK
- LICENSE, DISCLAIMER and NOTICE exist
- Can build from source.

Thank you for your work, Brennan!

On Tue, Jun 30, 2020 at 6:58 AM Brennan Ashton  wrote:
>
> Hello all,
> Apache NuttX (Incubating) 9.1.0 has been staged under [1] and it's time
> to vote on accepting it for release. If approved we will seek final
> release approval from the IPMC. Voting will be open for 72hr.  This RC
> replaces RC0 which was never released due to several bugs found durring
> the voting period.
>
> Because this project targets embedded systems there is more complexity
> involved in the build process. Two starting points:
>  * README.txt -- This is found in the Apache NuttX source and is
> extensive.
>  * Unofficial NuttX Companion -- Located at [3], this is a currently
> unofficial
>opinionated guide maintained by some of the project committers.
>
> 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 [4]
> "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 [5].
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [5])
> [ ] -1 reject (explanation required)
>
> Thank you all,
> Brennan Ashton
>
> SCM Information:
>   Release tag: releases/9.1.0-RC1
>   Hash for the release incubating-nuttx tag:
> 201f920c3b5de64e0eb8c8a76a50ae2fcc4f6a2e
>   Hash for the release incubating-nuttx-apps tag:
> d483748923d4ad77e0d1f98158548b75f65b9a77
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.1.0-RC1/
> [2]
> https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-9.1.0-RC1/ReleaseNotes
> [3] https://nuttx-companion.readthedocs.io/en/latest/
> [4] https://www.apache.org/dev/release.html#approving-a-release
> [5]
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
>

Re: Board report due by July 1st

[Abdelatif Guettouche]

Hi,

I filled in some blanks.  The report is due today but we still have
some time for last minute changes.

On Mon, Jun 22, 2020 at 4:03 PM Nathan Hartman  wrote:
>
> We are scheduled to submit our board report by July 1st.
>
> I have created a Confluence page [1] with some initial content. Please
> review and make any additions/changes/corrections.
>
> [1] https://cwiki.apache.org/confluence/display/NUTTX/July+2020
>
> Cheers,
> Nathan