Bye Bye Eggs :-(

[Sterling Hughes]

Hey,

I have implemented the bug report here: 
https://issues.apache.org/jira/browse/MYNEWT-71


I think everyone has noticed that on-boarding new users becomes 
difficult because we use custom terms for packages, package lists and 
repositories.  While I personally like these terms (I named them that 
way), I think we wan the package and build system to be as easy to use 
as possible, and keeping track of these seems to be creating too much of 
a hurdle.


So, I have a bunch of mondo commits to rename these.  They are low risk, 
and I've tested them.


When I commit, in order to maintain your existing targets, you will need 
to do the following:


- rename .nest in larva to .repo (this is custom per install, so I 
can't move this for you)


- rename nest.db to repo.db in .repo

- rename clutches/ directory pkg-lists/ in .repo

Everything else should operate well, unless you have changes to egg.yml 
files that are uncommitted.  You will need to manually port those over.


Also, as a part of this commit, I've removed .git from the newt import 
path.  It seems like the majority of people are able to go get this 
without the .git, and it was causing conflicts with newtmgr.  (*)


I'll push these to origin master this evening if nobody has objections.

Sterling

(*) These will eventually be moved, again, when Todd adds 
mynewt.apache.org support.

Address Randomization in net/nimble

[Sterling Hughes]

Howdy:

How hard is it to get address randomization in the net/nimble stack?  I 
realize that full Bluetooth security is probably a month or two away, 
but would it be possible to just provide the randomization component of 
it, for privacy and tracking considerations?


Sterling

Re: [jira] [Resolved] (MYNEWT-16) need to be able use json without floating points

[Sterling Hughes]

On 2/6/16 11:45 AM, Marko Kiiskila (JIRA) wrote:


  [ 
https://issues.apache.org/jira/browse/MYNEWT-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marko Kiiskila resolved MYNEWT-16.
--
 Resolution: Fixed

If you want it, define FLOAT_SUPPORT either in project.cflags,
or in target cflags.



I think this should be a capability (that generates a cflag), not a cflag.

To me the difference is a cflag is something that a single package might 
expect, whereas we should start having a few defined "capabilities" 
(SHELL, NEWTMGR, FLOAT_SUPPORT), that then generate different cflags 
based on the egg being compiled.


Perhaps this isn't the best mechanism, but I'm not sure just writing 
cflags is either...


Thoughts?

Sterling

Re: Larva content review for license

[Sterling Hughes]

On 2/5/16 8:39 AM, marko kiiskila wrote:

First of all; thanks for going through the licenses. This is good info.


On Feb 4, 2016, at 8:03 PM, Sterling Hughes <sterl...@apache.org> wrote:




We can raise this with legal, alternatively we could move the MCU &
BSP definitions to github.  People would need to config newt to point
at the github URL (newt add-clutch), but it would get around ASF
license issues.


Only if it’s considered an optional dependancy, but I think that is the
case. i.e. It not required for newt/larva to work. We had similar issue
with Adobe licensed software and Apache Flex.



It is an optional dependency.  These files are board support headers and 
drivers for the STM32F3Discovery board.  We'll have support for Nordic, 
Arduino, other STMicro boards in the default release - it would be just this 
board that was banished to Github.  Plus, it will be fun to test out if our 
clutch system actually works :-)


Ah, well that finding is inconvenient.

However, the good thing is that the stm32f3xx driver library dependency
in actuality is pretty small. I can drop that altogether.

Given that I brought it in, I can take it out.
—


I also think it will be good to have one external dependency on GH.  It 
adds a bit of visibility to start having a set of 3rd party packages :)


Sterling

Re: [2/2] incubator-mynewt-larva git commit: Simpler linker script for STM32F3 discovery board.

[Sterling Hughes]

Re [1] - Thanks, will do.

Re [2] - What defines major? :-)  I ask this because of libjson.

We've taken microjson (http://www.catb.org/esr/microjson/), and are 
doing some fairly major surgery to it:


