You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2020/09/11 04:05:52 UTC

[GitHub] [incubator-nuttx] patacongo commented on pull request #1747: sched: Rename note_add to sched_note_add

patacongo commented on pull request #1747:
URL: https://github.com/apache/incubator-nuttx/pull/1747#issuecomment-690861100


   
   First, the naming is totally wrong.  You cannot push to or pop from a FIFO.  That is incorrect.  Push and pop refer only stacks (LIFOs).  Very amateurish.Sent from Samsung tablet.
   -------- Original message --------From: Xiang Xiao <no...@github.com> Date: 9/10/20  9:20 PM  (GMT-06:00) To: apache/incubator-nuttx <in...@noreply.github.com> Cc: Subscribed <su...@noreply.github.com> Subject: Re: [apache/incubator-nuttx] sched: Rename note_add to sched_note_add (#1747) 
   
   I am referring to changing 4e45a66
   This schedule_note_xxxx interface has been used for years. It is an API to board-specific logic it does not require a de-multiplexer the APIs are focused. Please do not misinterpret the note: "NOTE: This is an internal OS interfaces and are called at at very critical locations in the OS." (it is the same as SPI selects that are defined by the board)
   What it means is It is an API to board-specific logic that should NOT waist any time.
   
   The board interface may change sometime if there is a good techinical reason, for example here is your change:
   commit ed5d00edd877c0489b8281c476a5d3dd35628bca
   Author: David Sidrane <Da...@NscDg.com>
   Date:   Tue Aug 4 10:14:54 2020 -0700
   
       board_crashdump:use consistent type from outer function for file name
   
   which also break other people's code. Should we forbid this change and revert it? I don't think so, because the change is good from the technology perspective.
   
   The proposal of 1) queuing a data type and 2) de-queuing it and 3) de-multiplexing it not useful in the original intent:
   That is to note an event of a specific kind.
   Feel free to extend the use case but not change the interface. That is a breaking change.
   
   The break can't avoid to get the better design or fix the new challenge, here is the partial list the recent change which break the compatibility in some way:
   797bf44
   797bf44
   a0ce81d
   875828b
   f92dba2
   153eee6
   c2244a2
   What should we do with these patches?
   
   —You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org