Commit Graph

3 Commits

Author SHA1 Message Date
Andrew Boie 65a9d2a94a kernel: make K_.*_INITIALIZER private to kernel
Upcoming memory protection features will be placing some additional
constraints on kernel objects:

- They need to reside in memory owned by the kernel and not the
application
- Certain kernel object validation schemes will require some run-time
initialization of all kernel objects before they can be used.

Per Ben these initializer macros were never intended to be public. It is
not forbidden to use them, but doing so requires care: the memory being
initialized must reside in kernel space, and extra runtime
initialization steps may need to be peformed before they are fully
usable as kernel objects. In particular, kernel subsystems or drivers
whose objects are already in kernel memory may still need to use these
macros if they define kernel objects as members of a larger data
structure.

It is intended that application developers instead use the
K_<object>_DEFINE macros, which will automatically put the object in the
right memory and add them to a section which can be iterated over at
boot to complete initiailization.

There was no K_WORK_DEFINE() macro for creating struct k_work objects,
this is now added.

k_poll_event and k_poll_signal are intended to be instatiated from
application memory and have not been changed.

Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-07-10 11:44:56 -07:00
David B. Kinder 570ad1d328 doc: add example clarifing duration/period
A recent mailing list question asked for clarify about
the duration and period parameters for starting a timer.

Change-Id: I9bf8dd93dbbb9bbb94c95c2d7072f446ea1d6b01
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
2017-03-18 23:33:20 +00:00
Anas Nashif ebe9771d02 doc: move kernel_v2 to kernel
Change-Id: I6caa94bc1a3d1986966652cd0a24bf22f3697481
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2016-12-24 01:53:16 +00:00