- conversion into our coding standards (tabs to spaces, line length)
- removal of all logging statements
- addition of support for non-contiguous buffers (instead of *p++, call 
a read_next_byte() handler.)

- removal of time support APIs

Would these go under the original license terms?  And, if so, what would 
be a case where it wouldn't go under original license terms.


Sterling

On 2/5/16 3:59 PM, Justin Mclean wrote:

Hi,


I will try and find some time this weekend to do a run through of the entire 
source code base and update this.  Tedious, but it will only get more tedious.


This should help and has the correct text [1]

One of the other things I noticed while doing the license review is that serval 
files incorrectly have a Runtime Inc header on top of another say BSD header. 
In most cases a file should only have one header (i.e. that of the original 
copyright owner). See [2].  This can get tricky when you start making changes 
to a file and at some point the header may need to change.

Thanks,
Justin

1. http://www.apache.org/legal/src-headers.html#headers
2. http://www.apache.org/legal/src-headers.html#3party

Re: [2/2] incubator-mynewt-larva git commit: Simpler linker script for STM32F3 discovery board.

[Sterling Hughes]

I agree.

I will try and find some time this weekend to do a run through of the 
entire source code base and update this.  Tedious, but it will only get 
more tedious.


sterling

On 2/5/16 3:47 PM, Justin Mclean wrote:

Hi,

Probably should start getting into the habit of putting in the correct 
copyright header i.e. Apache not RunTime Inc. All part pf the legal and 
branding obligations of being an Apache project. Also one less to change later.

Thanks,
Justin

Re: Vanity import domain

[Sterling Hughes]

Hi Justin,

mynewt.io would be a vanity domain to make git imports simpler, so 
instead of doing:


import (
"git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt/cli"
)

You'd do:

import (
"mynewt.io/newt/cli"
)

And for installation of packages, you would do:

go install mynewt.io/newt

Instead of:

go install git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt

All the cool kids are doing it :-)

mynewt.io would just provide a set of go metadata.

We (runtime) have purchased and set this up, because we are lazy and 
don't like typing things.  We'd be happy to gift this to the ASF, and 
run it on ASF infrastructure (perhaps redirect to 
mynewt.incubator.apache.org).


I'd be interested in your view, but to me, I feel like this is a nice 
developer convenience that makes us agnostic to git structure, and if 
the Mynewt project ever decided Runtime were being bad citizens, it's a 
very quick change to the source code to remove these references.


Sterling


On 2/4/16 1:11 PM, Justin Mclean wrote:

Hi,

I may be missing something but this may not be the best idea from a being open 
point of view. Who has access to mynewt.io? How are changes tracked? How do 
committers make changes?

Justin

Re: Mailing lists

[Sterling Hughes]

absolutely, let's update it!

On 2/4/16 4:31 PM, Justin Mclean wrote:

Hi,

Notice the readme’s at [1][2] are pointing people to stack-...@googlegroups.org 
shouldn’t it be this mailing list instead?

Thanks,
Justin

1. https://github.com/apache/incubator-mynewt-tadpole
2. https://github.com/apache/incubator-mynewt-larva

Re: Larva content review for license

[Sterling Hughes]

On 2/4/16 7:55 PM, Justin Mclean wrote:

Hi,


If you'd like to create an overall shout-out, then go for it. The
Subversion project does this, and uses the same file to track partial
commit (as Mynewt has adopted). See:
http://svn.apache.org/repos/asf/subversion/trunk/COMMITTERS


Apache Flex does this a little differently and names people by release:
https://github.com/apache/flex-sdk/blob/develop/CONTRIBUTORS

(Note this includes people who are not committers, the idea behind it was to 
encourage them to become so.)

But it not a requirement and each PMC can decide on how to or not do it.



This seems good to me.

At some point it seems like we'll want MAINTAINERS, as there is a fair 
amount of specialization (an OS is technically very broad.)  But I guess 
we can start breaking things into sub-projects when we hit that problem. 
(*)


