tk_root should be named as is.

Was independent part of last change

Reverted in part: 775dc71f
Provide hosted-mode execution somewhere to go after process termination
Comments moderated

Category: cosmetics
Race when creating new threads

If for example finalization of death is delayed due to pending join,
internal structures and state are vulnerable. There may be other use-cases.
This change aims to addresses all.

As tk_yield is called as part of thread creation everything after that point
that affects global consistency must be mistrusted and re-done.

An alternative solution could be to have a special yield that doesn't run
anything else until thread creation is final. But the same can happen for
example in true preemptive dispatch (i.e. context switch after IRQ) which we
have no control over. Enforcing no true dispatch would invalidate Tinker as
a true RT kernel that can react directly to external event as opposed to
indirectly by queuing in a run-queue. Direct reaction has faster response and
a simpler solution is better due to future changes (KISS). This solution is
therefore preferred.

Having both wouldn't hurt however as an unfinished thread isn't really ready
to run anyway and it would make the execution flow easier to follow and
debugging a somewhat less hard. Bug was hard to find and has been part
of the code for a while.

Bug found using test-case: test_ccSort.c (9e604fd).

Requirement for test: Enough threads to provoke the scenario.

Additional change in patch:
A simple detector for this kind of error.

Category: bug-fix
Marking up stacks on thread create now conditional.

Marking-up stacks with thread number in clear-ext was originally a debugging
aid to help detecting stack-smashing, memory layout/alignment issues. But
also a good tool for hard-core bare-metal RT-developers using tinker to
figure out memory requirement.

In hosted mode running on Linux, marking up the stacks proactive inhibits
possible overcommitment of stack-size. Possibility to overcommit memory is
an indirect effect of having a MMU managing physical memory.
ARM: malloc requires different sbrk implementation.

This applies to non-hosted targets only (i.e. real physical targets) but
it's a conceptual change that's worth considering even for other
architectures.

The Newlib provided one depends on a linker-script which is incompatible as
the Newlib malloc assumes everything up until top-of memory is free.  The
top it does not know or care about only the bottom (i.e. from where to
start).

Tinker new memory layout  is actually traditional, but since we have a
defined position for the root-stack and since context or other important
things may lay at BOS we need to help avoiding that this doesn't get
overwritten.

Another possibility would be to put the root-stack below the heap in which
case heap growth couldn't touch it. However the reversed problem
(stack-smashing) would still be an issue. Possibly somewhat detectable
during context switch though.
JUMPER fix

minor
Spell errors in comments

Category: cosmetic
Whitespace cleanup

White-space differences makes git auto-merge and rebase go ape-shit.
When working on different branches. Having a bunch of commits on
each side will trigger the same merge conflicts over and over.

Category: Cosmetic (but necessary not to drown in brain-dead SCM duties)

There has to be something wrong with Git regarding this. This is like
Enforcing users (developers) a certain coding style. Regardless of what one
might think of whitespace and where they occur, who does that?

Command used to do this en-mass:
find . -iregex '.*\.c\|.*\.h\|.*\.in\|.*\.ld\|.*\.m4\|.*Makefile*' | \
   futil.onfile.sh "sed -Ee 's/[[:space:]]+$//'"
typechange on files: execute flag cleared

Category: cosmetic & SCM related
Indent run on all files in src, bsp

Builds & runs for x86_64 (hosted mode)

Frequent complaints:
Warning:old style assignment ambiguity in "=&".  Assuming "= &"
Warning:old style assignment ambiguity in "=*".  Assuming "= *"

These are bit manipulation operations. The ambiguity for the second
complaint can only occur if RHS is a pointer, but the first is bad and
indent is not not correct in the assumption:

./tk_mem.c:163:
./filesys/inode.c:162:
./filesys/inode.c:165:
./filesys/inode.c:168:
./filesys/inode.c:171:
./filesys/inode.c:174:
./filesys/inode.c:177:
./filesys/inode.c:180:

indend will fail for files in include. Therefore left alone for now.
Separate patch will follow.

Command run in each directory:
indent -linux $(find . -iregex '.*\.h$\|.*\.c$' -type f)

The pre-processor rules under 'indent -linux' I think are ghastly.
Conditionals are obviously nut used much there. Linux coding-style says
nothing about it however:

https://www.kernel.org/doc/Documentation/CodingStyle

Perhaps it's just a too stringent configuration under 'indent -linux'

Either way, lets try this for a while in the hope it will save some
unnecessary merge conflict in the future.
Run indend on include/

All passed later compilation except pthread.h
indent on pthead.h

All except the fail.
indent on pthread.h 2(2)

Source tweaked with whatever tricked indent. Output in patch.

This finalizes indent. All files are now processed and any future run should
not generate diffs any-where, which was the whole purpose with this.
License headers corrected

New published work and old under src/. I.e. not bug-fixes. Files in bsp/
remain "as-is" even though their headers wrt the year(s) are not correct
according to the rule of "first published" and will be changed back
(re-created from log).

Original changes are in the git-log and the rcs/cvs-log still kept in each
file. Copy remains in Git even if rcs-logs are removed.
The big spell-check fixup (in src/)

Documentation in source wasn't such a good idea as it triggers
merger-conflicts when changed, and it often is for many more reasons than
code. It will have to go. Code comments are one thing, documentation
another...
CVS/RCS logs removed from source

CVS logs are obsolete. They now exist in git and in this patch.
Documentation removed from source except bsp/

Still available prior this commit (or revert this commit).

Documentation neglected outdated. Code comments will be re-introduced as per
relevancy. Proper documentation will be held separately instead.

Code in bsp/ is not purged as it's much more relevant to keep in source
there as it concerns driver, HW and IC specific details.

Category: cosmetic