Sterling

(*) As an example, net/nimble is the _first_ open-source Bluetooth stack 
(both Host & Controller) for MCUs.  Given contributor bandwidth, IMO it 
makes sense to bundle governance in with Mynewt, but over time I could 
imagine this being MCU agnostic and being its own Apache project in the 
Mynewt ecosystem.

Re: Larva content review for license

[Sterling Hughes]

rel_v0_0_8-b1 for example.

- newt's built in package manager knows to fetch packages from that
git branch (we make the changes to newt once we branch.)


May be an issue with this (I think not 100% sure), does that imply that
a release can basically change over time? Or that it would be
downloading un-released software?



I misspoke, it's probably a tag not a branch.  I guess somebody could 
always move a tag, but somebody can always replace a tarball too.


I'm pretty flexible about how we push this out -- feedback and thoughts 
are really welcome.  Let me give some quick technical background for the 
uninitiated.




newt is the build and package management tool that pulls the various 
components of our OS together and generates builds.   A collection of 
eggs (packages), forms a nest.  And newt knows how to build all the eggs 
in a nest.  "Larva" is our default nest, with a collection of eggs.


In newt, you can generate what is called a clutch.  A clutch is a 
snapshot of the eggs in a given nest at a given point in time.  As an 
example, here is the start of a clutch file generated on git master larva:


$ newt nest generate-clutch larva http://mynewt.apache.org
name: larva
url: http://mynewt.apache.org
eggs:
project/test:
vers: 0.1.0
hash: 8de883b9aa460677bb79da3c495fc654186b017e
deps:
- fs/nffs@none#stable
- libs/testutil@none#stable
- libs/os@none#stable
- libs/bootutil@none#stable
- libs/testreport@none#stable
hw/bsp/stm32f3discovery:
vers: 0.0.0
hash: 73f2aa944dec135e07891f4f0a1e154858b99024
deps:
- hw/mcu/stm/stm32f3xx@none#stable
project/blinky:


A user can configure newt to look at remote clutch files (HTTP or GIT), 
and newt will go read those files and install them in the user's local 
nest (along with resolving any dependencies.)


The idea is that the core of Mynewt will mature in the ASF, and people 
will get the default set of packages from there, and those packages will 
track along with overall project maturity (e.g. they'll be stable 
someday :-)


However, around this core, hopefully people will be adding all sorts of 
cool things around Mynewt.  These could be either Apache sub-projects 
(ala Hadoop ecosystem), corporations who share code across projects or 
just some guy who happened to put a cool library on Github.  Each of 
these would generate and distribute their own clutch-file, which the 
newt tool can be pointed at.






For something to be a release it must be voted on and while in
incubation also voted on by the incubator PMC. So as long at that git
branch only contained approved software that would be fine.


Agree.




- We build newt for all supported platforms (Linux, Mac OS X, Windows)
-- and we distribute that, along with necessary LICENSE files on our
website.


Best to distribute via the apache mirrors, there a cgi script you can
use to grab the artefacts from the nearest mirror. Not there must needs
to be a source only release and an optional binary convenience release.



Agree.  We'll need some help with this once we've got the tarballs.



- Those eggs then come with individual LICENSE files, which have their
license info.


Yep the LICENSE (and NOTICE) files need to reflect only what is bundled
in the artefact downloaded.


They are Apache -- can you point me to the specific files you're
referencing so I can double check?

./hw/bsp/nrf51dk/include/bsp/cmsis_nvic.h
./hw/bsp/nrf52pdk/include/bsp/cmsis_nvic.h
./hw/bsp/olimex_stm32-e407_devboard/include/bsp/cmsis_nvic.h
./hw/bsp/stm32f3discovery/include/bsp/cmsis_nvic.h
./libs/cmsis-core/src/cmsis_nvic.c



Thanks I'll dig into these & report back.


Anyhow, here is the FatFs license, it is liberal


Yep no issue there.


We can raise this with legal, alternatively we could move the MCU &
BSP definitions to github.  People would need to config newt to point
at the github URL (newt add-clutch), but it would get around ASF
license issues.


Only if it’s considered an optional dependancy, but I think that is the
case. i.e. It not required for newt/larva to work. We had similar issue
with Adobe licensed software and Apache Flex.



It is an optional dependency.  These files are board support headers and 
drivers for the STM32F3Discovery board.  We'll have support for Nordic, 
Arduino, other STMicro boards in the default release - it would be just 
this board that was banished to Github.  Plus, it will be fun to test 
out if our clutch system actually works :-)


Sterling

OS Task Statistics

[Sterling Hughes]

Heehaw,

I'm looking to add statistics to the core RTOS (libs/os), to improve
instrumentation.

Here are the commands, and data I'm bring back in those commands.  I'd
love people's input on what else they think should be included here.

Taskinfo:

- Array of tasks, each containing:
  - Task Name
  - Priority
  - Number of context switches
  - Task Run Time
  - State (RUN, SLEEP, SEM_WAIT, MUTEX_WAIT)
  - Stack Usage
  - Stack Size
  - Last Sanity Checkin
  - Next Sanity Checkin

Memory Pool Info:

- Array of memory pools, each containing:
  - Memory Pool Name
  - Pool Element Size
  - Number of blocks in the pool
  - Number of free blocks in the pool
  - Address of last free, and allocate from this pool
(Should this be a variable size array?)

Also, right now memory pools are not centrally linked.  This change
would require there to be a list of all memory pools initialized by
the system, adding 4 bytes to the mempool structure, and 4 bytes of
.bss.  Any objections?

Sterling

Go include path / Git Include Path

[Sterling Hughes]

Howdy,

Right now there is a conflict in how newtmgr & newt include libraries using go.

Newtmgr uses:

git-wip-us.apache.org/repos/asf/incubator-mynewt-newt/newtmgr

Whereas Newt uses:

git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt

In order for both of these packages to compile, we're going to need to
choose one layout and stick with it.  Personally, I'm fine with either
-- I think newtmgr's makes more sense, but if there is a good reason
for sticking with Newt's pathes, and I'm ok with that as well.

Thoughts?

Sterling

Re: subsystem configuration ideas

[Sterling Hughes]

I think lua for configuration would make sense, but I agree, a simpler
mechanism is also useful for more constrained systems.  I think it
would make sense that lua have hooks into the simpler configuration
system, and then more complex functions can be directly exposed by
lua.  Lua can supersede the simpler config if present.





On Mon, Jan 4, 2016 at 11:48 PM, will sanfilippo  wrote:
> I am fine with the naming and the interface and all that. Not so sure about 
> lua for config though. Seems like a heavyweight thing for config so I am glad 
> you are considering something simpler :-)
>
> Will
>
>> On Jan 4, 2016, at 10:58 AM, marko kiiskila  wrote:
>>
>> Hi,
>>
>> so we need to have a way to set/read settings for subsystems.
>> These are the ones to be adjusted at runtime.
>>
>> What I’m thinking is to build this in a way where names of
>> these are strings, and that you should be able to have hierarchical
>> naming. E.g. to have subsystem to be part of the name.
>>
>> subsystem1/variable1 = value
>> subsystem1/variable2 = another_value
>> subsystem2/var1 = yet_another_value
>>
>> I’d rather use strings as identifiers as opposed to say, enumerated
>> values, because it would be easier to keep them unique.
>>
>> As for setting/reading them, I was going to start with a CLI interface.
>> And have interface from newtmgr as well.
>>
>> Of course, we will need to persist configuration. So there’s few
>> options here. Either use lua scripts, which would be read at
>> bootup time and they can change these settings. And/or
>> a simpler script interface for cases when lua is not present.
>>
>> Let me know if you have comments on this,
>> M
>>
>>
>

Re: incubator-mynewt-larva git commit: add task info display. re-arrange the task structure a little, removing enum on task state and making it a uint8

[Sterling Hughes]

Hey,

Two things with this commit I wanted to see how people felt about.

1- I've done some re-arrangement of the task structure.

Specifically:

-uint8_t t_pad[2];
+uint8_t t_state;
+uint8_t t_pad;

 char *t_name;
 os_task_func_t t_func;
@@ -57,8 +58,9 @@ struct os_task {

 struct os_sanity_check t_sanity_check;

-os_task_state_t t_state;
 os_time_t t_next_wakeup;
+os_time_t t_run_time;
+uint32_t t_ctx_sw_cnt;


Prior to these changes task state (SLEEP, RDY) was an enum, taking up
4-bytes!  Bad!  (I think I may have done it this way originally :-)

If you look at this section of the structure, you now have:

  uint16_t t_stacksize;
  uint16_t t_flags;

  uint8_t t_taskid;
  uint8_t t_prio;
  uint8_t t_state;
  uint8_t t_pad;

With only 2-bits of flags being used.  I wonder if we should compress
this further, we could, for example:

- Make stack size a multiple of 8, and use 13 bits for it.  Take 2 of
those bits and make that the flags, and 1 bit to indicate Sleep or
ready.

- Eliminate state & pad.

Talking with Will, we decided this wasn't worth it.  We'd rather just
burn the 4-bytes in this structure.

2- In adding task profiling, I've made the structure a further 8-bytes
bigger, by adding context switch count and total run time.  In other
OS's, I've seen these two variable's #ifdef'd out, depending on
profiling level.

Some notes here:

- I've added them in os_arch_ctx_sw(), not within the ISR context.
This means that I could spuriously count a context switch, where the
OS wants to switch context, but before the PEND_SV (Cortex M* series)
interrupt actually swaps in the task, another, higher priority
interrupt executes and switches context to a new task.

I thought this was fine, because even if PEND_SV does switch context,
the interrupt could come before the task executed a single
instruction: there will always be some opportunity for jitter here.
I'd rather not do task accounting within an interrupt context, and
live with this.

- Total run time only increments at the granularity of the OS timer
(currently 1ms on ARM), which means that if you have smaller runtimes,
they won't be counted.  We have a more granular timer in the HAL, but
I decided it wasn't worth bringing in that dependency.  Therefore some
tasks, which execute very quickly, will show 0 runtime.

- Context switch count and total run time are very similar metrics.
However, because CSW count provides an indication of whether a task is
actually being scheduled, and runtime gives you an idea of how long
its been running, I think both are useful.

- There is one more statistic I want to add by default, which is total
stack usage.  This should be the maximum amount of stack used, as
opposed to what the current stack usage is.  I wonder if the task
should also record the bottom of the stack, so we can get the current
amount of stack usage?

Are there any other statistics we should be keeping?  Do folks think
that we should #ifdef these elements out?   I'm somewhat against it,
because I just think its useful enough to always know this, that the
slight efficiency gains you get aren't really worth it.  However, I
could be swayed.

Sterling











On Tue, Nov 17, 2015 at 10:39 AM,  <sterl...@apache.org> wrote:
> Repository: incubator-mynewt-larva
> Updated Branches:
>   refs/heads/master 55082ce6c -> e96c2c3c6
>
>
> add task info display.  re-arrange the task structure a little, removing enum 
> on task state and making it a uint8
>
>
> Project: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/repo
> Commit: 
> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/commit/e96c2c3c
> Tree: 
> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/tree/e96c2c3c
> Diff: 
> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/diff/e96c2c3c
>
> Branch: refs/heads/master
> Commit: e96c2c3c6377452d9f7b40915f741116c8209eb3
> Parents: 55082ce
> Author: Sterling Hughes <sterl...@apache.org>
> Authored: Tue Nov 17 10:39:01 2015 -0800
> Committer: Sterling Hughes <sterl...@apache.org>
> Committed: Tue Nov 17 10:39:12 2015 -0800
>
> --
>  libs/os/egg.yml  |   5 +
>  libs/os/include/os/os.h  |   3 +
>  libs/os/include/os/os_sched.h|   4 +
>  libs/os/include/os/os_task.h |   7 +-
>  libs/os/src/arch/cortex_m4/os_arch_arm.c |   4 +
>  libs/os/src/arch/sim/os_arch_sim.c   |   4 +
>  libs/os/src/os.c |   3 +
>  libs/os/src/os_info.c| 167 ++
>  libs/os/src/os_sched.c   |  56 -
>  libs/os/src/os_task.c|   6 +
>  libs/os/src/os_tim

Re: Mynewt logo - request for input

[Sterling Hughes]

I think that is good, singular case looks better to me.  what i
especially like about #1 is that it takes the y, and makes it look
cool..

On Tue, Nov 17, 2015 at 4:32 PM, aditi hilbert <ad...@runtime.io> wrote:
> It will be hard to capitalize the M on the first one but maybe we settle for 
> “mynewt” and “mynewt OS” and change all reference to that (e.g. docs, website 
> etc.)?
>
> aditi
>
>> On Nov 17, 2015, at 3:33 PM, Sterling Hughes <sterl...@apache.org> wrote:
>>
>> I like the one on the upper left hand corner of the second page as well.
>>
>> On Tue, Nov 17, 2015 at 3:31 PM, will sanfilippo <wi...@runtime.io> wrote:
>>> I like #1 too.
>>>
>>> Will
>>>> On Nov 17, 2015, at 10:13 AM, Christopher Collins <ch...@runtime.io> wrote:
>>>>
>>>> I think they are all really good, but my preference is for 1 or 2.
>>>>
>>>> I lke 1's font the best, and I like the way the newt's tail wraps around
>>>> the y.  So actually I guess I like 1 the best :).
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> On Tue, Nov 17, 2015 at 09:49:24AM -0800, aditi hilbert wrote:
>>>>> Good point! Doing that now :)
>>>>>
>>>>>> On Nov 17, 2015, at 9:47 AM, P. Taylor Goetz <ptgo...@gmail.com> wrote:
>>>>>>
>>>>>> Cool!
>>>>>>
>>>>>> For the purpose of discussion, it might be a good idea to annotate the 
>>>>>> PDF to give each one a number for easier reference. Otherwise we’ll have 
>>>>>> to reference them by description (e.g. “The green one with the ‘m’ 
>>>>>> inside the newt’s tail.” ;) )
>>>>>>
>>>>>> -Taylor
>>>>>>
>>>>>>
>>>>>>> On Nov 17, 2015, at 12:32 PM, aditi hilbert <ad...@runtime.io> wrote:
>>>>>>>
>>>>>>> Thanks, all. I just created MYNEWT-12 
>>>>>>> <https://issues.apache.org/jira/browse/MYNEWT-12>.
>>>>>>>
>>>>>>> aditi
>>>>>>>
>>>>>>>
>>>>>>>> On Nov 17, 2015, at 9:21 AM, P. Taylor Goetz <ptgo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Confirming that no attachments were received on your reply.
>>>>>>>>
>>>>>>>> Looks like another route is in order. JIRA attachments might be the 
>>>>>>>> easiest route.
>>>>>>>>
>>>>>>>> -Taylor
>>>>>>>>
>>>>>>>>> On Nov 17, 2015, at 12:12 PM, Marvin Humphrey 
>>>>>>>>> <mar...@rectangular.com> wrote:
>>>>>>>>>
>>>>>>>>> On Tue, Nov 17, 2015 at 7:32 AM, aditi hilbert <ad...@runtime.io> 
>>>>>>>>> wrote:
>>>>>>>>>> I did attach the document with 4 drawings of “mynewt” to my mail. I 
>>>>>>>>>> am going
>>>>>>>>>> to try a second time with the original drawings of 6 “mynewts". 
>>>>>>>>>> Please
>>>>>>>>>> ignore the first page with drawings of newt on it. The following two 
>>>>>>>>>> pages
>>>>>>>>>> should show a total of 6 drawings. Hope you can see them this time!
>>>>>>>>>
>>>>>>>>> It seems that this emailing list is configured to strip attachments.  
>>>>>>>>> As extra
>>>>>>>>> confirmation, I've attached the Incubator's egg logo to this email; I 
>>>>>>>>> predict
>>>>>>>>> you won't see it, though because of gmail's quirky deduping I 
>>>>>>>>> probably will.
>>>>>>>>>
>>>>>>>>> The easiest way to share an image is probably to open a MYNEWT Jira 
>>>>>>>>> issue and
>>>>>>>>> attach it there, or possibly just to commit the files to the site svn 
>>>>>>>>> repo.
>>>>>>>>> For text there are lots of other options such as paste.apache.org, 
>>>>>>>>> Github
>>>>>>>>> gists or pull requests, and so on, but for images there's not a 
>>>>>>>>> perfect answer
>>>>>>>>> that I know of.  The downside is that we won't be able to view them 
>>>>>>>>> in our
>>>>>>>>> browsers without downloading first because of MIME type issues 
>>>>>>>>> (unless you
>>>>>>>>> commit to svn and fiddle with the svn properties), but since the 
>>>>>>>>> target
>>>>>>>>> audience is developers, it's not unreasonable to ask us to figure 
>>>>>>>>> things out.
>>>>>>>>>
>>>>>>>>> Marvin Humphrey
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>

ASF Copyright header

[Sterling Hughes]

Hey,

At some point in the near future, I'm going to go through and replace
all the header files from:

/**
 * Copyright (c) 2015 Runtime Inc.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *   http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

To the appropriate one now that we're an ASF project.  I assume this
is the correct header?

-- 

Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.

--

I will also create NOTICE and LICENSE files in each source code
directory.  I assume this should bring us "up to code" from a legal
perspective?

Thanks,
Sterling

Task Priorities

[Sterling Hughes]

Howdy,

I'm working on getting blinky a bit more developed as an initial
project.  First part of that is getting console running on sim, which
I have working.

One thing I've been looking at, is the hal_uart starts an OS task when
initialized.  The priority of that task, and stack size is defined by
the MCU definition (e.g. hw/mcu/native, or hw/stm, etc.)

I think task priorities are something that should be defined on a
per-project level.  From what I can see, there are two options for
doing this:

1- Have the individual packages expect a #define from the project, in
the following format:

hal_uart.c:

  os_task_init(OS_PRIO_UART, ..)

project/blinky/include/project/os_cfg.h:
   #define OS_PRIO_UART (10)

This could be enforced using our capabilities concept, where the
package would req_capability: os_cfg, and the project would provide
that.

2- The init function could take the priority to start the task at.
So, when hal_uart_init_cbs() is called, it would take two additional
arguments the priority, and stack size.  Anything that creates a task,
would be called directly from the project, with these arguments.
(uart code needs a little refactoring to make this easy, but should be
fine.)

I'm leaning slightly towards option #2, as I don't like messing with
defines.  That said, #1 is much more common, and they way that other
operating systems do it (I think, so that all priorities are defined
in a single header file, and you don't have to look through the code
to find them.)

What do folks think?

Sterling

Re: JIRA

[Sterling Hughes]

Hi Justin,

No, we've pretty much been waiting for the ASF infra.

It will be nice to have JIRA!

Sterling

On Mon, Oct 26, 2015 at 3:11 PM, Justin Mclean  wrote:
> Hi,
>
> I’ve raised a JIRA to setup JIRA here. [1]
>
> Is there an existing JIRA bug base you wish to import issues from?
>
> Thanks,
> Justin
>
> 1. https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-10670