eLinux.org - User contributions [en]

Android Mainlining Project

2012-03-21T18:02:45Z

TimBird: /* Patch/Feature Status Chart */

This page is for organizing the Android Mainlining Project. It has information and resources associated with this
project.

== Goal ==
The goal of this project is to ultimately mainline all patches required to run the current released
version of Android. The purpose of mainlining these patches is 3-fold:
# to allow a developer to use the latest released version of the Linux kernel to run an Android system, without requiring patches to their kernel
# to make it possible to develop drivers and board support features against either an Android kernel release or a kernel.org kernel release, with little or no modifications or conditional code
# to reduce or eliminate the burden of maintaining independent patches from release to release for Android kernel developers

To "mainline" a patch means to have it included in Linus Torvalds kernel.org kernel, in a released (non-rc) version.

== Process ==
[This is a draft section, up for discussion]

Overall:
* identify all patches/features, and categorize into core or non/core
** core = feature is required or strongly desired for Android operation on a platform
** non-core = Most of the Android system can run without the feature

Per feature or patch:
* research any previous submission feedback
* incorporate feedback, as appropriate
* negotiate any interface changes with Google Android team
* submit updated patches to mainline
* repeat until accepted

== Resources ==
* Mailing list: https://lists.linuxfoundation.org/mailman/listinfo/ce-android-mainline
* Linaro blueprint for project: https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-android-upstreaming

== Meetings ==
* Meeting: [[Android mainlining interest group meeting 2012]]
** Summary: 9:30- 12:00 February 10, 2012 at the Sofitel Hotel in Redwood Shores, California.

== People ==
People who have expressed interest in this project are:

* Tim Bird
* John Stultz
* Paul McKenney
* Deepak Saxena
* Arnd Bergmann
* Thomas Gleixner
* Arjan Van de Ven
* Brian Swetland
* Tetsuyuki Kobayashi
* Andy Green
* Victor M. Jaquez
* Jesse Barker
* Anton Vorontsov
* Greg Kroah-Hartman
* Shuah Khan

=== roles/expertise ===
This section has miscellaneous notes on roles, capabilities and expertise of group's members

John Stultz is the owner of the Linaro blueprint for mainlining Android features.
Tim Bird is the owner of the CE Workgroup project for mainlining Android features.
Deepak and Jesse can help make arrangements for a meeting at Linaro Connect.
Tim can help make arrangements for a meeting at Android Builders Summit.

* John Stultz has worked on POSIX Alarm timers
* Jesse is working on shared memory buffers related to pmem/CMA/parts of ion
* Anton Vorontsov is looking at the lowmemory killer
* Greg has put some Android patches into mainline (under drivers/staging/android) previously
** Greg put some Android patches in mainline under drivers/staging/android in Dec. 2011
* Paul McKenney - kicking around ideas for dealing with wakelocks single global lock (dec. 2011)

== Plans ==
* Update this site with information on latest patch status - ongoing, by anyone
** [FIXTHIS - add sections needing a status or status update]

== Patch/Feature Status Chart ==
{| border="1" cellspacing="0" cellpadding="5"
|-bgcolor="#80c0d0"
!Feature/Patch
!Description
!Status
!Part of core?
!Owner/Interested parties
|Notes
|-
|[[Android_logger|logger]]
|kernel support for Android system logging
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|Tim Bird
|See [[Mainline Android logger project]] for a list of ideas, issues and a project plan for this feature
Also see [http://lkml.indiana.edu/hypermail/linux/kernel/1112.2/index.html#02419 this LKML discussion thread]
Some cleanup patches in linux-next, with more extensive changes to be written, tested, reviewed by Tim in Spring 2012.
|-
|wakelocks
|Power management locking mechanism to prevent opportunistic suspend
|not mainlined, as of 2012.03.19, work in progress
|yes
|Rafael Wysocki
|Is important due to impact on board support and drivers by 3rd parties. Last effort was around "autosleep and wakelocks".
See http://lwn.net/Articles/479841/ and this thread: http://thread.gmane.org/gmane.linux.kernel/1249726
|-
|Android alarm timers
|Timers that count down during suspended operation, and can wake from suspend
|Partial: Posix alarm timers were mainlined in kernel version 2.6.38 - see https://lwn.net/Articles/429925/
|yes
|John Stultz
|Mending patches to convert Android Alarm Timers to utilize the upstreamed alarm timer work are still pending.
|-
|ashmem
|Shared memory implementation that allows unpinned pages to be marked, which can be dropped by the kernel under memory pressure
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|John Stultz
|Working on fadvise volatile alternative implementation that handles part of the ashmem functionality. However, there are additional aspects of ashmem design that need to be addressed(no tmpfs mounts, atomic create/unlink behavior,etc).
|-
|network security
|special permission checks for secure access to network operations
|not mainlined
|? (can run without it, but network security won't be enforced)
|no one
|May be very difficult to mainline, as the code is extremely Android-specific with hardcoded GIDs and capabilities.
|-
|[[Android_Binder|binder]]
|Android inter-process communication mechanism
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|no one
|Generated a fair amount of discussion on last submission. See http://elinux.org/Android_Binder#obstacles_to_mainlining
See also this thread: http://lists.linuxfoundation.org/pipermail/ce-android-mainline/2012-January/thread.html#42
|-
|Android pmem driver
|manages large (1-16+MB) contiguous physical memory regions to be shared between userspace and kernel drivers (dsp, gpu etc.)
|Removed - no longer in use
|yes
|Shuah Khan
|Investigating existing alternatives. Can CMA (Contiguous Memory Allocator) fill the need? Based on recent lkml discussion, pmem.c is no longer used and will be removed from Android release. Reference: https://lkml.org/lkml/2012/1/23/183 - Patch to remove pmem.c from 3.3-rc1 staging area has been accepted.
|-
|Android USB gadget driver
|Support for Android as gadget device from host
|unknown
|? (not sure if needed for basic bringup or not, but would be really painful if missing)
|no one?
|
|-
|timed gpio
|perform gpio operations as a result of specified timeouts - mainly used to support vibrate feature.
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no? (is this needed for basic bringup?)
|Shuah Khan
|Enhancing ledtrig-timer with activate_once timer - Shuah working on a patch
|-
|timed output
|seems to just be a class for timed gpio items
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no? (required by timed_gpio)
|Shuah Khan
|Enhancing ledtrig-timer with activate_once timer - Shuah working on a patch
|-
|low memory killer
|feature to manage application lifecycle in low memory conditions
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes (but system might work without it)
|Anton Vorontsov
|See https://lkml.org/lkml/2011/12/18/173 for discussion about these patches
|-
|ram console
|ability to save console output to a reserved ram area for diagnostics on a subsequent boot
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no
|Shuah Khan
|No lkml submission attempt history found so far. pstore fs interface solves the same problem and is in mainline 3.1.5. fs/pstore Reference - http://lwn.net/Articles/421297/ After investigating and discussing ram console use cases, it is clear that the proposal to use ram-oops and pstore will not be a complete solution to cover all the cases. Hence, the going forward plan is to pursue ram console inclusion in the mainline. ram console is going through re-write splitting it into twp drivers. Waiting for these changes to get into the 3.3 staging area. For now working with the unofficial patches.
|-
|ion graphics memory driver
|graphics memory drivers thingie
|not mainlined
|yes (for 4.0 and later?)
|Jesse Barker
|
|}

== Progress Chart ==
This section is intended to show our progress, by showing the patch set size over time. With any luck, as
we get features into mainline, the difference between the Android kernel and the mainline Linux kernel will shrink.

<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#ffffcc; align:right; ">
''Note: This table is not up-to-date and is hard to measure anyway. The inclusion of a lot of material into 3.3 obsoletes the need for a per-patch tracking mechanism (maybe?). Also, there will always be some difference, due to board support packages and new development areas (like ion), so the goal is not really 0 differences, but just a reduction overall. I'm not sure if we'll maintain this table or not, but I'm leaving it for now as a placeholder.''
</div>

* diff of 2.6.29 kernel.org tree versus kernel
{| border="1" cellspacing="0" cellpadding="5"
|-bgcolor="#80c0d0"
!Kernel Version
!Files changed
!insertions
!deletions
!hunks
!bytes in diff
|-
|2.6.29 || 187 || 123506 || 0 || 187 || 3291827
|-
|}

[[Category:Android]]

Android Mainlining Project

2012-03-21T18:00:55Z

TimBird: /* Progress Chart */ add disclaimer to this section (which is not finished)

This page is for organizing the Android Mainlining Project. It has information and resources associated with this
project.

== Goal ==
The goal of this project is to ultimately mainline all patches required to run the current released
version of Android. The purpose of mainlining these patches is 3-fold:
# to allow a developer to use the latest released version of the Linux kernel to run an Android system, without requiring patches to their kernel
# to make it possible to develop drivers and board support features against either an Android kernel release or a kernel.org kernel release, with little or no modifications or conditional code
# to reduce or eliminate the burden of maintaining independent patches from release to release for Android kernel developers

To "mainline" a patch means to have it included in Linus Torvalds kernel.org kernel, in a released (non-rc) version.

== Process ==
[This is a draft section, up for discussion]

Overall:
* identify all patches/features, and categorize into core or non/core
** core = feature is required or strongly desired for Android operation on a platform
** non-core = Most of the Android system can run without the feature

Per feature or patch:
* research any previous submission feedback
* incorporate feedback, as appropriate
* negotiate any interface changes with Google Android team
* submit updated patches to mainline
* repeat until accepted

== Resources ==
* Mailing list: https://lists.linuxfoundation.org/mailman/listinfo/ce-android-mainline
* Linaro blueprint for project: https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-android-upstreaming

== Meetings ==
* Meeting: [[Android mainlining interest group meeting 2012]]
** Summary: 9:30- 12:00 February 10, 2012 at the Sofitel Hotel in Redwood Shores, California.

== People ==
People who have expressed interest in this project are:

* Tim Bird
* John Stultz
* Paul McKenney
* Deepak Saxena
* Arnd Bergmann
* Thomas Gleixner
* Arjan Van de Ven
* Brian Swetland
* Tetsuyuki Kobayashi
* Andy Green
* Victor M. Jaquez
* Jesse Barker
* Anton Vorontsov
* Greg Kroah-Hartman
* Shuah Khan

=== roles/expertise ===
This section has miscellaneous notes on roles, capabilities and expertise of group's members

John Stultz is the owner of the Linaro blueprint for mainlining Android features.
Tim Bird is the owner of the CE Workgroup project for mainlining Android features.
Deepak and Jesse can help make arrangements for a meeting at Linaro Connect.
Tim can help make arrangements for a meeting at Android Builders Summit.

* John Stultz has worked on POSIX Alarm timers
* Jesse is working on shared memory buffers related to pmem/CMA/parts of ion
* Anton Vorontsov is looking at the lowmemory killer
* Greg has put some Android patches into mainline (under drivers/staging/android) previously
** Greg put some Android patches in mainline under drivers/staging/android in Dec. 2011
* Paul McKenney - kicking around ideas for dealing with wakelocks single global lock (dec. 2011)

== Plans ==
* Update this site with information on latest patch status - ongoing, by anyone
** [FIXTHIS - add sections needing a status or status update]

== Patch/Feature Status Chart ==
{| border="1" cellspacing="0" cellpadding="5"
|-bgcolor="#80c0d0"
!Feature/Patch
!Description
!Status
!Part of core?
!Owner/Interested parties
|Notes
|-
|[[Android_logger|logger]]
|kernel support for Android system logging
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|Tim Bird
|should be non-controversial (though I'm always surprised)
See [[Mainline Android logger project]] for a list of ideas, issues and a project plan for this feature
Also see [http://lkml.indiana.edu/hypermail/linux/kernel/1112.2/index.html#02419 this LKML discussion thread]
Some cleanup patches in linux-next, with more extensive changes to be written, tested, reviewed by Tim in Spring 2012.
|-
|wakelocks
|Power management locking mechanism to prevent opportunistic suspend
|not mainlined, as of 2012.03.19, work in progress
|yes
|Rafael Wysocki
|Is important due to impact on board support and drivers by 3rd parties. Last effort was around "autosleep and wakelocks".
See http://lwn.net/Articles/479841/ and this thread: http://thread.gmane.org/gmane.linux.kernel/1249726
|-
|Android alarm timers
|Timers that count down during suspended operation, and can wake from suspend
|Partial: Posix alarm timers were mainlined in kernel version 2.6.38 - see https://lwn.net/Articles/429925/
|yes
|John Stultz
|Mending patches to convert Android Alarm Timers to utilize the upstreamed alarm timer work are still pending.
|-
|ashmem
|Shared memory implementation that allows unpinned pages to be marked, which can be dropped by the kernel under memory pressure
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|John Stultz
|Working on fadvise volatile alternative implementation that handles part of the ashmem functionality. However, there are additional aspects of ashmem design that need to be addressed(no tmpfs mounts, atomic create/unlink behavior,etc).
|-
|network security
|special permission checks for secure access to network operations
|not mainlined
|? (can run without it, but network security won't be enforced)
|no one
|May be very difficult to mainline, as the code is extremely Android-specific with hardcoded GIDs and capabilities.
|-
|[[Android_Binder|binder]]
|Android inter-process communication mechanism
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|no one
|Generated a fair amount of discussion on last submission. See http://elinux.org/Android_Binder#obstacles_to_mainlining
See also this thread: http://lists.linuxfoundation.org/pipermail/ce-android-mainline/2012-January/thread.html#42
|-
|Android pmem driver
|manages large (1-16+MB) contiguous physical memory regions to be shared between userspace and kernel drivers (dsp, gpu etc.)
|Removed - no longer in use
|yes
|Shuah Khan
|Investigating existing alternatives. Can CMA (Contiguous Memory Allocator) fill the need? Based on recent lkml discussion, pmem.c is no longer used and will be removed from Android release. Reference: https://lkml.org/lkml/2012/1/23/183 - Patch to remove pmem.c from 3.3-rc1 staging area has been accepted.
|-
|Android USB gadget driver
|Support for Android as gadget device from host
|unknown
|? (not sure if needed for basic bringup or not, but would be really painful if missing)
|no one?
|
|-
|timed gpio
|perform gpio operations as a result of specified timeouts - mainly used to support vibrate feature.
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no? (is this needed for basic bringup?)
|Shuah Khan
|Enhancing ledtrig-timer with activate_once timer - Shuah working on a patch
|-
|timed output
|seems to just be a class for timed gpio items
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no? (required by timed_gpio)
|Shuah Khan
|Enhancing ledtrig-timer with activate_once timer - Shuah working on a patch
|-
|low memory killer
|feature to manage application lifecycle in low memory conditions
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes (but system might work without it)
|Anton Vorontsov
|See https://lkml.org/lkml/2011/12/18/173 for discussion about these patches
|-
|ram console
|ability to save console output to a reserved ram area for diagnostics on a subsequent boot
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no
|Shuah Khan
|No lkml submission attempt history found so far. pstore fs interface solves the same problem and is in mainline 3.1.5. fs/pstore Reference - http://lwn.net/Articles/421297/ After investigating and discussing ram console use cases, it is clear that the proposal to use ram-oops and pstore will not be a complete solution to cover all the cases. Hence, the going forward plan is to pursue ram console inclusion in the mainline. ram console is going through re-write splitting it into twp drivers. Waiting for these changes to get into the 3.3 staging area. For now working with the unofficial patches.
|-
|ion graphics memory driver
|graphics memory drivers thingie
|not mainlined
|yes (for 4.0 and later?)
|Jesse Barker
|
|}

== Progress Chart ==
This section is intended to show our progress, by showing the patch set size over time. With any luck, as
we get features into mainline, the difference between the Android kernel and the mainline Linux kernel will shrink.

<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#ffffcc; align:right; ">
''Note: This table is not up-to-date and is hard to measure anyway. The inclusion of a lot of material into 3.3 obsoletes the need for a per-patch tracking mechanism (maybe?). Also, there will always be some difference, due to board support packages and new development areas (like ion), so the goal is not really 0 differences, but just a reduction overall. I'm not sure if we'll maintain this table or not, but I'm leaving it for now as a placeholder.''
</div>

* diff of 2.6.29 kernel.org tree versus kernel
{| border="1" cellspacing="0" cellpadding="5"
|-bgcolor="#80c0d0"
!Kernel Version
!Files changed
!insertions
!deletions
!hunks
!bytes in diff
|-
|2.6.29 || 187 || 123506 || 0 || 187 || 3291827
|-
|}

[[Category:Android]]

Android Mainlining Project

2012-03-19T23:25:23Z

TimBird: /* Patch/Feature Status Chart */ add thread from ce-android-mainline for binder

This page is for organizing the Android Mainlining Project. It has information and resources associated with this
project.

== Goal ==
The goal of this project is to ultimately mainline all patches required to run the current released
version of Android. The purpose of mainlining these patches is 3-fold:
# to allow a developer to use the latest released version of the Linux kernel to run an Android system, without requiring patches to their kernel
# to make it possible to develop drivers and board support features against either an Android kernel release or a kernel.org kernel release, with little or no modifications or conditional code
# to reduce or eliminate the burden of maintaining independent patches from release to release for Android kernel developers

To "mainline" a patch means to have it included in Linus Torvalds kernel.org kernel, in a released (non-rc) version.

== Process ==
[This is a draft section, up for discussion]

Overall:
* identify all patches/features, and categorize into core or non/core
** core = feature is required or strongly desired for Android operation on a platform
** non-core = Most of the Android system can run without the feature

Per feature or patch:
* research any previous submission feedback
* incorporate feedback, as appropriate
* negotiate any interface changes with Google Android team
* submit updated patches to mainline
* repeat until accepted

== Resources ==
* Mailing list: https://lists.linuxfoundation.org/mailman/listinfo/ce-android-mainline
* Linaro blueprint for project: https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-android-upstreaming

== Meetings ==
* Meeting: [[Android mainlining interest group meeting 2012]]
** Summary: 9:30- 12:00 February 10, 2012 at the Sofitel Hotel in Redwood Shores, California.

== People ==
People who have expressed interest in this project are:

* Tim Bird
* John Stultz
* Paul McKenney
* Deepak Saxena
* Arnd Bergmann
* Thomas Gleixner
* Arjan Van de Ven
* Brian Swetland
* Tetsuyuki Kobayashi
* Andy Green
* Victor M. Jaquez
* Jesse Barker
* Anton Vorontsov
* Greg Kroah-Hartman
* Shuah Khan

=== roles/expertise ===
This section has miscellaneous notes on roles, capabilities and expertise of group's members

John Stultz is the owner of the Linaro blueprint for mainlining Android features.
Tim Bird is the owner of the CE Workgroup project for mainlining Android features.
Deepak and Jesse can help make arrangements for a meeting at Linaro Connect.
Tim can help make arrangements for a meeting at Android Builders Summit.

* John Stultz has worked on POSIX Alarm timers
* Jesse is working on shared memory buffers related to pmem/CMA/parts of ion
* Anton Vorontsov is looking at the lowmemory killer
* Greg has put some Android patches into mainline (under drivers/staging/android) previously
** Greg put some Android patches in mainline under drivers/staging/android in Dec. 2011
* Paul McKenney - kicking around ideas for dealing with wakelocks single global lock (dec. 2011)

== Plans ==
* Update this site with information on latest patch status - ongoing, by anyone
** [FIXTHIS - add sections needing a status or status update]

== Patch/Feature Status Chart ==
{| border="1" cellspacing="0" cellpadding="5"
|-bgcolor="#80c0d0"
!Feature/Patch
!Description
!Status
!Part of core?
!Owner/Interested parties
|Notes
|-
|[[Android_logger|logger]]
|kernel support for Android system logging
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|Tim Bird
|should be non-controversial (though I'm always surprised)
See [[Mainline Android logger project]] for a list of ideas, issues and a project plan for this feature
Also see [http://lkml.indiana.edu/hypermail/linux/kernel/1112.2/index.html#02419 this LKML discussion thread]
Some cleanup patches in linux-next, with more extensive changes to be written, tested, reviewed by Tim in Spring 2012.
|-
|wakelocks
|Power management locking mechanism to prevent opportunistic suspend
|not mainlined, as of 2012.03.19, work in progress
|yes
|Rafael Wysocki
|Is important due to impact on board support and drivers by 3rd parties. Last effort was around "autosleep and wakelocks".
See http://lwn.net/Articles/479841/ and this thread: http://thread.gmane.org/gmane.linux.kernel/1249726
|-
|Android alarm timers
|Timers that count down during suspended operation, and can wake from suspend
|Partial: Posix alarm timers were mainlined in kernel version 2.6.38 - see https://lwn.net/Articles/429925/
|yes
|John Stultz
|Mending patches to convert Android Alarm Timers to utilize the upstreamed alarm timer work are still pending.
|-
|ashmem
|Shared memory implementation that allows unpinned pages to be marked, which can be dropped by the kernel under memory pressure
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|John Stultz
|Working on fadvise volatile alternative implementation that handles part of the ashmem functionality. However, there are additional aspects of ashmem design that need to be addressed(no tmpfs mounts, atomic create/unlink behavior,etc).
|-
|network security
|special permission checks for secure access to network operations
|not mainlined
|? (can run without it, but network security won't be enforced)
|no one
|May be very difficult to mainline, as the code is extremely Android-specific with hardcoded GIDs and capabilities.
|-
|[[Android_Binder|binder]]
|Android inter-process communication mechanism
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|no one
|Generated a fair amount of discussion on last submission. See http://elinux.org/Android_Binder#obstacles_to_mainlining
See also this thread: http://lists.linuxfoundation.org/pipermail/ce-android-mainline/2012-January/thread.html#42
|-
|Android pmem driver
|manages large (1-16+MB) contiguous physical memory regions to be shared between userspace and kernel drivers (dsp, gpu etc.)
|Removed - no longer in use
|yes
|Shuah Khan
|Investigating existing alternatives. Can CMA (Contiguous Memory Allocator) fill the need? Based on recent lkml discussion, pmem.c is no longer used and will be removed from Android release. Reference: https://lkml.org/lkml/2012/1/23/183 - Patch to remove pmem.c from 3.3-rc1 staging area has been accepted.
|-
|Android USB gadget driver
|Support for Android as gadget device from host
|unknown
|? (not sure if needed for basic bringup or not, but would be really painful if missing)
|no one?
|
|-
|timed gpio
|perform gpio operations as a result of specified timeouts - mainly used to support vibrate feature.
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no? (is this needed for basic bringup?)
|Shuah Khan
|Enhancing ledtrig-timer with activate_once timer - Shuah working on a patch
|-
|timed output
|seems to just be a class for timed gpio items
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no? (required by timed_gpio)
|Shuah Khan
|Enhancing ledtrig-timer with activate_once timer - Shuah working on a patch
|-
|low memory killer
|feature to manage application lifecycle in low memory conditions
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes (but system might work without it)
|Anton Vorontsov
|See https://lkml.org/lkml/2011/12/18/173 for discussion about these patches
|-
|ram console
|ability to save console output to a reserved ram area for diagnostics on a subsequent boot
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no
|Shuah Khan
|No lkml submission attempt history found so far. pstore fs interface solves the same problem and is in mainline 3.1.5. fs/pstore Reference - http://lwn.net/Articles/421297/ After investigating and discussing ram console use cases, it is clear that the proposal to use ram-oops and pstore will not be a complete solution to cover all the cases. Hence, the going forward plan is to pursue ram console inclusion in the mainline. ram console is going through re-write splitting it into twp drivers. Waiting for these changes to get into the 3.3 staging area. For now working with the unofficial patches.
|-
|ion graphics memory driver
|graphics memory drivers thingie
|not mainlined
|yes (for 4.0 and later?)
|Jesse Barker
|
|}

== Progress Chart ==
This section is intended to show our progress, by showing the patch set size over time. With any luck, as
we get features into mainline, the difference between the Android kernel and the legacy Linux kernel will shrink.

* diff of 2.6.29 kernel.org tree versus kernel
{| border="1" cellspacing="0" cellpadding="5"
|-bgcolor="#80c0d0"
!Kernel Version
!Files changed
!insertions
!deletions
!hunks
!bytes in diff
|-
|2.6.29 || 187 || 123506 || 0 || 187 || 3291827
|-
|}

[[Category:Android]]

Android Mainlining Project

2012-03-19T23:18:05Z

TimBird: /* Patch/Feature Status Chart */

This page is for organizing the Android Mainlining Project. It has information and resources associated with this
project.

== Goal ==
The goal of this project is to ultimately mainline all patches required to run the current released
version of Android. The purpose of mainlining these patches is 3-fold:
# to allow a developer to use the latest released version of the Linux kernel to run an Android system, without requiring patches to their kernel
# to make it possible to develop drivers and board support features against either an Android kernel release or a kernel.org kernel release, with little or no modifications or conditional code
# to reduce or eliminate the burden of maintaining independent patches from release to release for Android kernel developers

To "mainline" a patch means to have it included in Linus Torvalds kernel.org kernel, in a released (non-rc) version.

== Process ==
[This is a draft section, up for discussion]

Overall:
* identify all patches/features, and categorize into core or non/core
** core = feature is required or strongly desired for Android operation on a platform
** non-core = Most of the Android system can run without the feature

Per feature or patch:
* research any previous submission feedback
* incorporate feedback, as appropriate
* negotiate any interface changes with Google Android team
* submit updated patches to mainline
* repeat until accepted

== Resources ==
* Mailing list: https://lists.linuxfoundation.org/mailman/listinfo/ce-android-mainline
* Linaro blueprint for project: https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-android-upstreaming

== Meetings ==
* Meeting: [[Android mainlining interest group meeting 2012]]
** Summary: 9:30- 12:00 February 10, 2012 at the Sofitel Hotel in Redwood Shores, California.

== People ==
People who have expressed interest in this project are:

* Tim Bird
* John Stultz
* Paul McKenney
* Deepak Saxena
* Arnd Bergmann
* Thomas Gleixner
* Arjan Van de Ven
* Brian Swetland
* Tetsuyuki Kobayashi
* Andy Green
* Victor M. Jaquez
* Jesse Barker
* Anton Vorontsov
* Greg Kroah-Hartman
* Shuah Khan

=== roles/expertise ===
This section has miscellaneous notes on roles, capabilities and expertise of group's members

John Stultz is the owner of the Linaro blueprint for mainlining Android features.
Tim Bird is the owner of the CE Workgroup project for mainlining Android features.
Deepak and Jesse can help make arrangements for a meeting at Linaro Connect.
Tim can help make arrangements for a meeting at Android Builders Summit.

* John Stultz has worked on POSIX Alarm timers
* Jesse is working on shared memory buffers related to pmem/CMA/parts of ion
* Anton Vorontsov is looking at the lowmemory killer
* Greg has put some Android patches into mainline (under drivers/staging/android) previously
** Greg put some Android patches in mainline under drivers/staging/android in Dec. 2011
* Paul McKenney - kicking around ideas for dealing with wakelocks single global lock (dec. 2011)

== Plans ==
* Update this site with information on latest patch status - ongoing, by anyone
** [FIXTHIS - add sections needing a status or status update]

== Patch/Feature Status Chart ==
{| border="1" cellspacing="0" cellpadding="5"
|-bgcolor="#80c0d0"
!Feature/Patch
!Description
!Status
!Part of core?
!Owner/Interested parties
|Notes
|-
|[[Android_logger|logger]]
|kernel support for Android system logging
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|Tim Bird
|should be non-controversial (though I'm always surprised)
See [[Mainline Android logger project]] for a list of ideas, issues and a project plan for this feature
Also see [http://lkml.indiana.edu/hypermail/linux/kernel/1112.2/index.html#02419 this LKML discussion thread]
Some cleanup patches in linux-next, with more extensive changes to be written, tested, reviewed by Tim in Spring 2012.
|-
|wakelocks
|Power management locking mechanism to prevent opportunistic suspend
|not mainlined, as of 2012.03.19, work in progress
|yes
|Rafael Wysocki
|Is important due to impact on board support and drivers by 3rd parties. Last effort was around "autosleep and wakelocks".
See http://lwn.net/Articles/479841/ and this thread: http://thread.gmane.org/gmane.linux.kernel/1249726
|-
|Android alarm timers
|Timers that count down during suspended operation, and can wake from suspend
|Partial: Posix alarm timers were mainlined in kernel version 2.6.38 - see https://lwn.net/Articles/429925/
|yes
|John Stultz
|Mending patches to convert Android Alarm Timers to utilize the upstreamed alarm timer work are still pending.
|-
|ashmem
|Shared memory implementation that allows unpinned pages to be marked, which can be dropped by the kernel under memory pressure
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|John Stultz
|Working on fadvise volatile alternative implementation that handles part of the ashmem functionality. However, there are additional aspects of ashmem design that need to be addressed(no tmpfs mounts, atomic create/unlink behavior,etc).
|-
|network security
|special permission checks for secure access to network operations
|not mainlined
|? (can run without it, but network security won't be enforced)
|no one
|May be very difficult to mainline, as the code is extremely Android-specific with hardcoded GIDs and capabilities.
|-
|[[Android_Binder|binder]]
|Android inter-process communication mechanism
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|no one
|Generated a fair amount of discussion on last submission. See http://elinux.org/Android_Binder#obstacles_to_mainlining
|-
|Android pmem driver
|manages large (1-16+MB) contiguous physical memory regions to be shared between userspace and kernel drivers (dsp, gpu etc.)
|Removed - no longer in use
|yes
|Shuah Khan
|Investigating existing alternatives. Can CMA (Contiguous Memory Allocator) fill the need? Based on recent lkml discussion, pmem.c is no longer used and will be removed from Android release. Reference: https://lkml.org/lkml/2012/1/23/183 - Patch to remove pmem.c from 3.3-rc1 staging area has been accepted.
|-
|Android USB gadget driver
|Support for Android as gadget device from host
|unknown
|? (not sure if needed for basic bringup or not, but would be really painful if missing)
|no one?
|
|-
|timed gpio
|perform gpio operations as a result of specified timeouts - mainly used to support vibrate feature.
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no? (is this needed for basic bringup?)
|Shuah Khan
|Enhancing ledtrig-timer with activate_once timer - Shuah working on a patch
|-
|timed output
|seems to just be a class for timed gpio items
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no? (required by timed_gpio)
|Shuah Khan
|Enhancing ledtrig-timer with activate_once timer - Shuah working on a patch
|-
|low memory killer
|feature to manage application lifecycle in low memory conditions
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes (but system might work without it)
|Anton Vorontsov
|See https://lkml.org/lkml/2011/12/18/173 for discussion about these patches
|-
|ram console
|ability to save console output to a reserved ram area for diagnostics on a subsequent boot
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no
|Shuah Khan
|No lkml submission attempt history found so far. pstore fs interface solves the same problem and is in mainline 3.1.5. fs/pstore Reference - http://lwn.net/Articles/421297/ After investigating and discussing ram console use cases, it is clear that the proposal to use ram-oops and pstore will not be a complete solution to cover all the cases. Hence, the going forward plan is to pursue ram console inclusion in the mainline. ram console is going through re-write splitting it into twp drivers. Waiting for these changes to get into the 3.3 staging area. For now working with the unofficial patches.
|-
|ion graphics memory driver
|graphics memory drivers thingie
|not mainlined
|yes (for 4.0 and later?)
|Jesse Barker
|
|}

== Progress Chart ==
This section is intended to show our progress, by showing the patch set size over time. With any luck, as
we get features into mainline, the difference between the Android kernel and the legacy Linux kernel will shrink.

* diff of 2.6.29 kernel.org tree versus kernel
{| border="1" cellspacing="0" cellpadding="5"
|-bgcolor="#80c0d0"
!Kernel Version
!Files changed
!insertions
!deletions
!hunks
!bytes in diff
|-
|2.6.29 || 187 || 123506 || 0 || 187 || 3291827
|-
|}

[[Category:Android]]

Android Mainlining Project

2012-03-19T23:15:04Z

TimBird: /* Patch/Feature Status Chart */ change mainline status with 3.3 kernel release

This page is for organizing the Android Mainlining Project. It has information and resources associated with this
project.

== Goal ==
The goal of this project is to ultimately mainline all patches required to run the current released
version of Android. The purpose of mainlining these patches is 3-fold:
# to allow a developer to use the latest released version of the Linux kernel to run an Android system, without requiring patches to their kernel
# to make it possible to develop drivers and board support features against either an Android kernel release or a kernel.org kernel release, with little or no modifications or conditional code
# to reduce or eliminate the burden of maintaining independent patches from release to release for Android kernel developers

To "mainline" a patch means to have it included in Linus Torvalds kernel.org kernel, in a released (non-rc) version.

== Process ==
[This is a draft section, up for discussion]

Overall:
* identify all patches/features, and categorize into core or non/core
** core = feature is required or strongly desired for Android operation on a platform
** non-core = Most of the Android system can run without the feature

Per feature or patch:
* research any previous submission feedback
* incorporate feedback, as appropriate
* negotiate any interface changes with Google Android team
* submit updated patches to mainline
* repeat until accepted

== Resources ==
* Mailing list: https://lists.linuxfoundation.org/mailman/listinfo/ce-android-mainline
* Linaro blueprint for project: https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-android-upstreaming

== Meetings ==
* Meeting: [[Android mainlining interest group meeting 2012]]
** Summary: 9:30- 12:00 February 10, 2012 at the Sofitel Hotel in Redwood Shores, California.

== People ==
People who have expressed interest in this project are:

* Tim Bird
* John Stultz
* Paul McKenney
* Deepak Saxena
* Arnd Bergmann
* Thomas Gleixner
* Arjan Van de Ven
* Brian Swetland
* Tetsuyuki Kobayashi
* Andy Green
* Victor M. Jaquez
* Jesse Barker
* Anton Vorontsov
* Greg Kroah-Hartman
* Shuah Khan

=== roles/expertise ===
This section has miscellaneous notes on roles, capabilities and expertise of group's members

John Stultz is the owner of the Linaro blueprint for mainlining Android features.
Tim Bird is the owner of the CE Workgroup project for mainlining Android features.
Deepak and Jesse can help make arrangements for a meeting at Linaro Connect.
Tim can help make arrangements for a meeting at Android Builders Summit.

* John Stultz has worked on POSIX Alarm timers
* Jesse is working on shared memory buffers related to pmem/CMA/parts of ion
* Anton Vorontsov is looking at the lowmemory killer
* Greg has put some Android patches into mainline (under drivers/staging/android) previously
** Greg put some Android patches in mainline under drivers/staging/android in Dec. 2011
* Paul McKenney - kicking around ideas for dealing with wakelocks single global lock (dec. 2011)

== Plans ==
* Update this site with information on latest patch status - ongoing, by anyone
** [FIXTHIS - add sections needing a status or status update]

== Patch/Feature Status Chart ==
{| border="1" cellspacing="0" cellpadding="5"
|-bgcolor="#80c0d0"
!Feature/Patch
!Description
!Status
!Part of core?
!Owner/Interested parties
|Notes
|-
|[[Android_logger|logger]]
|kernel support for Android system logging
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|Tim Bird
|should be non-controversial (though I'm always surprised)
See [[Mainline Android logger project]] for a list of ideas, issues and a project plan for this feature
Also see [http://lkml.indiana.edu/hypermail/linux/kernel/1112.2/index.html#02419 this LKML discussion thread]
Some cleanup patches in linux-next, with more extensive changes to be written, tested, reviewed by Tim in Spring 2012.
|-
|wakelocks
|Power management locking mechanism to prevent opportunistic suspend
|not mainlined
|yes
|Rafael Wysocki
|Is important due to impact on board support and drivers by 3rd parties
|-
|Android alarm timers
|Timers that count down during suspended operation, and can wake from suspend
|Partial: Posix alarm timers were mainlined in kernel version 2.6.38 - see https://lwn.net/Articles/429925/
|yes
|John Stultz
|Mending patches to convert Android Alarm Timers to utilize the upstreamed alarm timer work are still pending.
|-
|ashmem
|Shared memory implementation that allows unpinned pages to be marked, which can be dropped by the kernel under memory pressure
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|John Stultz
|Working on fadvise volatile alternative implementation that handles part of the ashmem functionality. However, there are additional aspects of ashmem design that need to be addressed(no tmpfs mounts, atomic create/unlink behavior,etc).
|-
|network security
|special permission checks for secure access to network operations
|not mainlined
|? (can run without it, but network security won't be enforced)
|no one
|May be very difficult to mainline, as the code is extremely Android-specific with hardcoded GIDs and capabilities.
|-
|[[Android_Binder|binder]]
|Android inter-process communication mechanism
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes
|no one
|Generated a fair amount of discussion on last submission. See http://elinux.org/Android_Binder#obstacles_to_mainlining
|-
|Android pmem driver
|manages large (1-16+MB) contiguous physical memory regions to be shared between userspace and kernel drivers (dsp, gpu etc.)
|Removed - no longer in use
|yes
|Shuah Khan
|Investigating existing alternatives. Can CMA (Contiguous Memory Allocator) fill the need? Based on recent lkml discussion, pmem.c is no longer used and will be removed from Android release. Reference: https://lkml.org/lkml/2012/1/23/183 - Patch to remove pmem.c from 3.3-rc1 staging area has been accepted.
|-
|Android USB gadget driver
|Support for Android as gadget device from host
|unknown
|? (not sure if needed for basic bringup or not, but would be really painful if missing)
|no one?
|
|-
|timed gpio
|perform gpio operations as a result of specified timeouts - mainly used to support vibrate feature.
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no? (is this needed for basic bringup?)
|Shuah Khan
|Enhancing ledtrig-timer with activate_once timer - Shuah working on a patch
|-
|timed output
|seems to just be a class for timed gpio items
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no? (required by timed_gpio)
|Shuah Khan
|Enhancing ledtrig-timer with activate_once timer - Shuah working on a patch
|-
|low memory killer
|feature to manage application lifecycle in low memory conditions
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|yes (but system might work without it)
|Anton Vorontsov
|See https://lkml.org/lkml/2011/12/18/173 for discussion about these patches
|-
|ram console
|ability to save console output to a reserved ram area for diagnostics on a subsequent boot
|in drivers/staging/android, in kernel version 3.3 2012.03.19
|no
|Shuah Khan
|No lkml submission attempt history found so far. pstore fs interface solves the same problem and is in mainline 3.1.5. fs/pstore Reference - http://lwn.net/Articles/421297/ After investigating and discussing ram console use cases, it is clear that the proposal to use ram-oops and pstore will not be a complete solution to cover all the cases. Hence, the going forward plan is to pursue ram console inclusion in the mainline. ram console is going through re-write splitting it into twp drivers. Waiting for these changes to get into the 3.3 staging area. For now working with the unofficial patches.
|-
|ion graphics memory driver
|graphics memory drivers thingie
|not mainlined
|yes (for 4.0 and later?)
|Jesse Barker
|
|}

== Progress Chart ==
This section is intended to show our progress, by showing the patch set size over time. With any luck, as
we get features into mainline, the difference between the Android kernel and the legacy Linux kernel will shrink.

* diff of 2.6.29 kernel.org tree versus kernel
{| border="1" cellspacing="0" cellpadding="5"
|-bgcolor="#80c0d0"
!Kernel Version
!Files changed
!insertions
!deletions
!hunks
!bytes in diff
|-
|2.6.29 || 187 || 123506 || 0 || 187 || 3291827
|-
|}

[[Category:Android]]

Compact Flash

2008-11-17T18:00:18Z

TimBird: just reference Wikipedia compact flash page.

See http://en.wikipedia.org/wiki/CompactFlash

[[Category:Hardware]]

Technical Conference 2006 Planning

2008-11-17T17:55:17Z

TimBird: Remove spurious link to McKenny (from MoinMoin conversion)

Ideas for speakers:
- David Schleef - [[GStreamer]]
- Greg Kroah Hartman - Participating in Open Source
- Matt Mackall - Linux size??, Overview of Linux options
- ??? - Systemtap, tracing, etc.
- Pavel Machek or Patrick Mochel or Nigel Cunningham - Power Management
- Paul McKenney or Ingo Molnar or Karim Yaghmour - Realtime
- ??? - Security

Ideas for Topics:
- power management
- realtime
- security
- size
- bootup time

See
* [[Embedded Linux Conference 2006]]
* [[ELC 2006 Call For Presentations]]
* [[Celf Pri Wiki]]:[[Tech Conference April 2006]]

[[Category:Events]]

UTF8 Sampler

2008-11-17T17:54:24Z

TimBird: Remove spurious link to McGarry (from MoinMoin conversion)

UTF-8 SAMPLER
¥ · £ · € · $ · ¢ · ₡ · ₢ · ₣ · ₤ · ₥ · ₦ · ₧ · ₨ · ₩ · ₪ · ₫ · ₭ · ₮ · ₯

Frank da Cruz
The Kermit Project - Columbia University
New York City
fdc@columbia.edu

Last update: Sun Jun 12 20:24:10 2005

[ PEACE ] [ Poetry ] [ I Can Eat Glass ] [ The Quick Brown Fox ] [ HTML Features ] [ Credits, Tools, Commentary ]

UTF-8 is an ASCII-preserving encoding method for Unicode (ISO 10646), the Universal Character Set (UCS). The UCS encodes most of the world's writing systems in a single character set, allowing you to mix languages and scripts within a document without needing any tricks for switching character sets. This web page is encoded directly in UTF-8.

As shown HERE, Columbia University's Kermit 95 terminal emulation software can display UTF-8 plain text in Windows 95, 98, ME, NT, XP, or 2000 when using a monospace Unicode font like Andale Mono WT J or Everson Mono Terminal, or the lesser populated Courier New, Lucida Console, or Andale Mono. C-Kermit can handle it too, if you have a Unicode display. As many languages as are representable in your font can be seen on the screen at the same time.

This, however, is a Web page. Some Web browsers can handle UTF-8, some can't. And those that can might not have a sufficiently populated font to work with (some browsers might pick glyphs dynamically from multiple fonts; Netscape 6 seems to do this). CLICK HERE for a survey of Unicode fonts for Windows.

The subtitle above shows currency symbols of many lands. If they don't appear as blobs, we're off to a good start
Poetry
From the Anglo-Saxon Rune Poem (Rune version):

ᚠᛇᚻ᛫ᛒᛦᚦ᛫ᚠᚱᚩᚠᚢᚱ᛫ᚠᛁᚱᚪ᛫ᚷᛖᚻᚹᛦᛚᚳᚢᛗ
ᛋᚳᛖᚪᛚ᛫ᚦᛖᚪᚻ᛫ᛗᚪᚾᚾᚪ᛫ᚷᛖᚻᚹᛦᛚᚳ᛫ᛗᛁᚳᛚᚢᚾ᛫ᚻᛦᛏ᛫ᛞᚫᛚᚪᚾ
ᚷᛁᚠ᛫ᚻᛖ᛫ᚹᛁᛚᛖ᛫ᚠᚩᚱ᛫ᛞᚱᛁᚻᛏᚾᛖ᛫ᛞᚩᛗᛖᛋ᛫ᚻᛚᛇᛏᚪᚾ᛬

From Laȝamon's Brut (The Chronicles of England, Middle English, West Midlands):

An preost wes on leoden, Laȝamon was ihoten
He wes Leovenaðes sone -- liðe him be Drihten.
He wonede at Ernleȝe at æðelen are chirechen,
Uppen Sevarne staþe, sel þar him þuhte,
Onfest Radestone, þer he bock radde.

(The third letter in the author's name is Yogh, missing from many fonts; CLICK HERE for another Middle English sample with some explanation of letters and encoding).

From the Tagelied of Wolfram von Eschenbach (Middle High German):

Sîne klâwen durh die wolken sint geslagen,
er stîget ûf mit grôzer kraft,
ich sih in grâwen tägelîch als er wil tagen,
den tac, der im geselleschaft
erwenden wil, dem werden man,
den ich mit sorgen în verliez.
ich bringe in hinnen, ob ich kan.
sîn vil manegiu tugent michz leisten hiez.

Some lines of Odysseus Elytis (Greek):

Τη γλώσσα μου έδωσαν ελληνική
το σπίτι φτωχικό στις αμμουδιές του Ομήρου.
Μονάχη έγνοια η γλώσσα μου στις αμμουδιές του Ομήρου.

από το Άξιον Εστί
του Οδυσσέα Ελύτη

The first stanza of Pushkin's Bronze Horseman (Russian):

На берегу пустынных волн
Стоял он, дум великих полн,
И вдаль глядел. Пред ним широко
Река неслася; бедный чёлн
По ней стремился одиноко.
По мшистым, топким берегам
Чернели избы здесь и там,
Приют убогого чухонца;
И лес, неведомый лучам
В тумане спрятанного солнца,
Кругом шумел.

Šota Rustaveli's Veṗxis Ṭq̇aosani, ̣︡Th, The Knight in the Tiger's Skin (Georgian):

ვეპხის ტყაოსანი შოთა რუსთაველი

ღმერთსი შემვედრე, ნუთუ კვლა დამხსნას სოფლისა შრომასა, ცეცხლს, წყალსა და მიწასა, ჰაერთა თანა მრომასა; მომცნეს ფრთენი და აღვფრინდე, მივჰხვდე მას ჩემსა ნდომასა, დღისით და ღამით ვჰხედვიდე მზისა ელვათა კრთომაასა.

Tamil poetry of Cupiramaniya Paarathiyar, சுப்ரமணிய பாரதியார் (1882-1921):

யாமறிந்த மொழிகளிலே தமிழ்மொழி போல் இனிதாவது எங்கும் காணோம்,
பாமரராய் விலங்குகளாய், உலகனைத்தும் இகழ்ச்சிசொலப் பான்மை கெட்டு,
நாமமது தமிழரெனக் கொண்டு இங்கு வாழ்ந்திடுதல் நன்றோ? சொல்லீர்

I Can Eat Glass
And from the sublime to the ridiculous, here is a certain phrase¹ in an assortment of languages:

1. Sanskrit: काचं शक्नोम्यत्तुम् । नोपहिनस्ति माम् ॥
2. Sanskrit (standard transcription): kācaṃ śaknomyattum; nopahinasti mām.
3. Classical Greek: ὕαλον ϕαγεῖν δύναμαι· τοῦτο οὔ με βλάπτει.
4. Greek: Μπορώ να φάω σπασμένα γυαλιά χωρίς να πάθω τίποτα.
Etruscan: (NEEDED)
5. Latin: Vitrum edere possum; mihi non nocet.
6. Old French: Je puis mangier del voirre. Ne me nuit.
7. French: Je peux manger du verre, ça ne me fait pas de mal.
8. Provençal / Occitan: Pòdi manjar de veire, me nafrariá pas.
9. Québécois: J'peux manger d'la vitre, ça m'fa pas mal.
10. Walloon: Dji pou magnî do vêre, çoula m' freut nén må.
Champenois: (NEEDED)
Lorrain: (NEEDED)
11. Picard: Ch'peux mingi du verre, cha m'foé mie n'ma.
Corsican: (NEEDED)
12. Kreyòl Ayisyen: Mwen kap manje vè, li pa blese'm.
13. Basque: Kristala jan dezaket, ez dit minik ematen.
14. Catalan: Puc menjar vidre que no em fa mal.
15. Spanish: Puedo comer vidrio, no me hace daño.
16. Aragones: Puedo minchar beire, no me'n fa mal .
17. Galician: Eu podo xantar cristais e non cortarme.
18. Portuguese: Posso comer vidro, não me faz mal.
19. Brazilian Portuguese (7): Posso comer vidro, não me machuca.
20. Caboverdiano: M' podê cumê vidru, ca ta maguâ-m'.
21. Papiamentu: Ami por kome glas anto e no ta hasimi daño.
22. Italian: Posso mangiare il vetro e non mi fa male.
23. Milanese: Sôn bôn de magnà el véder, el me fa minga mal.
24. Roman: Me posso magna' er vetro, e nun me fa male.
25. Napoletano: M' pozz magna' o'vetr, e nun m' fa mal.
26. Sicilian: Puotsu mangiari u vitru, nun mi fa mali.
27. Venetian: Mi posso magnare el vetro, no'l me fa mae.
28. Zeneise (Genovese): Pòsso mangiâ o veddro e o no me fà mâ.
Rheto-Romance / Romansch: (NEEDED)
Romany / Tsigane: (NEEDED)
29. Romanian: Pot să mănânc sticlă și ea nu mă rănește.
30. Esperanto: Mi povas manĝi vitron, ĝi ne damaĝas min.
Pictish: (NEEDED)
Breton: (NEEDED)
31. Cornish: Mý a yl dybry gwéder hag éf ny wra ow ankenya.
32. Welsh: Dw i'n gallu bwyta gwydr, 'dyw e ddim yn gwneud dolur i mi.
33. Manx Gaelic: Foddym gee glonney agh cha jean eh gortaghey mee.
34. Old Irish (Ogham): ᚛᚛ᚉᚑᚅᚔᚉᚉᚔᚋ ᚔᚈᚔ ᚍᚂᚐᚅᚑ ᚅᚔᚋᚌᚓᚅᚐ᚜
35. Old Irish (Latin): Con·iccim ithi nglano. Ním·géna.
36. Irish: Is féidir liom gloinne a ithe. Ní dhéanann sí dochar ar bith dom.
37. Scottish Gaelic: S urrainn dhomh gloinne ithe; cha ghoirtich i mi.
38. Anglo-Saxon (Runes): ᛁᚳ᛫ᛗᚨᚷ᛫ᚷᛚᚨᛋ᛫ᛖᚩᛏᚪᚾ᛫ᚩᚾᛞ᛫ᚻᛁᛏ᛫ᚾᛖ᛫ᚻᛖᚪᚱᛗᛁᚪᚧ᛫ᛗᛖ᛬
39. Anglo-Saxon (Latin): Ic mæg glæs eotan ond hit ne hearmiað me.
40. Middle English: Ich canne glas eten and hit hirtiþ me nouȝt.
41. English: I can eat glass and it doesn't hurt me.
42. English (IPA): [aɪ kæn iːt glɑːs ænd ɪt dɐz nɒt hɜːt miː] (Received Pronunciation)
43. English (Braille): ⠊⠀⠉⠁⠝⠀⠑⠁⠞⠀⠛⠇⠁⠎⠎⠀⠁⠝⠙⠀⠊⠞⠀⠙⠕⠑⠎⠝⠞⠀⠓⠥⠗⠞⠀⠍⠑
44. Lalland Scots / Doric: Ah can eat gless, it disnae hurt us.
Glaswegian: (NEEDED)
45. Gothic (4): ̼̰̲ ̴̲̻̓ ̹̰̈̈́̽, ̹̽ ̼̹̓ ̿ͅ ̳̰̽̽ ̸̱̹̲̲̹͂.
46. Old Norse (Runes): ᛖᚴ ᚷᛖᛏ ᛖᛏᛁ ᚧ ᚷᛚᛖᚱ ᛘᚾ ᚦᛖᛋᛋ ᚨᚧ ᚡᛖ ᚱᚧᚨ ᛋᚨᚱ
47. Old Norse (Latin): Ek get etið gler án þess að verða sár.
48. Norsk / Norwegian (Nynorsk): Eg kan eta glas utan å skada meg.
49. Norsk / Norwegian (Bokmål): Jeg kan spise glass uten å skade meg.
Føroyskt / Faroese: (NEEDED)
50. Íslenska / Icelandic: Ég get etið gler án þess að meiða mig.
51. Svenska / Swedish: Jag kan äta glas utan att skada mig.
52. Dansk / Danish: Jeg kan spise glas, det gør ikke ondt på mig.
53. Soenderjysk: Æ ka æe glass uhen at det go mæ naue.
54. Frysk / Frisian: Ik kin glês ite, it docht me net sear.
55. Nederlands / Dutch: Ik kan glas eten, het doet mĳ geen kwaad.
56. Kirchröadsj/Bôchesserplat: Iech ken glaas èèse, mer 't deet miech jing pieng.
57. Afrikaans: Ek kan glas eet, maar dit doen my nie skade nie.
58. Lëtzebuergescht / Luxemburgish: Ech kan Glas iessen, daat deet mir nët wei.
59. Deutsch / German: Ich kann Glas essen, ohne mir weh zu tun.
60. Ruhrdeutsch: Ich kann Glas verkasematuckeln, ohne dattet mich wat jucken tut.
61. Lausitzer Mundart ("Lusatian"): Ich koann Gloos assn und doas dudd merr ni wii.
62. Odenwälderisch: Iech konn glaasch voschbachteln ohne dass es mir ebbs daun doun dud.
63. Sächsisch / Saxon: 'sch kann Glos essn, ohne dass'sch mer wehtue.
64. Pfälzisch: Isch konn Glass fresse ohne dasses mer ebbes ausmache dud.
65. Schwäbisch / Swabian: I kå Glas frässa, ond des macht mr nix
66. Bayrisch / Bavarian: I koh Glos esa, und es duard ma ned wei.
67. Allemannisch: I kaun Gloos essen, es tuat ma ned weh.
68. Schwyzerdütsch: Ich chan Glaas ässe, das tuet mir nöd weeh.
69. Hungarian: Meg tudom enni az üveget, nem lesz tőle bajom.
70. Suomi / Finnish: Voin syödä lasia, se ei vahingoita minua.
71. Sami (Northern): Sáhtán borrat lása, dat ii leat bávččas.
72. Erzian: Мон ярсан суликадо, ды зыян эйстэнзэ а ули.
Karelian: (NEEDED)
Vepsian: (NEEDED)
Votian: (NEEDED)
Livonian: (NEEDED)
73. Estonian: Ma võin klaasi süüa, see ei tee mulle midagi.
74. Latvian: Es varu ēst stiklu, tas man nekaitē.
75. Lithuanian: Aš galiu valgyti stiklą ir jis manęs nežeidžia
Old Prussian: (NEEDED)
Sorbian (Wendish): (NEEDED)
76. Czech: Mohu jíst sklo, neublíží mi.
77. Slovak: Môžem jesť sklo. Nezraní ma.
78. Polska / Polish: Mogę jeść szkło i mi nie szkodzi.
79. Slovenian: Lahko jem steklo, ne da bi mi škodovalo.
80. Croatian: Ja mogu jesti staklo i ne boli me.
81. Serbian (Latin): Mogu jesti staklo a da mi ne škodi.
82. Serbian (Cyrillic): Могу јести стакло а да ми не шкоди.
83. Macedonian: Можам да јадам стакло, а не ме штета.
84. Russian: Я могу есть стекло, оно мне не вредит.
85. Belarusian (Cyrillic): Я магу есці шкло, яно мне не шкодзіць.
86. Belarusian (Lacinka): Ja mahu jeści škło, jano mne ne škodzić.
87. Ukrainian: Я можу їсти шкло, й воно мені не пошкодить.
88. Bulgarian: Мога да ям стъкло, то не ми вреди.
89. Georgian: მინას ვჭამ და არა მტკივა.
90. Armenian: Կրնամ ապակի ուտել և ինծի անհանգիստ չըներ։
91. Albanian: Unë mund të ha qelq dhe nuk më gjen gjë.
92. Turkish: Cam yiyebilirim, bana zararı dokunmaz.
93. Turkish (Ottoman): جام ييه بلورم بڭا ضررى طوقونمز
94. Bangla / Bengali: আমি কাঁচ খেতে পারি, তাতে আমার কোনো ক্ষতি হয় না।
95. Marathi: मी काच खाऊ शकतो, मला ते दुखत नाही.
96. Hindi: मैं काँच खा सकता हूँ, मुझे उस से कोई पीडा नहीं होती.
97. Tamil: நான் கண்ணாடி சாப்பிடுவேன், அதனால் எனக்கு ஒரு கேடும் வராது.
98. Urdu(2): میں کانچ کھا سکتا ہوں اور مجھے تکلیف نہیں ہوتی ۔
99. Pashto(2): زه شيشه خوړلې شم، هغه ما نه خوږوي
100. Farsi / Persian: .من می توانم بدونِ احساس درد شيشه بخورم
101. Arabic(2): أنا قادر على أكل الزجاج و هذا لا يؤلمني.
Aramaic: (NEEDED)
102. Hebrew(2): אני יכול לאכול זכוכית וזה לא מזיק לי.
103. Yiddish(2): איך קען עסן גלאָז און עס טוט מיר נישט װײ.
Judeo-Arabic: (NEEDED)
Ladino: (NEEDED)
Gǝʼǝz: (NEEDED)
Amharic: (NEEDED)
104. Twi: Metumi awe tumpan, ɜnyɜ me hwee.
105. Hausa (Latin): Inā iya taunar gilāshi kuma in gamā lāfiyā.
106. Hausa (Ajami) (2): إِنا إِىَ تَونَر غِلَاشِ كُمَ إِن غَمَا لَافِىَا
107. Yoruba(3): Mo lè je̩ dígí, kò ní pa mí lára.
108. (Ki)Swahili: Naweza kula bilauri na sikunyui.
109. Malay: Saya boleh makan kaca dan ia tidak mencederakan saya.
110. Tagalog: Kaya kong kumain nang bubog at hindi ako masaktan.
111. Chamorro: Siña yo' chumocho krestat, ti ha na'lalamen yo'.
112. Javanese: Aku isa mangan beling tanpa lara.
Burmese: (NEEDED)
113. Vietnamese (quốc ngữ): Tôi có thể ăn thủy tinh mà không hại gì.
114. Vietnamese (nôm) (4): 些㎏世咹水晶擡空㎏害咦
Khmer: (NEEDED)
Lao: (NEEDED)
115. Thai: ฉันกินกระจกได้ แต่มันไม่ทำให้ฉันเจ็บ
116. Mongolian (Cyrillic): Би шил идэй чадна, надад хортой биш
117. Mongolian (Classic) (5): ᠪᠢ ᠰᠢᠯᠢ ᠢᠳᠡᠶᠦ ᠴᠢᠳᠠᠨᠠ ᠂ ᠨᠠᠳᠤᠷ ᠬᠣᠤᠷᠠᠳᠠᠢ ᠪᠢᠰᠢ
Dzongkha: (NEEDED)
Nepali: (NEEDED)
118. Tibetan: ཤེལ་སྒོ་ཟ་ནས་ང་ན་གི་མ་རེད།
119. Chinese: 我能吞下玻璃而不伤身体。
120. Chinese (Traditional): 我能吞下玻璃而不傷身體。
121. Taiwanese(6): Góa ē-tàng chia̍h po-lê, mā bē tio̍h-siong.
122. Japanese: 私はガラスを食べられます。それは私を傷つけません。
123. Korean: 나는 유리를 먹을 수 있어요. 그래도 아프지 않아요
124. Bislama: Mi save kakae glas, hemi no save katem mi.
125. Hawaiian: Hiki iaʻu ke ʻai i ke aniani; ʻaʻole nō lā au e ʻeha.
126. Marquesan: E koʻana e kai i te karahi, mea ʻā, ʻaʻe hauhau.
127. Chinook Jargon: Naika məkmək kakshət labutay, pi weyk ukuk munk-sik nay.
128. Navajo: Tsésǫʼ yishą́ągo bííníshghah dóó doo shił neezgai da.
Cherokee (and Cree, Ojibwa, Inuktitut, and other Native American languages): (NEEDED)
Garifuna: (NEEDED)
Gullah: (NEEDED)
129. Lojban: mi kakne le nu citka le blaci .iku'i le se go'i na xrani mi
130. Nórdicg: Ljœr ye caudran créneþ ý jor cẃran.

(Additions, corrections, completions, gratefully accepted.)

For testing purposes, some of these are repeated in a monospace font . . .

1. Euro Symbol: €.
2. Greek: Μπορώ να φάω σπασμένα γυαλιά χωρίς να πάθω τίποτα.
3. Íslenska / Icelandic: Ég get etið gler án þess að meiða mig.
4. Polish: Mogę jeść szkło, i mi nie szkodzi.
5. Romanian: Pot să mănânc sticlă și ea nu mă rănește.
6. Ukrainian: Я можу їсти шкло, й воно мені не пошкодить.
7. Armenian: Կրնամ ապակի ուտել և ինծի անհանգիստ չըներ։
8. Georgian: მინას ვჭამ და არა მტკივა.
9. Hindi: मैं काँच खा सकता हूँ, मुझे उस से कोई पीडा नहीं होती.
10. Hebrew(2): אני יכול לאכול זכוכית וזה לא מזיק לי.
11. Yiddish(2): איך קען עסן גלאָז און עס טוט מיר נישט װײ.
12. Arabic(2): أنا قادر على أكل الزجاج و هذا لا يؤلمني.
13. Japanese: 私はガラスを食べられます。それは私を傷つけません。
14. Thai: ฉันกินกระจกได้ แต่มันไม่ทำให้ฉันเจ็บ

Notes:

The "I can eat glass" phrase and initial translations (about 30 of them) were borrowed from Ethan Mollick's I Can Eat Glass page (which disappeared on or about June 2004) and converted to UTF-8. Since Ethan's original page is gone, I should mention that his purpose was offer travelers a phrase they could use in any country that would command a certain kind of respect, or at least get attention. See Credits for the many additional contributions since then. When submitting new entries, the word "hurt" (if you have a choice) is used in the sense of "cause harm", "do damage", or "bother", rather than "inflict pain" or "make sad". In this vein Otto Stolz comments (as do others further down; personally I think it's better for the purpose of this page to have extra entries and/or to show a greater repertoire of characters than it is to enforce a strict interpretation of the word "hurt"):

This is the meaning I have translated to the Swabian dialect. However, I just have noticed that most of the German variants translate the "inflict pain" meaning. The German example should rather read:

"Ich kann Glas essen ohne mir zu schaden."

(The comma fell victim to the 1996 orthographic reform, cf. http://www.ids-mannheim.de/reform/e3-1.html#P76.

You may wish to contact the contributors of the following translations to correct them:

* Lëtzebuergescht / Luxemburgish: Ech kan Glas iessen, daat deet mir nët wei.
* Lausitzer Mundart ("Lusatian"): Ich koann Gloos assn und doas dudd merr ni wii.
* Sächsisch / Saxon: 'sch kann Glos essn, ohne dass'sch mer wehtue.
* Bayrisch / Bavarian: I koh Glos esa, und es duard ma ned wei.
* Allemannisch: I kaun Gloos essen, es tuat ma ned weh.
* Schwyzerdütsch: Ich chan Glaas ässe, das tuet mir nöd weeh.

In contrast, I deem the following translations *alright*:

* Ruhrdeutsch: Ich kann Glas verkasematuckeln, ohne dattet mich wat jucken tut.
* Pfälzisch: Isch konn Glass fresse ohne dasses mer ebbes ausmache dud.
* Schwäbisch / Swabian: I kå Glas frässa, ond des macht mr nix

(However, you could remove the commas, on account of http://www.ids-mannheim.de/reform/e3-1.html#P76 and http://www.ids-mannheim.de/reform/e3-1.html#P72, respectively.)

I guess, also these examples translate the wrong sense of "hurt", though I do not know these languages well enough to assert them definitely:

* Nederlands / Dutch: Ik kan glas eten; het doet mĳ geen pĳn. (This one has been changed)
* Kirchröadsj/Bôchesserplat: Iech ken glaas èèse, mer 't deet miech jing pieng.

In the Romanic languages, the variations on "fa male" (it) are probably wrong, whilst the variations on "hace daño" (es) and "damaĝas" (Esperanto) are probably correct; "nocet" (la) is definitely right.

The northern Germanic variants of "skada" are probably right, as are the Slavic variants of "škodi/шкоди" (se); however the Slavic variants of " boli" (hv) are probably wrong, as "bolena" means "pain/ache", IIRC.

# The numbering of the samples is arbitrary, done only to keep track of how many there are, and can change any time a new entry is added. The arrangement is also arbitrary but with some attempt to group related examples together. Note: All languages not listed are wanted, not just the ones that say (NEEDED).
# Correct right-to-left display of these languages depends on the capabilities of your browser. The period should appear on the left. In the monospace Yiddish example, the Yiddish digraphs should occupy one character cell.
# Yoruba: The third word is Latin letter small 'j' followed by small 'e' with U+0329, Combining Vertical Line Below. This displays correctly only if your Unicode font includes the U+0329 glyph and your browser supports combining diacritical marks. The Indic examples also include combining sequences.
# Includes Unicode 3.1 (or later) characters beyond Plane 0.
# The Classic Mongolian example should be vertical, top-to-bottom and left-to-right. But such display is almost impossible. Also no font yet exists which provides the proper ligatures and positional variants for the characters of this script, which works somewhat like Arabic.
# Taiwanese is also known as Holo or Hoklo, and is related to Southern Min dialects such as Amoy. Contributed by Henry H. Tan-Tenn, who comments, "The above is the romanized version, in a script current among Taiwanese Christians since the mid-19th century. It was invented by British missionaries and saw use in hundreds of published works, mostly of a religious nature. Most Taiwanese did not know Chinese characters then, or at least not well enough to read. More to the point, though, a written standard using Chinese characters has never developed, so a significant minority of words are represented with different candidate characters, depending on one's personal preference or etymological theory. In this sentence, for example, "-tàng", "chia̍h", "mā" and "bē" are problematic using Chinese characters. "Góa" (I/me) and "po-lê" (glass) are as written in other Sinitic languages (e.g. Mandarin, Hakka)."
# Wagner Amaral of Pinese & Amaral Associados notes that the Brazilian Portuguese sentence for "I can eat glass" should be identical to the Portuguese one, as the word "machuca" means "inflict pain", or rather "injuries". The words "faz mal" would more correctly translate as "cause harm".

The Quick Brown Fox

The "I can eat glass" sentences do not necessarily show off the orthography of each language to best advantage. In many alphabetic written languages it is possible to include all (or most) letters (or "special" characters) in a single (often nonsense) pangram. These were traditionally used in typewriter instruction; now they are useful for stress-testing computer fonts and keyboard input methods. Here are a few examples (SEND MORE):

1. English: The quick brown fox jumps over the lazy dog.
2. Irish: "An ḃfuil do ċroí ag bualaḋ ó ḟaitíos an ġrá a ṁeall lena ṗóg éada ó ṡlí do leasa ṫú?" "D'ḟuascail Íosa Úrṁac na hÓiġe Beannaiṫe pór Éava agus Áḋaiṁ."
3. Dutch: Pa's wĳze lynx bezag vroom het fikse aquaduct.
4. German: Falsches Üben von Xylophonmusik quält jeden größeren Zwerg. (1)
5. German: Im finſteren Jagdſchloß am offenen Felsquellwaſſer patzte der affig-flatterhafte kauzig-höf‌liche Bäcker über ſeinem verſifften kniffligen C-Xylophon. (2)
6. Swedish: Flygande bäckasiner söka strax hwila på mjuka tuvor.
7. Czech: Příliš žluťoučký kůň úpěl ďábelské kódy.
8. Slovak: Starý kôň na hŕbe kníh žuje tíško povädnuté ruže, na stĺpe sa ďateľ učí kvákať novú ódu o živote.
9. Russian: В чащах юга жил-был цитрус? Да, но фальшивый экземпляр ёъ.
10. Bulgarian: Жълтата дюля беше щастлива, че пухът, който цъфна, замръзна като гьон.
11. Sami (Northern): Vuol Ruoŧa geđggiid leat máŋga luosa ja čuovžža.
12. Hungarian: Árvíztűrő tükörfúrógép.
13. Spanish: El pingüino Wenceslao hizo kilómetros bajo exhaustiva lluvia y frío, añoraba a su querido cachorro.
14. Portuguese: O próximo vôo à noite sobre o Atlântico, põe freqüentemente o único médico. (3)
15. French: Les naïfs ægithales hâtifs pondant à Noël où il gèle sont sûrs d'être déçus et de voir leurs drôles d'œufs abîmés.
16. Esperanto: Eĥoŝanĝo ĉiuĵaŭde.
17. Hebrew: זה כיף סתם לשמוע איך תנצח קרפד עץ טוב בגן.
18. Japanese (Hiragana):

いろはにほへど　ちりぬるを
わがよたれぞ　つねならむ
うゐのおくやま　けふこえて
あさきゆめみじ　ゑひもせず (4)

Notes:

# Other phrases commonly used in Germany include: "Ein wackerer Bayer vertilgt ja bequem zwo Pfund Kalbshaxe" and, more recently, "Franz jagt im komplett verwahrlosten Taxi quer durch Bayern", but both lack umlauts and esszet. Previously, going for the shortest sentence that has all the umlauts and special characters, I had "Grüße aus Bärenhöfe (und Óechtringen)" Acute accents are not used in native German words, so I was surprised to discover "Óechtringen" in the Deutsche Bundespost Postleitzahlenbuch (Vorsicht 2.8MB JPG image). It's a small village in eastern Lower Saxony. The "oe" in this case turns out to be the Lower Saxon "lengthening e" (Dehnungs-e), which makes the previous vowel long (used in a number of Lower Saxon place names such as Soest and Itzehoe), not the "e" that indicates umlaut of the preceding vowel. Many thanks to the Óechtringen-Namenschreibungsuntersuchungskomitee (Alex Bochannek, Manfred Erren, Asmus Freytag, Christoph Päper, plus Werner Lemberg who serves as the Óechtringen-Namenschreibungsuntersuchungskomiteerechtschreibungsprüfer) for their relentless pursuit of the facts in this case. Conclusion: the accent almost certainly does not belong on this (or any other native German) word, but neither can it be dismissed as dirt on the page. To add to the mystery, it has been reported that other copies of the same edition of the PLZB do not show the accent
# From Karl Pentzlin (Kochel am See, Bavaria, Germany): "This German phrase is suited for display by a Fraktur (broken letter) font. It contains: all common three-letter ligatures: ffi ffl fft and all two-letter ligatures required by the Duden for Fraktur typesetting: ch ck ff fi fl ft ll ſch ſi ſſ ſt tz (all in a manner such they are not part of a three-letter ligature), one example of f-l where German typesetting rules prohibit ligating (marked by a ZWNJ), and all German letters a...z, ä,ö,ü,ß, ſ [long s] (all in a manner such that they are not part of a two-letter Fraktur ligature)." Otto Stolz notes that "'Schloß' is now spelled 'Schloss', in contrast to 'größer' (example 4) which has kept its 'ß'. Fraktur has been banned from general use, in 1942, and long-s (ſ) has ceased to be used with Antiqua (Roman) even earlier (the latest Antiqua-ſ I have seen is from 1913, but then I am no expert, so there may well be a later instance." Later Otto confirms the latter theory, "Now I've run across a book “Deutsche Rechtschreibung” (edited by Lutz Mackensen) from 1954 (my reprint is from 1956) that has kept the Antiqua-ſ in its dictionary part (but neither in the preface nor in the appendix)."
# Diaeresis is not used in Iberian Portuguese.
# From Yurio Miyazawa: "This poetry contains all the sounds in the Japanese language and used to be the first thing for children to learn in their Japanese class. The Hiragana version is particularly neat because it covers every character in the phonetic Hiragana character set." Yurio also sent the Kanji version:

色は匂へど散りぬるを
我が世誰ぞ常ならむ
有為の奥山今日越えて
浅き夢見じ酔ひもせず

Accented Cyrillic:

(This section contributed by Vladimir Marinov.)

In Bulgarian it is desirable, customary, or in some cases required to write accents over vowels. Unfortunately, no computer character sets contain the full repertoire of accented Cyrillic letters. With Unicode, however, it is possible to combine any Cyrillic letter with any combining accent. The appearance of the result depends on the font and the rendering engine. Here are two examples.

# Той видя бялата коса́ по главата и́ и ко́са на рамото и́, и ре́че да и́ рече́: "Пара́та по́ па́ри от па́рата, не ща пари́", но си поми́сли: "Хей, помисли́ си А́ и́ река, а́ е скочила в тази река, която щеше да тече́, а не те́че."
# По пъ́тя пъту́ват кю́рди и югославя́ни.

HTML Features
Here is the Russian alphabet (uppercase only) coded in three different ways, which should look identical:

# АБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ (Literal UTF-8)
# АБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ (Decimal numeric character reference)
# АБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ (Hexadecimal numeric character reference)

In another test, we use HTML language tags to distinguish Bulgarian, Russian, and Serbian, which have different italic forms for lowercase б, г, д, п, and/or т:

Bulgarian: [ бгдпт ] [ бгдпт ] Мога да ям стъкло и не ме боли.
Russian: [ бгдпт ] [ бгдпт ] Я могу есть стекло, это мне не вредит.
Serbian: [ бгдпт ] [ бгдпт ] Могу јести стакло а да ми не шкоди.

Credits, Tools, and Commentary

Credits:

The "I can eat glass" phrase and the initial collection of translations: Ethan Mollick. Transcription / conversion to UTF-8: Frank da Cruz. Albanian: Sindi Keesan. Afrikaans: Johan Fourie, Kevin Poalses. Anglo Saxon: Frank da Cruz. Arabic: Najib Tounsi. Armenian: Vaçe Kundakçı. Belarusian: Alexey Chernyak. Bengali: Somnath Purkayastha, Deepayan Sarkar. Bislama: Dan Mc Garry. Braille: Frank da Cruz. Bulgarian: Sindi Keesan, Guentcho Skordev, Vladimir Marinov. Cabo Verde Creole: Cláudio Alexandre Duarte. Chinese: Jack Soo, Wong Pui Lam. Chinook Jargon: David Robertson. Cornish: Chris Stephens. Croatian: Marjan Baće. Czech: Stanislav Pecha, Radovan Garabík. Dutch: Peter Gotink. Pim Blokland, Rob Daniel, Rob de Wit. Erzian: Jack Rueter. Esperanto: Franko Luin, Radovan Garabík. Estonian: Meelis Roos. Farsi/Persian: Payam Elahi. Finnish: Sampsa Toivanen. French: Luc Carissimo, Anne Colin du Terrail, Sean M. Burke. Galician: Laura Probaos. Georgian: Giorgi Lebanidze. German: Christoph Päper, Otto Stolz, Karl Pentzlin, Frank da Cruz. Gothic: Aurélien Coudurier. Greek: Ariel Glenn, Constantine Stathopoulos, Siva Nataraja. Hebrew: Jonathan Rosenne, Tal Barnea. Hausa: Malami Buba, Tom Gewecke. Hawaiian: na Hauʻoli Motta, Anela de Rego, Kaliko Trapp. Hindi: Shirish Kalele. Hungarian: András Rácz, Mark Holczhammer. Icelandic: Andrés Magnússon. International Phonetic Alphabet (IPA): Siva Nataraja / Vincent Ramos. Irish: Michael Everson, Marion Gunn, James Kass, Curtis Clark. Italian: Thomas De Bellis. Japanese: Makoto Takahashi, Yurio Miyazawa. Kirchröadsj: Roger Stoffers. Kreyòl: Sean M. Burke. Korean: Jungshik Shin. Lëtzebuergescht: Stefaan Eeckels. Lithuanian: Gediminas Grigas. Lojban: Edward Cherlin. Lusatian: Ronald Schaffhirt. Macedonian: Sindi Keesan. Malay: Zarina Mustapha. Manx: Éanna Ó Brádaigh. Marathi: Shirish Kalele. Marquesan: Kaliko Trapp. Middle English: Frank da Cruz. Milanese: Marco Cimarosti. Mongolian: Tom Gewecke. Napoletano: Diego Quintano. Navajo: Tom Gewecke. Nórdicg: Yẃlyan Rott. Norwegian: Herman Ranes. Odenwälderisch: Alexander Heß. Old Irish: Michael Everson. Old Norse: Andrés Magnússon. Papiamentu: Bianca and Denise Zanardi. Pashto: N.R. Liwal. Pfälzisch: Dr. Johannes Sander. Picard: Philippe Mennecier. Polish: Juliusz Chroboczek. Portuguese: "Cláudio" Alexandre Duarte, Bianca and Denise Zanardi, Pedro Palhoto Matos, Wagner Amaral. Québécois: Laurent Detillieux. Roman: Pierpaolo Bernardi. Romanian: Juliusz Chroboczek, Ionel Mugurel. Ruhrdeutsch: "Timwi". Russian: Alexey Chernyak, Serge Nesterovitch. Sami: Anne Colin du Terrail, Luc Carissimo. Sanskrit: Siva Nataraja / Vincent Ramos. Sächsisch: André Müller. Schwäbisch: Otto Stolz. Scots: Jonathan Riddell. Serbian: Sindi Keesan, Ranko Narancic, Boris Daljevic, Szilvia Csorba. Slovak: G. Adam Stanislav, Radovan Garabík. Slovenian: Albert Kolar. Spanish: Aleida Muñoz, Laura Probaos. Swahili: Ronald Schaffhirt. Swedish: Christian Rose, Bengt Larsson. Taiwanese: Henry H. Tan-Tenn. Tagalog: Jim Soliven. Tamil: Vasee Vaseeharan. Tibetan: D. Germano, Tom Gewecke. Thai: Alan Wood's wife. Turkish: Vaçe Kundakçı, Tom Gewecke, Merlign Olnon. Ukrainian: Michael Zajac. Urdu: Mustafa Ali. Vietnamese: Dixon Au, [James] Đỗ Bá Phước 杜伯福. Walloon: Pablo Saratxaga. Welsh: Geiriadur Prifysgol Cymru (Andrew). Yiddish: Mark David, Zeneise: Angelo Pavese.

Tools Used to Create This Web Page:

The UTF8-aware Kermit 95 terminal emulator on Windows, to a Unix host with the EMACS text editor. Kermit 95 displays UTF-8 and also allows keyboard entry of arbitrary Unicode BMP characters as 4 hex digits, as shown HERE. Hex codes for Unicode values can be found in The Unicode Standard (recommended) and the online code charts. When submissions arrive by email encoded in some other character set (Latin-1, Latin-2, KOI, various PC code pages, JEUC, etc), I use the TRANSLATE command of C-Kermit on the Unix host (where I read my mail) to convert the character set to UTF-8 (I could also use Kermit 95 for this; it has the same TRANSLATE command). That's it -- no "Web authoring" tools, no locales, no "smart" anything. It's just plain text, nothing more. By the way, there's nothing special about EMACS -- any text editor will do, providing it allows entry of arbitrary 8-bit bytes as text, including the 0x80-0x9F "C1" range. EMACS 21.1 actually supports UTF-8; earlier versions don't know about it and display the octal codes; either way is OK for this purpose.

Commentary:

:Date: Wed, 27 Feb 2002 13:21:59 +0100
:From: Bruno DEDOMINICIS b.dedominicis@cite-sciences.fr
:Subject: Je peux manger du verre, cela ne me fait pas mal.

:I just found out your website and it makes me feel like proposing an interpretation of the choice of this peculiar phrase.

:Glass is transparent and can hurt as everyone knows. The relation between people and civilisations is sometimes effusional and more often rude. The concept of breaking frontiers through globalization, in a way, is also an attempt to deny any difference. Isn't "transparency" the flag of modernity? Nothing should be hidden any more, authority is obsolete, and the new powers are supposed to reign through loving and smiling and no more through coercion...

:Eating glass without pain sounds like a very nice metaphor of this attempt. That is, frontiers should become glass transparent first, and be denied by incorporating them. On the reverse, it shows that through globalization, frontiers undergo a process of displacement, that is, when they are not any more speakable, they become repressed from the speech and are therefore incorporated and might become painful symptoms, as for example what happens when one tries to eat glass.

:The frontiers that used to separate bodies one from another tend to divide bodies from within and make them suffer.... The chosen phrase then appears as a denial of the symptom that might result from the destitution of traditional frontiers.

:Best,<br>
:Bruno De Dominicis, Paris, France

Other Unicode pages onsite:

* Peace in All Languages
* Frank's Compulsive Guide to Postal Addresses (especially the Index)
* Representing Middle English on the Web with UTF-8
* The Kermit Bibliography (in UTF-8)
* Interchange of Non-English Computer Text (UTF-8 math and box-drawing)
* Unicode Table (in UTF-8)

Unicode samplers offsite:

* Michael Everson's Bibliography of Typography and Scripts
* Sample Unicode Test Pages and Script Links
* I don't know, I only work here
* Anyone can be provincial
* Transcriptions of "Unicode"
* Example Unicode Usage for Business Applications
* UTF-8 and Unicode FAQ for Unix/Linux

Unicode fonts:

* Unicode Fonts for Windows Computers (Alan Wood)
* Unicode Fonts and Tools for X11 (Markus Kuhn)
* Everson Mono (Michael Everson)
* Agfa Monotype

[ Kermit 95 ] [ K95 Screen Shots ] [ C-Kermit ] [ Kermit Home ] [ Display Problems? ] [ The Unicode Consortium ]
UTF-8 Sampler / The Kermit Project / Columbia University / kermit@columbia.edu

[[Category:Categories]]

DLNA Summit 2008

2008-07-01T18:55:58Z

TimBird: /* Venue/Hotel Information */

== Introduction ==

The CE Linux Forum is hosting the second Open Source DLNA Summit, in Ede Netherlands, November 8 2008.

This summit is co-located at the same venue as
[http://www.embeddedlinuxconference.com/elc_europe08/index.html Embedded Linux Conference Europe].
(Note that registration in Embedded Linux Conference is not required for attending the DLNA Summit)

== Purpose ==
The primary purpose of this conference is to facilitate the meeting and sharing of information among several parties interested in open source implementations of the DLNA specifications. These includes open source developers, product developers who might use these implementations, representatives from the DLNA organization or from related companies (certification and testing labs), and from members of the CE Linux Forum who are interested in this work.

This page has information about the summit. It will be updated as more information becomes available.

The CE Linux Forum is interested in promoting and supporting work in this area, for eventual use in Linux-based CE products. It is hoped that by collaborating we can avoid duplication of effort, strengthen interoperability between implementations, and help accelerate the development of robust and feature-full solutions. During this summit we also want to gauge the interest level for holding such events in the future and discuss ideas for making them more productive.

== Overview ==
* Location: Ede, Netherlands
* Date: November 8 (Saturday), 2008
* Times: 10 am to 5 pm
* Venue: tbd
* Price: Free
* Attendees: Attendance is by invitation. If you are interested in attending, please contact Rahul Saxena: rahul dot saxena at intel.com or Tim Bird: tim dot bird at am.sony.com

== Agenda ==
List of presentation and discussion topics:

*Specification Roadmap

*Status of DLNA OSS Projects

*Industry input on DLNA stack feature priorities and problem areas

*CELF sponsorship and support of OSS projects, contract work etc

*Open sourcing of DLNA stacks from CE companies

*Ideas on collaboration: Code sharing, partitioning problem space etc

*Certification Processes and Tools

*Hardware availability: Development and Test hardware

*DLNA Plug Fests

*Share compliance experiences e.g. PS3 war stories

*Future Summit discussion: Need for such a summit, agenda Ideas, mail lists, new invitees etc

Short (up to 30 minutes) presentations on above or similar topics are welcome and encouraged. Though Pre-submission of presentations is not required, please inform Rahul Saxena (rahul dot saxena at intel.com) if you plan to present.

== Attendees ==
List of Attendees (To be updated)

== Venue/Hotel Information ==
This summit is co-located at the same venue as Embedded Linux Conference Europe (ELCE). Please see the following ELCE conference web site for Venue and Hotel information:
* Venue information: http://www.embeddedlinuxconference.com/elc_europe08/venue.html
* Hotel information: http://www.embeddedlinuxconference.com/elc_europe08/hotel.html

== Link to more resources ==
More information about open source DLNA projects is available on the elinux wiki at:

http://elinux.org/DLNA_Open_Source_Projects

Link to 2007 DLNA Summit website:

http://tree.celinuxforum.org/CelfPubWiki/DLNASummit

DLNA Summit 2008

2008-07-01T18:54:58Z

TimBird: /* Agenda */

== Introduction ==

The CE Linux Forum is hosting the second Open Source DLNA Summit, in Ede Netherlands, November 8 2008.

This summit is co-located at the same venue as
[http://www.embeddedlinuxconference.com/elc_europe08/index.html Embedded Linux Conference Europe].
(Note that registration in Embedded Linux Conference is not required for attending the DLNA Summit)

== Purpose ==
The primary purpose of this conference is to facilitate the meeting and sharing of information among several parties interested in open source implementations of the DLNA specifications. These includes open source developers, product developers who might use these implementations, representatives from the DLNA organization or from related companies (certification and testing labs), and from members of the CE Linux Forum who are interested in this work.

This page has information about the summit. It will be updated as more information becomes available.

The CE Linux Forum is interested in promoting and supporting work in this area, for eventual use in Linux-based CE products. It is hoped that by collaborating we can avoid duplication of effort, strengthen interoperability between implementations, and help accelerate the development of robust and feature-full solutions. During this summit we also want to gauge the interest level for holding such events in the future and discuss ideas for making them more productive.

== Overview ==
* Location: Ede, Netherlands
* Date: November 8 (Saturday), 2008
* Times: 10 am to 5 pm
* Venue: tbd
* Price: Free
* Attendees: Attendance is by invitation. If you are interested in attending, please contact Rahul Saxena: rahul dot saxena at intel.com or Tim Bird: tim dot bird at am.sony.com

== Agenda ==
List of presentation and discussion topics:

*Specification Roadmap

*Status of DLNA OSS Projects

*Industry input on DLNA stack feature priorities and problem areas

*CELF sponsorship and support of OSS projects, contract work etc

*Open sourcing of DLNA stacks from CE companies

*Ideas on collaboration: Code sharing, partitioning problem space etc

*Certification Processes and Tools

*Hardware availability: Development and Test hardware

*DLNA Plug Fests

*Share compliance experiences e.g. PS3 war stories

*Future Summit discussion: Need for such a summit, agenda Ideas, mail lists, new invitees etc

Short (up to 30 minutes) presentations on above or similar topics are welcome and encouraged. Though Pre-submission of presentations is not required, please inform Rahul Saxena (rahul dot saxena at intel.com) if you plan to present.

== Attendees ==
List of Attendees (To be updated)

== Venue/Hotel Information ==
This summit is co-located at the same venue as Embedded Linux Conference Europe (ELCE). Please see the following ELCE conference web sites for Venu and Hotel information

== Link to more resources ==
More information about open source DLNA projects is available on the elinux wiki at:

http://elinux.org/DLNA_Open_Source_Projects

Link to 2007 DLNA Summit website:

http://tree.celinuxforum.org/CelfPubWiki/DLNASummit

DLNA Summit 2008

2008-07-01T18:54:30Z

TimBird: /* Overview */ fix formatting

== Introduction ==

The CE Linux Forum is hosting the second Open Source DLNA Summit, in Ede Netherlands, November 8 2008.

This summit is co-located at the same venue as
[http://www.embeddedlinuxconference.com/elc_europe08/index.html Embedded Linux Conference Europe].
(Note that registration in Embedded Linux Conference is not required for attending the DLNA Summit)

== Purpose ==
The primary purpose of this conference is to facilitate the meeting and sharing of information among several parties interested in open source implementations of the DLNA specifications. These includes open source developers, product developers who might use these implementations, representatives from the DLNA organization or from related companies (certification and testing labs), and from members of the CE Linux Forum who are interested in this work.

This page has information about the summit. It will be updated as more information becomes available.

The CE Linux Forum is interested in promoting and supporting work in this area, for eventual use in Linux-based CE products. It is hoped that by collaborating we can avoid duplication of effort, strengthen interoperability between implementations, and help accelerate the development of robust and feature-full solutions. During this summit we also want to gauge the interest level for holding such events in the future and discuss ideas for making them more productive.

== Overview ==
* Location: Ede, Netherlands
* Date: November 8 (Saturday), 2008
* Times: 10 am to 5 pm
* Venue: tbd
* Price: Free
* Attendees: Attendance is by invitation. If you are interested in attending, please contact Rahul Saxena: rahul dot saxena at intel.com or Tim Bird: tim dot bird at am.sony.com

== Agenda ==
List of presentation and discussion topics:

*Specification Roadmap

*Status of DLNA OSS Projects

*Industry input on DLNA stack feature priorities and problem areas

*CELF sponsorship and support of OSS projects, contract work etc

*Open sourcing of DLNA stacks from CE companies

*Ideas on collaboration: Code sharing, partitioning problem space etc

*Certification Processes and Tools

*Hardware availability: Development and Test hardware

*DLNA Plug Fests

*Share compliance experiences e.g. PS3 war stories

*Future Summit discussion: Need for such a summit, agenda Ideas, mail lists, new invitees etc

Short (Upto 30 minutes) presentations on above or similar topics are welcome and encouraged. Though Pre-submission of presentations is not required, please inform Rahul Saxena (rahul dot saxena at intel.com) if you plan to present.

== Attendees ==
List of Attendees (To be updated)

== Venue/Hotel Information ==
This summit is co-located at the same venue as Embedded Linux Conference Europe (ELCE). Please see the following ELCE conference web sites for Venu and Hotel information

== Link to more resources ==
More information about open source DLNA projects is available on the elinux wiki at:

http://elinux.org/DLNA_Open_Source_Projects

Link to 2007 DLNA Summit website:

http://tree.celinuxforum.org/CelfPubWiki/DLNASummit

DLNA Summit 2008

2008-07-01T18:53:34Z

TimBird: add link to ELCE 2008 web site

== Introduction ==

The CE Linux Forum is hosting the second Open Source DLNA Summit, in Ede Netherlands, November 8 2008.

This summit is co-located at the same venue as
[http://www.embeddedlinuxconference.com/elc_europe08/index.html Embedded Linux Conference Europe].
(Note that registration in Embedded Linux Conference is not required for attending the DLNA Summit)

== Purpose ==
The primary purpose of this conference is to facilitate the meeting and sharing of information among several parties interested in open source implementations of the DLNA specifications. These includes open source developers, product developers who might use these implementations, representatives from the DLNA organization or from related companies (certification and testing labs), and from members of the CE Linux Forum who are interested in this work.

This page has information about the summit. It will be updated as more information becomes available.

The CE Linux Forum is interested in promoting and supporting work in this area, for eventual use in Linux-based CE products. It is hoped that by collaborating we can avoid duplication of effort, strengthen interoperability between implementations, and help accelerate the development of robust and feature-full solutions. During this summit we also want to gauge the interest level for holding such events in the future and discuss ideas for making them more productive.

== Overview ==

Location: Ede, Netherlands
Date: November 8 (Saturday), 2008
Times: 10 am to 5 pm
Venue: tbd
Price: Free
Attendees: Attendance is by invitation. If you are interested in attending, please contact Rahul Saxena: rahul dot saxena atintel.com or Tim Bird: tim dot bird at am.sony.com

== Agenda ==
List of presentation and discussion topics:

*Specification Roadmap

*Status of DLNA OSS Projects

*Industry input on DLNA stack feature priorities and problem areas

*CELF sponsorship and support of OSS projects, contract work etc

*Open sourcing of DLNA stacks from CE companies

*Ideas on collaboration: Code sharing, partitioning problem space etc

*Certification Processes and Tools

*Hardware availability: Development and Test hardware

*DLNA Plug Fests

*Share compliance experiences e.g. PS3 war stories

*Future Summit discussion: Need for such a summit, agenda Ideas, mail lists, new invitees etc

Short (Upto 30 minutes) presentations on above or similar topics are welcome and encouraged. Though Pre-submission of presentations is not required, please inform Rahul Saxena (rahul dot saxena at intel.com) if you plan to present.

== Attendees ==
List of Attendees (To be updated)

== Venue/Hotel Information ==
This summit is co-located at the same venue as Embedded Linux Conference Europe (ELCE). Please see the following ELCE conference web sites for Venu and Hotel information

== Link to more resources ==
More information about open source DLNA projects is available on the elinux wiki at:

http://elinux.org/DLNA_Open_Source_Projects

Link to 2007 DLNA Summit website:

http://tree.celinuxforum.org/CelfPubWiki/DLNASummit

ELC 2006 Presentations

2008-06-27T19:05:34Z

TimBird: /* Table */ fix table layout

Presenters, Demo-ers, Panelists and Participants:
Thanks very much for your participation in CELF's Embedded Linux Conference
I really enjoyed the conference, and hope you did as well.

'''Presenters:''' Please post your technical conference presentations on this page.

(See Instructions below the table)

Here is an article on LinuxDevices with images of the demo posters: http://www.linuxdevices.com/articles/AT8247255296.html

== Table ==
{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
| align="center" | '''Person'''
| align="center" | '''Session Description'''
| align="center" | '''Presentation'''
|-
| Tim Bird (Sony)
| Keynote: 13 Years of Linux
| [[Media:13-years-of-Linux.pdf]]
|-
| Andre Kruetzfeldt, Christophe Guinet
| The MPPWG Mobile Phone Telephony API – part 2 Introduction to the Mobile Phone API
| [[Media:ELC-Aplix-NEC.pdf]]
|-
| Armin Gerritsen
| The Video Clip Player – Philips Nexperia™ PNX0106 and Linux based platform
| [[Media:CELF-ELC_VideoClipPlayer.pdf]]
|-
| Chang-Sik Cho
| Digital Entertainment Center Solution
| [[Media:ELC-presentation-DEC-0412.pdf]]
|-
| Denis Kropp
| Graphics Subsystem in an Embedded World - Integrating [[DirectFB]] into a UHAPI platform
| [[Media:ELC 2006 -GraphicsSubsystemInAnEmbeddedWorld.pdf]]
|-
| Ed Plowman
| Khronos Media API Update
| [[Media:Khronos-API-CELF-Apr06.pdf]]
|-
| Greg Kroah Hartman
| Tutorial: Write a real, working Linux driver
| [[Media:celf_2006_tutorial.pdf]] [[Media:USB_tutorial_example_code.tar.gz]]
|-
| Greg Ungerer
| uClinux -- Micro-controller Linux
| [[Media:uclinux.pdf]]
|-
| Hyok S. Choi
| Non-Paged Memory Management on Mainline ARM Kernel
| .
|-
| Jared Hulbert
| Tutorial: Creating optimized XIP systems
| [[Media:CELF-XIP_Linux.pdf]]
|-
| John Goodacre
| ARM [[MPCore]] and Power Management
| [[Media:MPCore_and_Linux_Power.pdf,]] [[Media:MPCore_and_Linux_Power.ppt]]
|-
| Jordan Crouse
| Taking the plunge - the marriage of X86 and embedded Linux
| [[Media:jordan_crouse_celf_2006.pdf]]
|-
| Jung-Hyun Yoo
| Linux on a Terrestrial DMB TV Receiver
| .
|-
| Kevin D. Kissell
| Microthreads as Linux [[CPUs]] - SMTC Linux for MIPS MT cores
| [[Media:CELF_SMTC_April_2006_v0.3.pdf]]
|-
| Kittur Ganesh
| Optimization Techniques for maximizing application performance on Multi-core processors.
| [[Media:Ganesh-CELF.pdf,]] [[Media:Ganesh-CELF.ppt]]
|-
| Klaas de Waal
| [[Myth TV]] on Philips Nexperia™ PNX8550 and Linux based platform
| [[Media:MythTVonNexperia-CELF-05.pdf]]
|-
| Liam Girdwood
| Enhancing ALSA audio for portable devices.
| .
|-
| Manas Saksena
| State of Linux Realtime – BOF
| .
|-
| Mark Gross
| Power Management Panel
| .
|-
| Mathew Locke
| CE Linux Forum Open Test Lab
| .
|-
| Mathieu Desnoyers
| Low disturbance embedded system tracing with Linux Trace Toolkit Next Generation.
| [[Media:celf2006-desnoyers.pdf]]
|-
| Matt Mackall
| Kernel Size Issues
| .
|-
| Matthew Klahn
| Visualizing resource usage during initialization of embedded systems
| [[Media:VisualizingResUsageDuringBoot.pdf]]
|-
| Min-Seok Jang
| Research on Linux 2.6 Kernel Features for CE products
| .
|-
| Munehiro Ikeda
| Examining Linux Kernel Size
| [[Media:size_exam_celf_elc2006.pdf]]
|-
| Prof. Nicholas Mc Guire
| Boot-Time Optimization - results of applying currently available solutions
| [[Media:boot_opt.pdf]]
|-
| Rob Landley
| What's new with [[Busy Box]]
| .
|-
| Ruud Derwig
| Audio Video Graphics Version 2.0 Specification
| [[Media:CELF_AVG_Specification_v2_20060411.pdf]] ([[Media:CELF_AVG_Specification_v2_20060411.ppt)]]
|-
| Scott Preece
| The MPPWG Mobile Phone Telephony API – part 1 Developing the API
| [[Media:MppApiSession1.pdf]]
|-
| Shinichi Ochiai
| Experience with realtime performance of the current Linux technologies
| [[Media:ExperienceWithRealtimePerformance.pdf]]
|-
| Steve Johnson
| Trusted Bootloader
| [[Media:Trusted_Boot_Loader.pdf]]
|-
| Takanari Hayama
| Analysis of User Level Device Driver usability in embedded application – Technique to achieve good real-time performance
| [[Media:uldd060411celfelc2006.pdf]]
|-
| Thomas Gleixner
| A Case Study of transitioning a project from RTAI to RT-Preempt
| .
|-
| Todd Poynor
| Topics in Embedded Power Management
| [[Media:pm-celf-summit-2006.pdf]]
|-
| Tohru Nojiri
| Kprobes implementation for Embedded System
| .
|}

== Instructions for Presenters ==

Here are the steps to follow to add your presentation to this page (Please read them BEFORE clicking):
* If you don't have a wiki account, please create one by clicking on [[User Preferences]], fill out the form, and return here.
** (A wiki account is required to attach files or edit this page)
* PDF format is preferred. If you can convert your presentation to PDF, please do so.
* If your presentation has any message which says it is confidential (such as in a footer from a corporate or CELF template), please remove it.
** If you used a CELF template that has "CELF confidential" in the footer, please upload the presentation so we can remove the footer. Or you can remove it yourself by editing the footer on the slide "master" page.
* Please make sure your filename does not have any spaces in it
* Click on the AttachFile link at the bottom of the page
** on the form, enter your presentation file name (or browse to it)
** click on "Add link to page".
** click on "Upload" (your file will be added as an attachment to the page)
** click on "ShowText" to see the page again.

If you want to be extra nice, you can add the appropriate "[[Media:"]] line to your entry in the table. Do this
by clicking on EditText at the bottom of the page and copying the text from the bottom of the page to
your line (where it currently has a ".").

See the entry for Tim Bird (first in the table) for an example of the syntax required. Each table line is
one long line, even though it may wrap in your browser (so remove all line feeds from your line before saving this
page.) Don't worry - if you don't do this or mess something up I will come along later and fix up the table for you.

Thanks

== Attachments ==
Below this line is a list of attachments:

<hr />

* [[Media:13-years-of-Linux.pdf]]
* [[Media:celf2006-desnoyers.pdf]]
* [[Media:MppApiSession1.pdf]]
* [[Media:pm-celf-summit-2006.pdf]]
* [[Media:Ganesh-CELF.pdf]]
* [[Media:Ganesh-CELF.ppt]]
* [[Media:ELC 2006 -GraphicsSubsystemInAnEmbeddedWorld.pdf]]
* [[Media:VisualizingResUsageDuringBoot.pdf]]
* [[Media:CELF_SMTC_April_2006_v0.3.pdf]]
* [[Media:celf_2006_tutorial.pdf]]
* [[Media:USB_tutorial_example_code.tar.gz]]
* [[Media:Trusted_Boot_Loader.pdf]]
* [[Media:ExperienceWithRealtimePerformance.pdf]]
* [[Media:size_exam_celf_elc2006.pdf]]
* [[Media:CELF_AVG_Specification_v2_20060411.pdf]]
* [[Media:CELF_AVG_Specification_v2_20060411.ppt]]
* [[Media:uclinux.pdf]]
* [[Media:MythTVonNexperia-CELF-05.pdf]]
* [[Media:CELF-ELC_VideoClipPlayer.pdf]]
* [[Media:uldd060411celfelc2006.pdf]]
* [[Media:MPCore_and_Linux_Power.pdf]]
* [[Media:MPCore_and_Linux_Power.ppt]]
* [[Media:ELC-Aplix-NEC.pdf]]
* [[Media:ELC-presentation-DEC-0412.pdf]]
* [[Media:Khronos-API-CELF-Apr06.pdf]]
* [[Media:boot_opt.pdf]]

[[Category:Events]]

Events

2008-06-27T18:50:25Z

TimBird: /* Past events */

== Upcoming events ==
* Regional conference in Japan - Tokyo, Japan, July 4, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree21 Japan Technical Jamboree 21]
* Ottawa Linux Symposium 2008 - Ottawa, Canada, July 23-26
** Home page: http://www.linuxsymposium.org/2008/
* Embedded Linux Conference Europe - Ede, The Netherlands, November 6-7, 2008
** Home page - http://www.embeddedlinuxconference.com/elc_europe08/index.html
** Call for Presentations - http://tree.celinuxforum.org/CelfPubWiki/ELCE2008CallForPresentations

== Past events ==
Some information is at: [[Embedded linux events]]

Here is a list of past CELF events:
* Regional conference in Japan - Tokyo, Japan, April 25, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree20 Japan Technical Jamboree 20]
* [http://www.embeddedlinuxconference.com/elc2008/index.html Embedded Linux Conference, 2008] - Mountain View, California, USA, April 15-17, 2008
** [http://www.celinux.org/elc08_presentations/ ELC 2008 Presentations]
* Regional conference in Japan - Tokyo, Japan, February 21, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree19 Japan Technical Jamboree 19]
* Regional conference in Korea - Seoul, Japan, February 22, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree2 Korean Technical Jamboree 2]
* Regional conference in Japan - Tokyo, Japan, December 21, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree18 Japan Technical Jamboree 18]
*[http://www.celinux.org/elc2008/index.html Embedded Linux Conference - 2008] - Mountain View, California, USA, April 15-17, 2008
*[http://www.celinux.org/elc_europe07/elc_europe_index.html Embedded Linux Conference - Europe 2007] - Linz, Austria, November 2-4, 2007
** Presentations are being collected at: [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations ELC Europe 2007 Presentations]
* Regional conference in Japan - Tokyo, Japan, October 25, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree17 Japan Technical Jamboree 17]
*Regional conference in Japan - Tokyo, Japan, August 31, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree16 Japan Technical Jamboree 16]
*Ottawa Linux Symposium 2007 - Ottawa, Canada, June 27-30, 2007
** [[Ottawa Linux Symposium 2007]]
** [[OLS 2007 Embedded Linux BOF]] - June 27
** [[OLS 2007 Embedded Linux Wiki BOF]] - June 27
** [[OLS 2007 CELF BOF]] - June 29, 7-9pm, Westin Hotel
*Regional conference in Japan - Tokyo, Japan, June 29, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree15 Japan Technical Jamboree 15]
*Embedded System Expo & Conference in Japan - Tokyo, Japan, May 16-18
*Regional conference in Japan - Tokyo, Japan, April 27, 2007 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree14 Japan Technical Jamboree 14]
* Embedded Linux Conference, 2007 - San Jose, California, April 17-19, 2007 [http://www.celinux.org/elc2007/index.html ELC 2007]
** Presentations are available at http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations
*Regional conference in Japan - Tokyo, Japan, February 22, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree13 Japan Technical Jamboree 13]
*Regional conference in Japan - Tokyo, Japan, December 8, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree12 Japan Technical Jamboree 12]
*Embedded Technology 2006 - Yokohama, Japan, November 15..17,
*Regional conference in Japan - Tokyo, Japan, October 27, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree11 Japan Technical Jamboree 11]
*Regional conference in Japan - Tokyo, Japan, August 25, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree10 Japan Technical Jamboree 10]
*GNOME Embedded and Mobile (GMAE) forum first meetting at Guadec 2006 in Villanova, Spain. Have a look at the report: {{pdf|Gmae-report-for-celf-2006-08-10.pdf|GMAE Report}}
*Ottawa Linux Symposium 2006 - Ottawa, Canada, July 19-22, 2006
** We had a great time in Ottawa! See the following pages for more information:
** [[Ottawa Linux Symposium 2006]]
** [http://tree.celinuxforum.org/CelfPubWiki/OLS2006Demos OLS 2006 CELF Demos]
*Regional conference in Japan - Tokyo, Japan, July 13, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree9 Japan Technical Jamboree 9]
*Regional conference in Japan - Tokyo, Japan, May 26, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree8 Japan Technical Jamboree 8]
*CELF Embedded Linux Conference - San Jose, California, April 11-12, 2006 - [http://www.celinux.org/elc2006/index.html elc2006]
**Presentations from the conference are being collected at: [[ELC 2006 Presentations]]
*Regional conference in Japan - Tokyo, Japan, March 24, 2006 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree7 Japan Technical Jamboree 7]
*Regional conference in Japan - Tokyo, Japan, January 20, 2006 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree6 Japan Technical Jamboree 6]
*Regional conference in Japan - Tokyo, Japan, November 25, 2005 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree5 Japan Technical Jamboree 5]
*Regional conference in Japan - Tokyo, Japan, September 30, 2005 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree4 Japan Technical Jamboree 4]
*Ottawa Linux Symposium - Ottawa, Canada, July 20-23 - [http://www.linuxsymposium.org/ OLS]
**CELF was a sponsor again this year for the Ottawa Linux Symposium. We were permitted to show some demos at the event. CELF held a Birds-of-a-Feather (BOF) session on embedded Linux. Also, CELF handed out some prizes at the final address.
*Regional conference in Japan - Tokyo, Japan, July 15, 2005 [[Japan Technical Jamboree 3]]
*International technical conference - Yokohama, Japan, June 2005 [[International Technical Jamboree]]
*Regional conference in Korea - Seoul, Korea, May 14, 2005 - [[CELF Korea Tech Conference]]
*Linux Conf Australia - Canberra, Australia, April 18, 2005
**A few individuals attended, and Tim put up a poster of bootup-time results
*CELF Worldwide Technical Conference - San Jose, January 25, 26, 2005
**Conference program: [http://tree.celinuxforum.org/CelfPubWiki/TechnicalConference2005 CELF Technical Conference 2005]
**Presentations from various sessions: [http://tree.celinuxforum.org/CelfPubWiki/TechConference2005Docs Tech Conference 2005 Docs]
*Regional conference in Japan - December, 2004 - [[Japan Technical Jamboree 2]]
*Regional conference in Japan - October, 2004 - [[Japan Technical Jamboree]]
*Ottawa Linux Symposium, July 2004 - Tim gave a talk, and CELF held a BOF and gave out prizes
**see [http://www.linuxsymposium.org/proceedings/reprints/Reprint-Bird-OLS2004.pdf OLS2004]

== Links to Papers from other events ==
*Fosdem 2005 embedded kernel papers - [http://www.embedded-kernel-track.org/2005/papers.html FOSDEM]
*Ottawa Linux Symposium proceedings - [http://www.linuxsymposium.org/proceedings.php OLS]
** OLS 2007 - broken out paper links - https://ols2006.108.redhat.com/2007/Reprints/
*OLS proceedings collected on kernel.org - http://kernel.org/doc/ols/
[[Category:Events]]

Events

2008-06-27T18:49:58Z

TimBird: /* Past events */

== Upcoming events ==
* Regional conference in Japan - Tokyo, Japan, July 4, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree21 Japan Technical Jamboree 21]
* Ottawa Linux Symposium 2008 - Ottawa, Canada, July 23-26
** Home page: http://www.linuxsymposium.org/2008/
* Embedded Linux Conference Europe - Ede, The Netherlands, November 6-7, 2008
** Home page - http://www.embeddedlinuxconference.com/elc_europe08/index.html
** Call for Presentations - http://tree.celinuxforum.org/CelfPubWiki/ELCE2008CallForPresentations

== Past events ==
Some information is at: [[Embedded linux events]]

Here is a list of past CELF events:
* Regional conference in Japan - Tokyo, Japan, April 25, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree20 Japan Technical Jamboree 20]
* [[http://www.embeddedlinuxconference.com/elc2008/index.html Embedded Linux Conference, 2008]] - Mountain View, California, USA, April 15-17, 2008
** [http://www.celinux.org/elc08_presentations/ ELC 2008 Presentations]
* Regional conference in Japan - Tokyo, Japan, February 21, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree19 Japan Technical Jamboree 19]
* Regional conference in Korea - Seoul, Japan, February 22, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree2 Korean Technical Jamboree 2]
* Regional conference in Japan - Tokyo, Japan, December 21, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree18 Japan Technical Jamboree 18]
*[http://www.celinux.org/elc2008/index.html Embedded Linux Conference - 2008] - Mountain View, California, USA, April 15-17, 2008
*[http://www.celinux.org/elc_europe07/elc_europe_index.html Embedded Linux Conference - Europe 2007] - Linz, Austria, November 2-4, 2007
** Presentations are being collected at: [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations ELC Europe 2007 Presentations]
* Regional conference in Japan - Tokyo, Japan, October 25, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree17 Japan Technical Jamboree 17]
*Regional conference in Japan - Tokyo, Japan, August 31, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree16 Japan Technical Jamboree 16]
*Ottawa Linux Symposium 2007 - Ottawa, Canada, June 27-30, 2007
** [[Ottawa Linux Symposium 2007]]
** [[OLS 2007 Embedded Linux BOF]] - June 27
** [[OLS 2007 Embedded Linux Wiki BOF]] - June 27
** [[OLS 2007 CELF BOF]] - June 29, 7-9pm, Westin Hotel
*Regional conference in Japan - Tokyo, Japan, June 29, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree15 Japan Technical Jamboree 15]
*Embedded System Expo & Conference in Japan - Tokyo, Japan, May 16-18
*Regional conference in Japan - Tokyo, Japan, April 27, 2007 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree14 Japan Technical Jamboree 14]
* Embedded Linux Conference, 2007 - San Jose, California, April 17-19, 2007 [http://www.celinux.org/elc2007/index.html ELC 2007]
** Presentations are available at http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations
*Regional conference in Japan - Tokyo, Japan, February 22, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree13 Japan Technical Jamboree 13]
*Regional conference in Japan - Tokyo, Japan, December 8, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree12 Japan Technical Jamboree 12]
*Embedded Technology 2006 - Yokohama, Japan, November 15..17,
*Regional conference in Japan - Tokyo, Japan, October 27, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree11 Japan Technical Jamboree 11]
*Regional conference in Japan - Tokyo, Japan, August 25, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree10 Japan Technical Jamboree 10]
*GNOME Embedded and Mobile (GMAE) forum first meetting at Guadec 2006 in Villanova, Spain. Have a look at the report: {{pdf|Gmae-report-for-celf-2006-08-10.pdf|GMAE Report}}
*Ottawa Linux Symposium 2006 - Ottawa, Canada, July 19-22, 2006
** We had a great time in Ottawa! See the following pages for more information:
** [[Ottawa Linux Symposium 2006]]
** [http://tree.celinuxforum.org/CelfPubWiki/OLS2006Demos OLS 2006 CELF Demos]
*Regional conference in Japan - Tokyo, Japan, July 13, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree9 Japan Technical Jamboree 9]
*Regional conference in Japan - Tokyo, Japan, May 26, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree8 Japan Technical Jamboree 8]
*CELF Embedded Linux Conference - San Jose, California, April 11-12, 2006 - [http://www.celinux.org/elc2006/index.html elc2006]
**Presentations from the conference are being collected at: [[ELC 2006 Presentations]]
*Regional conference in Japan - Tokyo, Japan, March 24, 2006 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree7 Japan Technical Jamboree 7]
*Regional conference in Japan - Tokyo, Japan, January 20, 2006 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree6 Japan Technical Jamboree 6]
*Regional conference in Japan - Tokyo, Japan, November 25, 2005 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree5 Japan Technical Jamboree 5]
*Regional conference in Japan - Tokyo, Japan, September 30, 2005 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree4 Japan Technical Jamboree 4]
*Ottawa Linux Symposium - Ottawa, Canada, July 20-23 - [http://www.linuxsymposium.org/ OLS]
**CELF was a sponsor again this year for the Ottawa Linux Symposium. We were permitted to show some demos at the event. CELF held a Birds-of-a-Feather (BOF) session on embedded Linux. Also, CELF handed out some prizes at the final address.
*Regional conference in Japan - Tokyo, Japan, July 15, 2005 [[Japan Technical Jamboree 3]]
*International technical conference - Yokohama, Japan, June 2005 [[International Technical Jamboree]]
*Regional conference in Korea - Seoul, Korea, May 14, 2005 - [[CELF Korea Tech Conference]]
*Linux Conf Australia - Canberra, Australia, April 18, 2005
**A few individuals attended, and Tim put up a poster of bootup-time results
*CELF Worldwide Technical Conference - San Jose, January 25, 26, 2005
**Conference program: [http://tree.celinuxforum.org/CelfPubWiki/TechnicalConference2005 CELF Technical Conference 2005]
**Presentations from various sessions: [http://tree.celinuxforum.org/CelfPubWiki/TechConference2005Docs Tech Conference 2005 Docs]
*Regional conference in Japan - December, 2004 - [[Japan Technical Jamboree 2]]
*Regional conference in Japan - October, 2004 - [[Japan Technical Jamboree]]
*Ottawa Linux Symposium, July 2004 - Tim gave a talk, and CELF held a BOF and gave out prizes
**see [http://www.linuxsymposium.org/proceedings/reprints/Reprint-Bird-OLS2004.pdf OLS2004]

== Links to Papers from other events ==
*Fosdem 2005 embedded kernel papers - [http://www.embedded-kernel-track.org/2005/papers.html FOSDEM]
*Ottawa Linux Symposium proceedings - [http://www.linuxsymposium.org/proceedings.php OLS]
** OLS 2007 - broken out paper links - https://ols2006.108.redhat.com/2007/Reprints/
*OLS proceedings collected on kernel.org - http://kernel.org/doc/ols/
[[Category:Events]]

Events

2008-06-27T18:46:52Z

TimBird: /* Past events */ fix elc 2008 link

== Upcoming events ==
* Regional conference in Japan - Tokyo, Japan, July 4, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree21 Japan Technical Jamboree 21]
* Ottawa Linux Symposium 2008 - Ottawa, Canada, July 23-26
** Home page: http://www.linuxsymposium.org/2008/
* Embedded Linux Conference Europe - Ede, The Netherlands, November 6-7, 2008
** Home page - http://www.embeddedlinuxconference.com/elc_europe08/index.html
** Call for Presentations - http://tree.celinuxforum.org/CelfPubWiki/ELCE2008CallForPresentations

== Past events ==
Some information is at: [[Embedded linux events]]

Here is a list of past CELF events:
* Regional conference in Japan - Tokyo, Japan, April 25, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree20 Japan Technical Jamboree 20]
* Embedded Linux Conference, 2008 - Mountain View, California, USA, April 15-17, 2008
** Home page: http://www.embeddedlinuxconference.com/elc2008/index.html
** [http://tree.celinuxforum.org/CelfPubWiki/ELC2008CallForPresentations Call for sessions]
* Regional conference in Japan - Tokyo, Japan, February 21, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree19 Japan Technical Jamboree 19]
* Regional conference in Korea - Seoul, Japan, February 22, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree2 Korean Technical Jamboree 2]
* Regional conference in Japan - Tokyo, Japan, December 21, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree18 Japan Technical Jamboree 18]
*[http://www.celinux.org/elc2008/index.html Embedded Linux Conference - 2008] - Mountain View, California, USA, April 15-17, 2008
*[http://www.celinux.org/elc_europe07/elc_europe_index.html Embedded Linux Conference - Europe 2007] - Linz, Austria, November 2-4, 2007
** Presentations are being collected at: [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations ELC Europe 2007 Presentations]
* Regional conference in Japan - Tokyo, Japan, October 25, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree17 Japan Technical Jamboree 17]
*Regional conference in Japan - Tokyo, Japan, August 31, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree16 Japan Technical Jamboree 16]
*Ottawa Linux Symposium 2007 - Ottawa, Canada, June 27-30, 2007
** [[Ottawa Linux Symposium 2007]]
** [[OLS 2007 Embedded Linux BOF]] - June 27
** [[OLS 2007 Embedded Linux Wiki BOF]] - June 27
** [[OLS 2007 CELF BOF]] - June 29, 7-9pm, Westin Hotel
*Regional conference in Japan - Tokyo, Japan, June 29, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree15 Japan Technical Jamboree 15]
*Embedded System Expo & Conference in Japan - Tokyo, Japan, May 16-18
*Regional conference in Japan - Tokyo, Japan, April 27, 2007 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree14 Japan Technical Jamboree 14]
* Embedded Linux Conference, 2007 - San Jose, California, April 17-19, 2007 [http://www.celinux.org/elc2007/index.html ELC 2007]
** Presentations are available at http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations
*Regional conference in Japan - Tokyo, Japan, February 22, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree13 Japan Technical Jamboree 13]
*Regional conference in Japan - Tokyo, Japan, December 8, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree12 Japan Technical Jamboree 12]
*Embedded Technology 2006 - Yokohama, Japan, November 15..17,
*Regional conference in Japan - Tokyo, Japan, October 27, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree11 Japan Technical Jamboree 11]
*Regional conference in Japan - Tokyo, Japan, August 25, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree10 Japan Technical Jamboree 10]
*GNOME Embedded and Mobile (GMAE) forum first meetting at Guadec 2006 in Villanova, Spain. Have a look at the report: {{pdf|Gmae-report-for-celf-2006-08-10.pdf|GMAE Report}}
*Ottawa Linux Symposium 2006 - Ottawa, Canada, July 19-22, 2006
** We had a great time in Ottawa! See the following pages for more information:
** [[Ottawa Linux Symposium 2006]]
** [http://tree.celinuxforum.org/CelfPubWiki/OLS2006Demos OLS 2006 CELF Demos]
*Regional conference in Japan - Tokyo, Japan, July 13, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree9 Japan Technical Jamboree 9]
*Regional conference in Japan - Tokyo, Japan, May 26, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree8 Japan Technical Jamboree 8]
*CELF Embedded Linux Conference - San Jose, California, April 11-12, 2006 - [http://www.celinux.org/elc2006/index.html elc2006]
**Presentations from the conference are being collected at: [[ELC 2006 Presentations]]
*Regional conference in Japan - Tokyo, Japan, March 24, 2006 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree7 Japan Technical Jamboree 7]
*Regional conference in Japan - Tokyo, Japan, January 20, 2006 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree6 Japan Technical Jamboree 6]
*Regional conference in Japan - Tokyo, Japan, November 25, 2005 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree5 Japan Technical Jamboree 5]
*Regional conference in Japan - Tokyo, Japan, September 30, 2005 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree4 Japan Technical Jamboree 4]
*Ottawa Linux Symposium - Ottawa, Canada, July 20-23 - [http://www.linuxsymposium.org/ OLS]
**CELF was a sponsor again this year for the Ottawa Linux Symposium. We were permitted to show some demos at the event. CELF held a Birds-of-a-Feather (BOF) session on embedded Linux. Also, CELF handed out some prizes at the final address.
*Regional conference in Japan - Tokyo, Japan, July 15, 2005 [[Japan Technical Jamboree 3]]
*International technical conference - Yokohama, Japan, June 2005 [[International Technical Jamboree]]
*Regional conference in Korea - Seoul, Korea, May 14, 2005 - [[CELF Korea Tech Conference]]
*Linux Conf Australia - Canberra, Australia, April 18, 2005
**A few individuals attended, and Tim put up a poster of bootup-time results
*CELF Worldwide Technical Conference - San Jose, January 25, 26, 2005
**Conference program: [http://tree.celinuxforum.org/CelfPubWiki/TechnicalConference2005 CELF Technical Conference 2005]
**Presentations from various sessions: [http://tree.celinuxforum.org/CelfPubWiki/TechConference2005Docs Tech Conference 2005 Docs]
*Regional conference in Japan - December, 2004 - [[Japan Technical Jamboree 2]]
*Regional conference in Japan - October, 2004 - [[Japan Technical Jamboree]]
*Ottawa Linux Symposium, July 2004 - Tim gave a talk, and CELF held a BOF and gave out prizes
**see [http://www.linuxsymposium.org/proceedings/reprints/Reprint-Bird-OLS2004.pdf OLS2004]

== Links to Papers from other events ==
*Fosdem 2005 embedded kernel papers - [http://www.embedded-kernel-track.org/2005/papers.html FOSDEM]
*Ottawa Linux Symposium proceedings - [http://www.linuxsymposium.org/proceedings.php OLS]
** OLS 2007 - broken out paper links - https://ols2006.108.redhat.com/2007/Reprints/
*OLS proceedings collected on kernel.org - http://kernel.org/doc/ols/
[[Category:Events]]

Test Systems

2008-06-25T21:19:52Z

TimBird:

Here is a quick list of different test systems (and test projects) for Linux:

== Test Projects ==
Clearly, a number of open source projects in this realm exist. This page intends to collect descriptions and links to these projects

=== Test Automation Tools ===

* [http://test.kernel.org/autotest Autotest]
* [https://testing.108.redhat.com/ Red Hat Test Project]

=== Test Suites ===

* [http://ltp.sourceforge.net/ Linux Test Project]

=== Static Analysis ===

* [http://tree.celinuxforum.org/CelfPubWiki/Sparse Sparse]
* [http://smatch.sourceforge.net/ Smatch]

== Automated kernel compilation results ==
Here are some locations where automated tests of kernel compilation can be viewed:
=== L4X ===

* http://l4x.org/k/ - Jan Dittmer's page showing the build status and kernel size of the defconfigs of many architectures. Running since 2004 or 2005

=== Kautobuild ===
Kautobuild is Simtec's automated system to build and store results for ARM and MIPS platforms, for every kernel version. It uses defconfigs for multiple boards, and reports compile errors/warnings, module size, kernel size etc.
* Kautobuild for ARM - http://armlinux.simtec.co.uk/kautobuild/
* mail archive version of results is at: http://lists.simtec.co.uk/pipermail/kautobuild/
* Article about the Simtel site is at: http://www.linuxdevices.com/news/NS4646877354.html (2006)

=== ABAT ===
ABAT - https://sourceforge.net/projects/abat/
- does a download/build/boot regression test for several mainline kernel trees, as soon as new versions are available
- test results matrix is available here:
- http://ftp.kernel.org/pub/linux/kernel/people/mbligh/abat/regression_matrix.html

Test Systems

2008-06-25T21:19:27Z

TimBird:

Here is a quick list of different test systems (and test projects) for Linux:

== Test Projects ==
Clearly, a number of open source projects in this realm exist. This page intends to collect descriptions and links to these projects

=== Test Automation Tools ===

* [http://test.kernel.org/autotest Autotest]
* [https://testing.108.redhat.com/ Red Hat Test Project]

=== Test Suites ===

* [http://ltp.sourceforge.net/ Linux Test Project]

=== Static Analysis ===

* [http://tree.celinuxforum.org/CelfPubWiki/Sparse Sparse]
* [http://smatch.sourceforge.net/ Smatch]

== Automated kernel compilation results ==
Here are some locations where automated tests of kernel compilation can be viewed:
=== L4X ===

* http://l4x.org/k/ - Jan Dittmer's page showing the build status and kernel size of the defconfigs of many architectures. Running since 2004 or 2005

=== Kautobuild ==
Kautobuild is Simtec's automated system to build and store results for ARM and MIPS platforms, for every kernel version. It uses defconfigs for multiple boards, and reports compile errors/warnings, module size, kernel size etc.
* Kautobuild for ARM - http://armlinux.simtec.co.uk/kautobuild/
* mail archive version of results is at: http://lists.simtec.co.uk/pipermail/kautobuild/
* Article about the Simtel site is at: http://www.linuxdevices.com/news/NS4646877354.html (2006)

=== ABAT ===
ABAT - https://sourceforge.net/projects/abat/
- does a download/build/boot regression test for several mainline kernel trees, as soon as new versions are available
- test results matrix is available here:
- http://ftp.kernel.org/pub/linux/kernel/people/mbligh/abat/regression_matrix.html

Test Systems

2008-06-25T21:08:44Z

TimBird: add links to automated test sites

Here is a quick list of different test systems (and test projects) for Linux:

This information has also been posted to the OSDL test-tools wiki.

See: http://developer.osdl.org/dev/test_tools/index.php/Test_Projects

There was a testing summit held at [[Linux World]] in San Francisco in August of 2006.
The minutes from the meeting are at:
http://lists.osdl.org/pipermail/test-tools/2006-August/000000.html

As a result of the meeting, a mailing list and wiki were created.
These resources are intended to be used to coordinate the efforts
of the disparate testing projects in Linux. The list info is at:
https://lists.osdl.org/mailman/listinfo/test-tools

The wiki is at:
http://developer.osdl.org/dev/test_tools/index.php/Main_Page

== automated kernel compilation tests ==
Here are some locations where automated tests of kernel compilation can be viewed:
* http://l4x.org/k/ - Jan Dittmer's page showing the build status and kernel size of the defconfigs of many architectures. Running since 2004 or 2005
* http://lists.simtec.co.uk/pipermail/kautobuild/ - Simtec's archive of build results for ARM and MIPS platforms, for every kernel version. It uses defconfigs for multiple boards, and reports compile errors/warnings, module size, kernel size etc.

== old page content ==
This content was moved to the OSDL test-tools wiki at:
http://developer.osdl.org/dev/test_tools/index.php/Test_Projects

It is preserved here only temporarily. (TRB - Aug, 2006)

ABAT - https://sourceforge.net/projects/abat/
- does a download/build/boot regression test for several mainline kernel trees, as soon as new versions are available
- test results matrix is available here:
- http://ftp.kernel.org/pub/linux/kernel/people/mbligh/abat/regression_matrix.html

Linux Test Project
- http://ltp.sourceforge.net/

CELF's Proposed Test Lab
- [[Open Test Lab]]

[[K Auto Build]] - http://armlinux.simtec.co.uk/index.html
- [[KAuto Build]] project for ARM architectures
- Article about the site is at: http://www.linuxdevices.com/news/NS4646877354.html

There was a testing summit held

I wanted to report that there was a testing summit held at
[[Linux World]] in San Francisco a few weeks ago. I represented
the CELF test lab effort at the meeting.

[[Category:Community]]

Toolbox

2008-06-25T20:57:34Z

TimBird:

This page has information about developing Embedded Linux, including links to toolchains, debuggers and other development tools. Also, it has links to pages with debugging tips.

== Development Tools ==
=== Toolchains ===
* see [[Toolchains]]
=== Debuggers ===
* [http://openocd.berlios.de/web/ Open On-Chip Debugger]
* FIXTHIS - need link for debuggers (DDD, gdb, kgdb, etc.)eclipse

=== Integrated Development Environments ===
* FIXTHIS - need link for IDEs (eclipse, etc.)

=== Tracers and Profilers ===
* see [[Kernel Trace Systems]]

=== Benchmarks ===
* see [[Benchmark Programs]]

=== Source Management Tools ===
There are a number of tools for managing patches, which are useful for different tasks.
There's now a whole page devoted to this. See [[Source Management Tools]]

For some simple tools for managing patches, see [[Diff And Patch Tricks]]

=== Test Systems ===
* See [[Test Systems]]

== Developer Resources ==
=== Kernel mailing lists, web sites, etc. ===
* See [[Linux Kernel Resources]]

=== Documentation ===
* Linux Device Drivers, 3rd edition - http://lwn.net/Kernel/LDD3/
* Papers from the Ottawa Linux Symposium - broken out - see http://kernel.org/doc/ols/

==== Books ====
* Embedded Linux System Design and Development - by P. Raghavan, Amol Lad, and Sriram Neelakandan (Hardcover - Dec 21, 2005)
** This one looks quite good.
* Embedded Linux Primer: A Practical Real-World Approach - by Christopher Hallinan
** So does this one.
* Building Embedded Linux Systems - by Karim Yaghmour
** This book is a bit dated (the edition I have is from 2003, but it is still a great resource.

=== Code Style Tips ===
* This section is for good [[Code Styling Tips]]

=== Debugging Tips ===
* See the [[Kernel Debugging Tips]] page
* See also [[Debugging Makefiles]]

=== GCC Tips and Tricks ===
* This section of [[GCC Tips]] is a collection of tips and tricks helpful for embedded developers

== Embedded Linux Distributions ==
* see [[Embedded Linux Distributions]]
[[Category:Development Tools]]

Toolbox

2008-06-25T20:56:56Z

TimBird:

This page has information about developing Embedded Linux, including links to toolchains, debuggers and other development tools. Also, it has links to pages with debugging tips.

== Development Tools ==
=== Toolchains ===
* see [[Toolchains]]
=== Debuggers ===
* [http://openocd.berlios.de/web/ Open On-Chip Debugger]
* FIXTHIS - need link for debuggers (DDD, gdb, kgdb, etc.)eclipse

=== Integrated Development Environments ===
* FIXTHIS - need link for IDEs (eclipse, etc.)

=== Tracers and Profilers ===
* see [[Kernel Trace Systems]]

=== Benchmarks ===
* see [[Benchmark Programs]]

=== Source Management Tools ===
There are a number of tools for managing patches, which are useful for different tasks.
There's now a whole page devoted to this. See [[Source Management Tools]]

=== Test Systems ===
* See [[Test Systems]]

For some simple tools for managing patches, see [[Diff And Patch Tricks]]
== Developer Resources ==
=== Kernel mailing lists, web sites, etc. ===
* See [[Linux Kernel Resources]]

=== Documentation ===
* Linux Device Drivers, 3rd edition - http://lwn.net/Kernel/LDD3/
* Papers from the Ottawa Linux Symposium - broken out - see http://kernel.org/doc/ols/

==== Books ====
* Embedded Linux System Design and Development - by P. Raghavan, Amol Lad, and Sriram Neelakandan (Hardcover - Dec 21, 2005)
** This one looks quite good.
* Embedded Linux Primer: A Practical Real-World Approach - by Christopher Hallinan
** So does this one.
* Building Embedded Linux Systems - by Karim Yaghmour
** This book is a bit dated (the edition I have is from 2003, but it is still a great resource.

=== Code Style Tips ===
* This section is for good [[Code Styling Tips]]

=== Debugging Tips ===
* See the [[Kernel Debugging Tips]] page
* See also [[Debugging Makefiles]]

=== GCC Tips and Tricks ===
* This section of [[GCC Tips]] is a collection of tips and tricks helpful for embedded developers

== Embedded Linux Distributions ==
* see [[Embedded Linux Distributions]]
[[Category:Development Tools]]

Squash Fs

2008-06-25T18:44:45Z

TimBird: /* File System Performance */ fix lnk to comparisons page

== Description ==
"Squash FS" is the name of a compressed read-only filesystem for Linux. There are a number of such file systems available for Linux, including ROMFS, CRAMFS and SquashFS.

== Rationale ==
A compressed file system is interesting in embedded systems for reducing the overall size (in flash) of the Linux system. Squash FS is reported to have better compression capabilities than CRAMFS, which is a very popular

== Resources ==
=== Projects ===
The Squash fs home page is at: [http://squashfs.sourceforge.net/ Squash FS]

=== Specifications ===
There are no specifications on this technology.

== Downloads ==
=== Patch ===
*see the Squash fs [http://sourceforge.net/project/showfiles.php?group_id=63835 download page] for latest patches

=== Utility programs ===
The squashfs file release contains a README, the squashfs patch files, and the squashfs-tools directory (mksquashfs). Please see the INSTALL file for install instructions.

== How To Use ==
See the Squash FS Howto:
*[http://artemio.net/projects/linuxdoc/squashfs online version]
*[[Squash FS Howto]] page (copy of document in this wiki - may be out of date)

== Sample Results ==

Here are brief summaries for 2 large file systems, saved using a variety of file system types.

This information was provided by Phillip Lougher.

=== Ubuntu liveCD compression results ===

<pre>
ext3 uncompressed size 1.4 GB
ISO9660 uncompressed size 1.3 GB
Zisofs compressed size 589.81 MB
Cloop compressed size 471.89 MB
Squashfs2.0 compressed size 448.58 MB
Squashfs2.1 compressed size 448.58 MB
</pre>

=== Damn Small Linux liveCD compression results ===

<pre>
ext3 uncompressed size 126 MB
CRAMFS compressed size 52.19 MB
Squashfs2.0 compressed size 46.52 MB
Squashfs2.1 compressed size 46.52 MB
</pre>

=== File System Performance ===
There is performance data for these file systems on the page [[Squash Fs Comparisons]]

=== lzma data comparison ===
Here is some information that was posted recently on the squashfsmailing list by Oleg Vdovikin:

<pre>
> # du -s target
> 7836 target
> # ls -l target.*
> -rw-r--r-- 1 root root 2842788 Aug 27 17:54 target.cramfs
> -rwx------ 1 root root 2449408 Jan 26 13:19 target.sqshfs
> -rwx------ 1 root root 2060288 Jan 26 13:21 target.lzmafs
>
> So, lzma for this filesystem gives 84% of original size. For bigger
> filesystem I've got 82%.
</pre>

= Future Work/Action Items =
Here is a list of things that could be worked on for this feature:
*there was a report in August, 2004 of problems with squashfs on PPC. see [http://sourceforge.net/forum/message.php?msg_id=2735613 here] (at bottom of page)
*there was a suggestion to use LZMA compression for version 3.0 of squashfs - see [http://sourceforge.net/forum/forum.php?thread_id=1113639&forum_id=215699 here]

== Notes on compression ==
<pre>
From: John Richard Moser <nigele...@comcast.net>
Date: Wed, 29 Sep 2004 18:20:11 +0200
Subject: Re: Compressed filesystems: Better compression?

Matti Aarnio wrote:
| Compression algorithms are a bit tough to be used in a random access
| smallish blocks environments. In long streams where you can use megabytes
| worth of buffer spaces there is no problem is achieving good performance.
| But do try to do that in an environment where your maximum block size
| is, say: 4 kB, and you have to start afresh at every block boundary.

Yes of course. I've seen the compressed page cache patch do this and
get fair peformance (10-20%), though on double size blocks (8KiB) it
manages almost twice as good (20-50%, averaged around 30% IIRC). Not
great, but not bad.

On compressed filesystems you can work with 64k or 128k blocks.
Somewhere around 32-64k is usually optimal; you're not going to see
great improvements using 1M blocks instead of 512k blocks.

| Whatever algorithms you use, there will always be data sequences that
| are of maximum entropy, and won't compress. Rather they will be
| presented in streams as is with a few bytes long wrappers around
| them.

Yes, an intelligent algorithm decides that if the underlying compression
algorithm used produces no results, it just marks the block as
uncompressed and stores it as such. ZLIB does this if the block gets
bigger. LZMA might not; but higher level intrinsics (block headers)
could handle that easy (as you said).
</pre>

[[Category:File Systems]]

Boot Time

2008-06-17T19:40:05Z

TimBird: /* Measuring Boot-up Time */

Boot Time includes topics such as Boot Time measurement, Boot Time reduction, and Boot Time analysis. Boot Time directly impacts the first perception an end user has of a consumer electronic product. Regardless of how attractive or well designed a consumer electronic device is, the time required to move the device from off to an interactive, usable state is critical to obtaining a positive end user experience. Turning on a device is Use Case #1.

== Technology/Project Pages ==
The following are individual pages with information about various technologies relevant to improving Boot Time for Linux. Some of these describe local patches available on this site. Others point to projects or patches maintained elsewhere.

=== Measuring Boot-up Time ===
*[[Printk Times]] - simple system for showing timing information for each printk.
*[[Kernel Function Trace]] - system for reporting function timings in the kernel.
*[[Linux Trace Toolkit]] - system for reporting timing data for certain kernel and process events.
*[http://oprofile.sourceforge.net/news/ Oprofile] - system-wide profiler for Linux.
*[[Bootchart]] - a tool for performance analysis and visualization of the Linux boot process. Resource utilization and process information are collected during the user-space portion of the boot process and are later rendered in a PNG, SVG or EPS encoded chart.
*[http://people.redhat.com/berrange/systemtap/bootprobe/ Bootprobe] - a set of [[System Tap]] scripts for analyzing system bootup.
* and, let us not forget: "cat /proc/uptime"

[ FIXTHIS - should mention (and publish) sstream here ]

[ FIXTHIS - should also mention initcall_debug (kernel command line option) here - it shows driver init times for many drivers]

=== Technologies and Techniques for Reducing Boot Time ===
==== Bootloader speedups ====
*[[Kernel XIP]] - Allow kernel to be executed in-place in ROM or FLASH.
*[[DMA Copy Of Kernel On Startup]] - Copy kernel from Flash to RAM using DMA

==== Kernel speedups ====
*[[Disable Console]] - Avoid overhead of console output during system startup.
*[[RTC No Sync]] - Avoid delay to synchronize system time with RTC clock edge on startup.
*[[Short IDE Delays]] - Reduce duration of IDE startup delays (this is effective but possibly dangerous).
*[[Hardcode kernel module info]] - Reduce the overhead of loading a module, by hardcoding some information used for loading the relocation information
*[[IDE No Probe]] - Force kernel to observe the ide<x>=noprobe option.
*[[Preset LPJ]] - Allow the use of a preset loops_per_jiffy value.
*[[Threaded Device Probing]] - Allow drivers to probe devices in parallel.

==== User-space and application speedups ====
* [[Optimize RC Scripts]] - Reduce overhead of running RC scripts
* [[Parallel RC Scripts]] - Run RC scripts in parallel instead of sequentially
* [[Application XIP]] - Allow programs and libraries to be executed in-place in ROM or FLASH
* [[Pre Linking]] - Avoid cost of runtime linking on first program load
* GNU_HASH: ~ 50% speed improvement in dynamic linking
** See http://sourceware.org/ml/binutils/2006-06/msg00418.html
* [[Application Init Optimizations]] - Improvements in program load and init time via:
** use of mmap vs. read
** control over page mapping characteristics.

== Information ==
*[[Boot-up Time Definition Of Terms]] - definitions of terms
*[[Kernel Instrumentation]] - lists some known kernel instrumentation tools. These are of interest for measuring kernel startup time.
*[[Filesystem Information]] - information about boot-up times with various file systems
*[[Image:alert.gif]] ''in progress'' - [[Boot-up Time Reduction Howto]] - this is a project to catalog existing boot-up time reduction techniques. Work on this project is under way. The wiki will serve as the primary repository of information gathered for this project.
*[[Image:alert.gif]]''no content yet'' - [[Boot-up Time Delay Taxonomy]] - list of delays categorized by boot phase, type and magnitude

== Articles ==
* [http://lwn.net/Articles/192082/ Optimizing Linker Load Times]
** (introducing various kinds of bootuptime reduction, prelinking, etc.)

=== Case Studies ===
*Samsung proof-of-acceptability study for digital still camera: see [[Media:LinuxBootupTimeReduction4DSC.ppt|Boot Up Time Reduction PPT]]
*Tim Bird's (Sony) survey of boot-up time reduction techniques:
**[http://kernel.org/doc/ols/2004/ols2004v1-pages-79-88.pdf Methods to Improve Boot-up Time in Linux] - Paper prepared for 2004 Ottawa Linux Symposium
**{{pdf|ReducingStartupTime v0.8.pdf|Reducing Startup Time in Embedded Linux Systems}} - December 2003 Presentation describing some existing boot-up time reduction techniques and strategies.

== Additional Projects/Mailing Lists/Resources ==
=== Kexec ===
*Kexec is a system which allows a system to be '''rebooted''' without going through BIOS. That is, a Linux kernel can directly boot into another Linux kernel, without going through firmware. See the white paper at: [http://developer.osdl.org/andyp/kexec/whitepaper/kexec.pdf kexec.pdf]
**2004 Kernel Summit presentation: [http://www.xenotime.net/linux/fastboot/fastboot-ks-2004.pdf fastboot.pdf]
**here's another Kexec white paper:[http://www-106.ibm.com/developerworks/linux/library/l-kexec.html?ca=dgr-lnxw04 Reboot Fast]

=== Others ===
*[http://www.bootsplash.org/ bootspash.org] - technology to put up a splash screen early in boot sequence
*[http://dev.gentoo.org/~spock/projects/gensplash/ Gentoo Splashscreen] - newer technology to put a splash screen early in the boot sequence
**see the HOWTO at: [http://gentoo-wiki.com/HOWTO_fbsplash HOWTO FBSplash]
* [http://butterfeet.org/?p=8 PSplash] - PSplash is a userspace graphical boot splash screen for mainly
embedded Linux devices supporting a 16bpp or 32bpp framebuffer.
*[http://www.linuxdevices.com/news/NS5907201615.html FSMLabs Fastboot] - press release by FSMLabs about fast booting of their product. Is any of this published?

*[http://tree.celinuxforum.org/CelfPubWiki/ snapshot boot] - a technology uses software resume to boot up the system quickly.
[[Category:Boot Time]]

Boot Time

2008-06-17T19:08:26Z

TimBird: /* Case Studies */ fix link to Tim Bird's OSL 2004 paper

Boot Time includes topics such as Boot Time measurement, Boot Time reduction, and Boot Time analysis. Boot Time directly impacts the first perception an end user has of a consumer electronic product. Regardless of how attractive or well designed a consumer electronic device is, the time required to move the device from off to an interactive, usable state is critical to obtaining a positive end user experience. Turning on a device is Use Case #1.

== Technology/Project Pages ==
The following are individual pages with information about various technologies relevant to improving Boot Time for Linux. Some of these describe local patches available on this site. Others point to projects or patches maintained elsewhere.

=== Measuring Boot-up Time ===
*[[Printk Times]] - simple system for showing timing information for each printk.
*[[Kernel Function Trace]] - system for reporting function timings in the kernel.
*[[Linux Trace Toolkit]] - system for reporting timing data for certain kernel and process events.
*[http://oprofile.sourceforge.net/news/ Oprofile] - system-wide profiler for Linux.
*[[Bootchart]] - a tool for performance analysis and visualization of the Linux boot process. Resource utilization and process information are collected during the user-space portion of the boot process and are later rendered in a PNG, SVG or EPS encoded chart.
*[http://people.redhat.com/berrange/systemtap/bootprobe/ Bootprobe] - a set of [[System Tap]] scripts for analyzing system bootup.
* and, let us not forget: "cat /proc/uptime"

=== Technologies and Techniques for Reducing Boot Time ===
==== Bootloader speedups ====
*[[Kernel XIP]] - Allow kernel to be executed in-place in ROM or FLASH.
*[[DMA Copy Of Kernel On Startup]] - Copy kernel from Flash to RAM using DMA

==== Kernel speedups ====
*[[Disable Console]] - Avoid overhead of console output during system startup.
*[[RTC No Sync]] - Avoid delay to synchronize system time with RTC clock edge on startup.
*[[Short IDE Delays]] - Reduce duration of IDE startup delays (this is effective but possibly dangerous).
*[[Hardcode kernel module info]] - Reduce the overhead of loading a module, by hardcoding some information used for loading the relocation information
*[[IDE No Probe]] - Force kernel to observe the ide<x>=noprobe option.
*[[Preset LPJ]] - Allow the use of a preset loops_per_jiffy value.
*[[Threaded Device Probing]] - Allow drivers to probe devices in parallel.

==== User-space and application speedups ====
* [[Optimize RC Scripts]] - Reduce overhead of running RC scripts
* [[Parallel RC Scripts]] - Run RC scripts in parallel instead of sequentially
* [[Application XIP]] - Allow programs and libraries to be executed in-place in ROM or FLASH
* [[Pre Linking]] - Avoid cost of runtime linking on first program load
* GNU_HASH: ~ 50% speed improvement in dynamic linking
** See http://sourceware.org/ml/binutils/2006-06/msg00418.html
* [[Application Init Optimizations]] - Improvements in program load and init time via:
** use of mmap vs. read
** control over page mapping characteristics.

== Information ==
*[[Boot-up Time Definition Of Terms]] - definitions of terms
*[[Kernel Instrumentation]] - lists some known kernel instrumentation tools. These are of interest for measuring kernel startup time.
*[[Filesystem Information]] - information about boot-up times with various file systems
*[[Image:alert.gif]] ''in progress'' - [[Boot-up Time Reduction Howto]] - this is a project to catalog existing boot-up time reduction techniques. Work on this project is under way. The wiki will serve as the primary repository of information gathered for this project.
*[[Image:alert.gif]]''no content yet'' - [[Boot-up Time Delay Taxonomy]] - list of delays categorized by boot phase, type and magnitude

== Articles ==
* [http://lwn.net/Articles/192082/ Optimizing Linker Load Times]
** (introducing various kinds of bootuptime reduction, prelinking, etc.)

=== Case Studies ===
*Samsung proof-of-acceptability study for digital still camera: see [[Media:LinuxBootupTimeReduction4DSC.ppt|Boot Up Time Reduction PPT]]
*Tim Bird's (Sony) survey of boot-up time reduction techniques:
**[http://kernel.org/doc/ols/2004/ols2004v1-pages-79-88.pdf Methods to Improve Boot-up Time in Linux] - Paper prepared for 2004 Ottawa Linux Symposium
**{{pdf|ReducingStartupTime v0.8.pdf|Reducing Startup Time in Embedded Linux Systems}} - December 2003 Presentation describing some existing boot-up time reduction techniques and strategies.

== Additional Projects/Mailing Lists/Resources ==
=== Kexec ===
*Kexec is a system which allows a system to be '''rebooted''' without going through BIOS. That is, a Linux kernel can directly boot into another Linux kernel, without going through firmware. See the white paper at: [http://developer.osdl.org/andyp/kexec/whitepaper/kexec.pdf kexec.pdf]
**2004 Kernel Summit presentation: [http://www.xenotime.net/linux/fastboot/fastboot-ks-2004.pdf fastboot.pdf]
**here's another Kexec white paper:[http://www-106.ibm.com/developerworks/linux/library/l-kexec.html?ca=dgr-lnxw04 Reboot Fast]

=== Others ===
*[http://www.bootsplash.org/ bootspash.org] - technology to put up a splash screen early in boot sequence
*[http://dev.gentoo.org/~spock/projects/gensplash/ Gentoo Splashscreen] - newer technology to put a splash screen early in the boot sequence
**see the HOWTO at: [http://gentoo-wiki.com/HOWTO_fbsplash HOWTO FBSplash]
* [http://butterfeet.org/?p=8 PSplash] - PSplash is a userspace graphical boot splash screen for mainly
embedded Linux devices supporting a 16bpp or 32bpp framebuffer.
*[http://www.linuxdevices.com/news/NS5907201615.html FSMLabs Fastboot] - press release by FSMLabs about fast booting of their product. Is any of this published?

*[http://tree.celinuxforum.org/CelfPubWiki/ snapshot boot] - a technology uses software resume to boot up the system quickly.
[[Category:Boot Time]]

Debugging Makefiles

2008-06-13T20:08:55Z

TimBird: add remake

Here is some information on debugging Makefiles:

== showing symbol values, and showing file dependencies ==
There's a good Dr. Dobbs article on this topic, by John Graham-Cumming, at:
* [http://www.ddj.com/development-tools/197003338 Debugging Makefiles]
or printable, all-in-one page, at
http://www.embedded.com/columns/technicalinsights/197003517?printable=true

This article describes some macros you can put in your Makefiles to show
you the values of symbols, and to show the dependencies that led to a particular
target being built. This is handy if you have a complex Makefile that you
are trying to debug.

== Makefile Debugger ==
John has also written a Makefile Debugger.

The following articles describe the debugger and how to use it:
* [http://www.cmcrossroads.com/content/view/6479/120/ An Interactive GNU Make Debugger]
* [http://www.cmcrossroads.com/content/view/6529/120/ Dynamic Breakpoints in the GNU Make Debugger]

The following resources are needed to use the debugger:

* Download gmsl (a library of gnu make stuff), from http://gmsl.sf.net/
* Download gmd (the debugger itself), from http://gmd.sf.net/

Expand the tarballs from these, and place __gmsl, gmsl and gmd in the
directory with the Makefile you wish to debug.

Add the following lines to your Makefile:
include gdm

and

all:
$(__BREAKPOINT)

== remake ==
"remake", is "A patched GNU make with a debuger,
better tracing and error reporting" (based on GNU make 3.80).

See: http://sourceforge.net/projects/bashdb/

Development seems to have stopped, though.

== Debugging a kernel build ==
=== Verbose options ===
There are several Kernel makefile tricks which are helpful for debugging a kernel build.

Try "make V=1 [<rest of make args...>]" to see all the full-length commands used to build the kernel.

Sometimes, if a particular step is breaking and you don't understand why, you can copy-and-paste from
this verbose command output (to the shell command line). To do this you need to make sure you are in
the correct source directory, and that all required files are present.

To see why a particular target is being build, use "make V=2".
This is quite useful when a small change results in much more being build than you expected.

=== Building in a separate directory ===
Use the variable KBUILD_OUTPUT either as an environment variable or on the make command line, if you wish
to put the build output into a separate directory from the source. This can be useful for several reasons, including
when you want to build for multiple architectures from the same source, or when you wish to avoid cluttering up
the source tree with object files, libraries and other generated files (to make diffs easier).

Debugging Makefiles

2008-06-13T19:32:00Z

TimBird: add kernel makefile tips

Here is some information on debugging Makefiles:

== showing symbol values, and showing file dependencies ==
There's a good Dr. Dobbs article on this topic, by John Graham-Cumming, at:
* [http://www.ddj.com/development-tools/197003338 Debugging Makefiles]
or printable, all-in-one page, at
http://www.embedded.com/columns/technicalinsights/197003517?printable=true

This article describes some macros you can put in your Makefiles to show
you the values of symbols, and to show the dependencies that led to a particular
target being built. This is handy if you have a complex Makefile that you
are trying to debug.

== Makefile Debugger ==
John has also written a Makefile Debugger.

The following articles describe the debugger and how to use it:
* [http://www.cmcrossroads.com/content/view/6479/120/ An Interactive GNU Make Debugger]
* [http://www.cmcrossroads.com/content/view/6529/120/ Dynamic Breakpoints in the GNU Make Debugger]

The following resources are needed to use the debugger:

* Download gmsl (a library of gnu make stuff), from http://gmsl.sf.net/
* Download gmd (the debugger itself), from http://gmd.sf.net/

Expand the tarballs from these, and place __gmsl, gmsl and gmd in the
directory with the Makefile you wish to debug.

Add the following lines to your Makefile:
include gdm

and

all:
$(__BREAKPOINT)

== Debugging a kernel build ==
=== Verbose options ===
There are several Kernel makefile tricks which are helpful for debugging a kernel build.

Try "make V=1 [<rest of make args...>]" to see all the full-length commands used to build the kernel.

Sometimes, if a particular step is breaking and you don't understand why, you can copy-and-paste from
this verbose command output (to the shell command line). To do this you need to make sure you are in
the correct source directory, and that all required files are present.

To see why a particular target is being build, use "make V=2".
This is quite useful when a small change results in much more being build than you expected.

=== Building in a separate directory ===
Use the variable KBUILD_OUTPUT either as an environment variable or on the make command line, if you wish
to put the build output into a separate directory from the source. This can be useful for several reasons, including
when you want to build for multiple architectures from the same source, or when you wish to avoid cluttering up
the source tree with object files, libraries and other generated files (to make diffs easier).

Debugging Makefiles

2008-06-13T18:34:07Z

TimBird: /* Makefile Debugger */ re-arrange links

Debugging Makefiles

2008-06-13T18:33:18Z

TimBird:

Debugging Makefiles

2008-06-13T18:28:05Z

TimBird:

Here is some information on debugging Makefiles:

There's a good Dr. Dobbs article on this topic, by John Graham-Cumming, at:
* [http://www.ddj.com/development-tools/197003338 Debugging Makefiles]
or printable, all-in-one page, at
http://www.embedded.com/columns/technicalinsights/197003517?printable=true

John has also written a Makefile Debugger.
The following resources are needed to use this debugger:

* Download gmsl (a library of gnu make stuff), from http://gmsl.sf.net/
* Download gmd (the debugger itself), from http://gmd.sf.net/

Expand the tarballs from these, and place __gmsl, gmsl and gmd in the
directory with the Makefile you wish to debug.

Add the following lines to your Makefile:
include gdm

and

all:
$(__BREAKPOINT)

See the following articles for more information:
* [http://www.cmcrossroads.com/content/view/6479/120/ An Interactive GNU Make Debugger]
* [http://www.cmcrossroads.com/content/view/6529/120/ Dynamic Breakpoints in the GNU Make Debugger]

Debugging Makefiles

2008-06-13T18:27:39Z

TimBird: create page

Here is some information on debugging Makefiles:

There's a good Dr. Dobbs article on this topic, by John Graham-Cumming, at:
* [http://www.ddj.com/development-tools/197003338 Debugging Makefiles]
or printable, all-in-one page, at
http://www.embedded.com/columns/technicalinsights/197003517?printable=true

John has also written a Makefile Debugger.
The following resources are needed to use this debugger:

* Download gmsl (a library of gnu make stuff), from http://gmsl.sf.net/
* Download gmd (the debugger itself), from http://gmd.sf.net/

Explode the tarballs from these, and place __gmsl, gmsl and gmd in the
directory with the Makefile you wish to debug.

Add the following lines to your Makefile:
include gdm

and

all:
$(__BREAKPOINT)

See the following articles for more information:
* [http://www.cmcrossroads.com/content/view/6479/120/ An Interactive GNU Make Debugger]
* [http://www.cmcrossroads.com/content/view/6529/120/ Dynamic Breakpoints in the GNU Make Debugger]

Toolbox

2008-06-13T18:08:43Z

TimBird: /* Debugging Tips */

This page has information about developing Embedded Linux, including links to toolchains, debuggers and other development tools. Also, it has links to pages with debugging tips.

== Development Tools ==
=== Toolchains ===
* see [[Toolchains]]
=== Debuggers ===
* [http://openocd.berlios.de/web/ Open On-Chip Debugger]
* FIXTHIS - need link for debuggers (DDD, gdb, kgdb, etc.)eclipse

=== Integrated Development Environments ===
* FIXTHIS - need link for IDEs (eclipse, etc.)

=== Tracers and Profilers ===
* see [[Kernel Trace Systems]]

=== Benchmarks ===
* see [[Benchmark Programs]]

=== Source Management Tools ===
There are a number of tools for managing patches, which are useful for different tasks.
There's now a whole page devoted to this. See [[Source Management Tools]]

For some simple tools for managing patches, see [[Diff And Patch Tricks]]
== Developer Resources ==
=== Kernel mailing lists, web sites, etc. ===
* See [[Linux Kernel Resources]]

=== Documentation ===
* Linux Device Drivers, 3rd edition - http://lwn.net/Kernel/LDD3/
* Papers from the Ottawa Linux Symposium - broken out - see http://kernel.org/doc/ols/

==== Books ====
* Embedded Linux System Design and Development - by P. Raghavan, Amol Lad, and Sriram Neelakandan (Hardcover - Dec 21, 2005)
** This one looks quite good.
* Embedded Linux Primer: A Practical Real-World Approach - by Christopher Hallinan
** So does this one.
* Building Embedded Linux Systems - by Karim Yaghmour
** This book is a bit dated (the edition I have is from 2003, but it is still a great resource.

=== Code Style Tips ===
* This section is for good [[Code Styling Tips]]

=== Debugging Tips ===
* See the [[Kernel Debugging Tips]] page
* See also [[Debugging Makefiles]]

=== GCC Tips and Tricks ===
* This section of [[GCC Tips]] is a collection of tips and tricks helpful for embedded developers

== Embedded Linux Distributions ==
* see [[Embedded Linux Distributions]]
[[Category:Development Tools]]

Toolchains

2008-06-13T17:24:57Z

TimBird: /* Available Toolchains */ add info on embedded debian toolchains

A [http://en.wikipedia.org/wiki/Toolchain toolchain] is a set of distinct software development tools that are linked (or chained) together by specific stages such as GCC, binutils and glibc (a portion of the [http://en.wikipedia.org/wiki/GNU_Toolchain GNU Toolchain]). Optionally, a toolchain may contain other tools such as a [http://en.wikipedia.org/wiki/Debugger Debugger] or a [http://en.wikipedia.org/wiki/Compiler Compiler] for a specific programming language, such as ,[http://en.wikipedia.org/wiki/C%2B%2B C++]. Quite often, the toolchain used for embedded development is a cross toolchain, or more commonly known as a [http://en.wikipedia.org/wiki/Cross_compiler cross compiler]. All the programs (like GCC) run on a host system of a specific architecture (such as x86) but produce binary code (executables) to run on a different architecture (e.g. ARM). This is called cross compilation and is the typical way of building embedded software. It is possible to compile natively, running gcc on your target. Before searching for a prebuilt toolchain or building your own, it's worth checking to see if one is included with your target hardware's [http://en.wikipedia.org/wiki/Board_support_package Board Support Package (BSP)] if you have one.

== Note about C libraries ==
Realistically, there are two options for the C Library: [http://en.wikipedia.org/wiki/Uclibc uClibc] & [http://en.wikipedia.org/wiki/Glibc glibc]. GLibc is what your PC is probably using. It's a bit of a brute, very powerful but a bit bloated. If flash space and memory footprint is an issue, using uClibc is likely to be the better option. However, the space advantages gained using uClibc are becoming less important as the price of memory & flash continues to drop. There are a few "gotcha"s when using uClibc. At time of writing(uClibc 0.9.28), locales are a bit ropey and the new Application Binary Interface (ABI) for ARM architectures (EABI) introduced with GCC 4.1.1 requires patches to be applied. This situation is likely to get better quickly as uClibc is under heavy development.

== Available Toolchains ==
Creating a cross development toolchain from sources can be a real pain. There are version dependency issues, patches required to make something work etc. etc. Check out the [http://kegel.com/crosstool/crosstool-0.43/buildlogs/ build matrix] for crosstool and look at all the red "failed" entries. Fortunately, there are several groups of people who have done all the hard work for you, producing scripts to create a toolchain or releases of binary toolchains.

=== DENX ELDK ===
The DENX Embedded Linux Development Kit (ELDK) provides a complete and powerful software development environment for embedded and real-time systems. It is available for ARM, PowerPC and MIPS processors and consists of:

* Cross Development Tools (Compiler, Assembler, Linker etc.) to develop software for the target system.
* Native Tools (Shell, commands and libraries) which provide a standard Linux development environment that runs on the target system.
* Firmware that can be easily ported to new boards and processors.
* Linux kernel including the complete source-code with all device drivers, board-support functions etc.
* RTAI (Real Time Application Interface) Extension for systems requiring hard real-time responses.
* SELF (Simple Embedded Linux Framework) as fundament to build your embedded systems on.

All components of the ELDK are available for free with complete source code under GPL and other Free Software Licenses. Also, detailed instructions to rebuild all the tools and packages from scratch are included.

The ELDK can be downloaded for free from several mirror sites or ordered on CD-ROM for a nominal charge (99 Euro). To order the CD please contact office@denx.de

Detailed information about the ELDK is available [http://www.denx.de/wiki/DULG/ELDK here].

=== Buildroot ===
Buildroot is a complete build system based on the Linux Kernel configuration system and supports a wide range of target architectures. It generates root file system images ready to be written to flash. In addition to having a huge number of packages which can be compiled into the image, it also generates a cross toolchain to build those packages from source. Even if you don't want to use buildroot for your root filesystem, it is a useful tool for generating a toolchain. It should be noted however that it only supports uClibc. If you want to use glibc, you'll need something else. Link: [http://buildroot.uclibc.org/ Buildroot homepage]

=== Scratchbox ===
Scratchbox provides toolchains for ARM and x86 target architectures (with PowerPC, MIPS and CRIS in experimental stages). Both uClibc & glibc are supported. Scratchbox simplifies cross compiling software which is built using GNU autotools - Code tests performed by configure are run in an emulator or even on the actual target. The toolchains scratchbox ships with are based on gcc 3.3 and as such are quite old, but stable and well tested. It should be pointed out that scripts to build custom toolchains are also provided with scratchbox allowing more recent gcc versions to be used. Link: [http://www.scratchbox.org/ Scratchbox]

=== Crossdev (Gentoo) ===
Crossdev is specific to developers using Gentoo for their development PCs. It is a script which generates a cross toolchain using the portage build scripts for gcc etc. There are numerous architectures which are supported and both uClibc and glibc toolchains can be built. Link: [http://gentoo-wiki.com/HOWTO_Cross_Compile Gentoo Cross-Compile HOWTO]

=== Crosstool ===
Crosstool is a script which downloads source tar-balls and builds simple gcc/glibc cross toolchains. There is a build matrix which shows which versions of gcc/glibc work together with various architectures ([http://kegel.com/crosstool/crosstool-0.43/buildlogs/ link]). The inclusion of this matrix makes it easy to select which versions of gcc/glibc should be used to generate a toolchain for a particular architecture. Link: [http://kegel.com/crosstool/ Crosstool]

=== Crosstool-NG ===
Crosstool-NG is a fork of crosstool, targeted at easier configuration, re-factored code, and a learning base on how toolchains are built, with support for both uClibc and glibc, for debug tools (gdb, strace, dmalloc...), and a wide range of versions for each tools. Different target architectures are supported as well. Link: [http://ymorin.is-a-geek.org/dokuwiki/projects/crosstool crosstool-NG]

=== CodeSourcery ===
[http://www.codesourcery.com/ CodeSourcery] develops [http://www.codesourcery.com/gnu_toolchains/sgpp/ Sourcery G++], an [http://en.wikipedia.org/wiki/Eclipse_IDE Eclipse] based [http://en.wikipedia.org/wiki/Integrated_development_environment Integrated Development Environment (IDE)] that incorporates the [http://en.wikipedia.org/wiki/GNU_toolchain GNU Toolchain] (gcc, gdb, etc.) for cross development for numerous target architectures. [http://www.codesourcery.com/ CodeSourcery] provides a "lite" version for [http://www.codesourcery.com/gnu_toolchains/arm ARM], [http://www.codesourcery.com/gnu_toolchains/coldfire Coldfire], [http://www.codesourcery.com/gnu_toolchains/mips MIPS] and [http://www.codesourcery.com/gnu_toolchains/power Power] architectures. The toolchains are always very up to date. [http://www.codesourcery.com/ CodeSourcery] contributes enhancements it makes to the [http://en.wikipedia.org/wiki/GNU_toolchain GNU Toolchain] upstream continually, making it the single largest (by patch count) corporate contributor.

=== Crossdev/tsrpm (Timesys) ===
Crossdev is a project sponsored by Timesys, completely unrelated to the Gentoo cross toolchain generation system. The projects main focus is on a tool called tsrpm which is used to build cross development toolchains and generate cross-compiled software packages. Currently only x86 and select PowerPC architectures are supported. Link: [https://crossdev.timesys.com/ Crossdev]

=== Fedora ARM ===
Fedora ARM is a try to port Fedora to ARM.
It provides some tools as an ARM toolchain packaged in RPM format.
Link: [http://fedoraproject.org/wiki/Architectures/ARM Fedora ARM]

=== Embedded Debian cross-tools packages ===
Paraphrasing Wookey (from a post on the linux-embedded mailing list):
[For Debian users, the toolchains problem] is fairly reliably solved.

For a debian-based box just install pre-built cross toolchians from emdebian:
http://www.emdebian.org/tools/crosstools.html
(from i386, amd64, powerpc; to: nearly all debian-supported
architectures, gcc3.3, 3.4, 4.1, 4.2, 4.3)

http://www.emdebian.org/toolchains/search.php?section=devel gives more
details.

emdebian-tools also provides the debian equivalent of crosstool
('emchain' to build your own version of current toolchain,
should a suitable pre-built one not exist.

[[Category:Development Tools]]

Kernel Debugging Tips

2008-06-13T16:13:24Z

TimBird: /* Using CONFIG_DEBUG_LL and printascii() */

Here are some miscellaneous tips for debugging a kernel:

== Debugging early boot problems ==
=== Accessing the printk buffer after a silent hang on boot ===
Sometimes, if the kernel hangs early in the boot process, you get no
messages on the console before the hang. However, there may still
be messages in the printk buffer, which can give you an idea of
where the problem is.

The kernel starts putting messages into the printk buffer as soon
as it starts. They stay buffered there until the console code
has a chance to initialize the console device (often the serial
port for embedded devices). Eve though these messages
are no printed before the hang, it is still possible in some circumstances
to dump the printk buffer and see the messages.

Quinn Jensen writes:

Something I've found handy when the console is
silent is to dump the printk buffer from the boot
loader. To do it you have to know how your boot
loader maps memory compared to the kernel.

==== Redboot example on a Freescale ADS board ====
Quinn says: Here's what I do with Redboot on i.MX31:

fgrep printk_buf System.map

this shows the linked address of the printk_buf, e.g.:

c02338f0 b printk_buf.16194

The address "c02338f0" is in kernel virtual, which,
in the case of i.MX31 ADS, redboot will have mapped
to 0x802338f0. So, after resetting the target board,
but without letting it try to boot again, at the redboot
prompt,

dump -b 0x802338f0 -l 10000

And you see the printk buffer that never got flushed
to the UART. Knowing what's there can be '''very'''
useful in debugging your console.

==== U-boot example on an OMAP OSK board ====
Tim Bird tried these steps and they worked:

grep __log_buf System.map

or

grep __log_buf /proc/kallsyms

These show:

c0352d88 B __log_buf

In the case of the OSK, this address maps to
0x10352d88. So I reset the target board and use the following:

OMAP5912 OSK # md 10352d88
10352d88: 4c3e353c 78756e69 72657620 6e6f6973 <5>Linux version
10352d98: 362e3220 2e32322e 612d3631 6e5f706c 2.6.22.16-alp_n
10352da8: 7428206c 64726962 6d697440 6b736564 l (tbird@timdesk
10352db8: 2e6d612e 796e6f73 6d6f632e 67282029 .am.sony.com) (g
10352dc8: 76206363 69737265 33206e6f 342e342e cc version 3.4.4
10352dd8: 34232029 45525020 54504d45 65755420 ) #4 PREEMPT Tue
...

=== Using CONFIG_DEBUG_LL and printascii() (ARM only) ===
If the kernel fails before the serial console is enabled, you can use CONFIG_DEBUG_LL
to add extra debug output routines to the kernel. These are printascii, printch and printhex.
These routines print directly to the serial port, bypassing the console code, and are available
earlier in machine initialization.

Here is an e-mail exchange seen on the linux-embedded mailing list (with answer by George Davis):
<pre>
> When we try to boot a 2.6.21 kernel after uncompressing the kernel the boot process dies somehow.
> We've figured out so far that the kernel dies somewhere between the gunzip and start_kernel.

Try enabling DEBUG_LL to see if it's an machine ID error. If you see:

Error: unrecognized/unsupported processor variant.

or:

Error: unrecognized/unsupported machine ID...

Then you either don't have proper processor support enabled for your target
or your bootloader is passing in the wrong machine number.

If you still don't see anything, try hacking printk.c to call
printascii() (enabled for the DEBUG_LL case) to print directly to the
serial port w/o a driver, etc.,. You can find more details on these
low-level debugging hacks via a little googling...
</pre>

== Triggering a kernel event ==
=== overloading the sync system call ===
Sometimes, it is nice to trigger an event to happen in the kernel from user space.
Instead of creating infrastructure to handle a /proc event, an ioctl() or making a new syscall,
it can be quick and easy to just overload an existing function. One function not used
very often is sync. (I have found that the sync system call is not normally called by user
space programs (or during standard linux booting).

It is quite easy to put a hook to your own kernel program in the sys_sync() routine
(located in fs/sync.c) and cause it to execute by issuing 'sync' from the shell command line.
This is handy as a temporary mechanism to test things that you have put in the kernel.
[[Category:Development Tools]]

Kernel Debugging Tips

2008-06-13T16:05:06Z

TimBird: put in overloading sync tip

Here are some miscellaneous tips for debugging a kernel:

== Debugging early boot problems ==
=== Accessing the printk buffer after a silent hang on boot ===
Sometimes, if the kernel hangs early in the boot process, you get no
messages on the console before the hang. However, there may still
be messages in the printk buffer, which can give you an idea of
where the problem is.

The kernel starts putting messages into the printk buffer as soon
as it starts. They stay buffered there until the console code
has a chance to initialize the console device (often the serial
port for embedded devices). Eve though these messages
are no printed before the hang, it is still possible in some circumstances
to dump the printk buffer and see the messages.

Quinn Jensen writes:

Something I've found handy when the console is
silent is to dump the printk buffer from the boot
loader. To do it you have to know how your boot
loader maps memory compared to the kernel.

==== Redboot example on a Freescale ADS board ====
Quinn says: Here's what I do with Redboot on i.MX31:

fgrep printk_buf System.map

this shows the linked address of the printk_buf, e.g.:

c02338f0 b printk_buf.16194

The address "c02338f0" is in kernel virtual, which,
in the case of i.MX31 ADS, redboot will have mapped
to 0x802338f0. So, after resetting the target board,
but without letting it try to boot again, at the redboot
prompt,

dump -b 0x802338f0 -l 10000

And you see the printk buffer that never got flushed
to the UART. Knowing what's there can be '''very'''
useful in debugging your console.

==== U-boot example on an OMAP OSK board ====
Tim Bird tried these steps and they worked:

grep __log_buf System.map

or

grep __log_buf /proc/kallsyms

These show:

c0352d88 B __log_buf

In the case of the OSK, this address maps to
0x10352d88. So I reset the target board and use the following:

OMAP5912 OSK # md 10352d88
10352d88: 4c3e353c 78756e69 72657620 6e6f6973 <5>Linux version
10352d98: 362e3220 2e32322e 612d3631 6e5f706c 2.6.22.16-alp_n
10352da8: 7428206c 64726962 6d697440 6b736564 l (tbird@timdesk
10352db8: 2e6d612e 796e6f73 6d6f632e 67282029 .am.sony.com) (g
10352dc8: 76206363 69737265 33206e6f 342e342e cc version 3.4.4
10352dd8: 34232029 45525020 54504d45 65755420 ) #4 PREEMPT Tue
...

=== Using CONFIG_DEBUG_LL and printascii() ===
If the kernel fails before the serial console is enabled, you can use CONFIG_DEBUG_LL
to change the way the printk code outputs characters.

Here is an e-mail exchange seen on the linux-embedded mailing list (with answer by George Davis):
<pre>
> When we try to boot a 2.6.21 kernel after uncompressing the kernel the boot process dies somehow.
> We've figured out so far that the kernel dies somewhere between the gunzip and start_kernel.

Try enabling DEBUG_LL to see if it's an machine ID error. If you see:

Error: unrecognized/unsupported processor variant.

or:

Error: unrecognized/unsupported machine ID...

Then you either don't have proper processor support enabled for your target
or your bootloader is passing in the wrong machine number.

If you still don't see anything, try hacking printk.c to call
printascii() (enabled for the DEBUG_LL case) to print directly to the
serial port w/o a driver, etc.,. You can find more details on these
low-level debugging hacks via a little googling...
</pre>

== Triggering a kernel event ==
=== overloading the sync system call ===
Sometimes, it is nice to trigger an event to happen in the kernel from user space.
Instead of creating infrastructure to handle a /proc event, an ioctl() or making a new syscall,
it can be quick and easy to just overload an existing function. One function not used
very often is sync. (I have found that the sync system call is not normally called by user
space programs (or during standard linux booting).

It is quite easy to put a hook to your own kernel program in the sys_sync() routine
(located in fs/sync.c) and cause it to execute by issuing 'sync' from the shell command line.
This is handy as a temporary mechanism to test things that you have put in the kernel.
[[Category:Development Tools]]

Kernel Debugging Tips

2008-06-13T16:00:02Z

TimBird:

Here are some miscellaneous tips for debugging a kernel:

== Debugging early boot problems ==
=== Accessing the printk buffer after a silent hang on boot ===
Sometimes, if the kernel hangs early in the boot process, you get no
messages on the console before the hang. However, there may still
be messages in the printk buffer, which can give you an idea of
where the problem is.

The kernel starts putting messages into the printk buffer as soon
as it starts. They stay buffered there until the console code
has a chance to initialize the console device (often the serial
port for embedded devices). Eve though these messages
are no printed before the hang, it is still possible in some circumstances
to dump the printk buffer and see the messages.

Quinn Jensen writes:

Something I've found handy when the console is
silent is to dump the printk buffer from the boot
loader. To do it you have to know how your boot
loader maps memory compared to the kernel.

==== Redboot example on a Freescale ADS board ====
Quinn says: Here's what I do with Redboot on i.MX31:

fgrep printk_buf System.map

this shows the linked address of the printk_buf, e.g.:

c02338f0 b printk_buf.16194

The address "c02338f0" is in kernel virtual, which,
in the case of i.MX31 ADS, redboot will have mapped
to 0x802338f0. So, after resetting the target board,
but without letting it try to boot again, at the redboot
prompt,

dump -b 0x802338f0 -l 10000

And you see the printk buffer that never got flushed
to the UART. Knowing what's there can be '''very'''
useful in debugging your console.

==== U-boot example on an OMAP OSK board ====
Tim Bird tried these steps and they worked:

grep __log_buf System.map

or

grep __log_buf /proc/kallsyms

These show:

c0352d88 B __log_buf

In the case of the OSK, this address maps to
0x10352d88. So I reset the target board and use the following:

OMAP5912 OSK # md 10352d88
10352d88: 4c3e353c 78756e69 72657620 6e6f6973 <5>Linux version
10352d98: 362e3220 2e32322e 612d3631 6e5f706c 2.6.22.16-alp_n
10352da8: 7428206c 64726962 6d697440 6b736564 l (tbird@timdesk
10352db8: 2e6d612e 796e6f73 6d6f632e 67282029 .am.sony.com) (g
10352dc8: 76206363 69737265 33206e6f 342e342e cc version 3.4.4
10352dd8: 34232029 45525020 54504d45 65755420 ) #4 PREEMPT Tue
...

=== Using CONFIG_DEBUG_LL and printascii() ===
If the kernel fails before the serial console is enabled, you can use CONFIG_DEBUG_LL
to change the way the printk code outputs characters.

Here is an e-mail exchange seen on the linux-embedded mailing list (with answer by George Davis):
<pre>
> When we try to boot a 2.6.21 kernel after uncompressing the kernel the boot process dies somehow.
> We've figured out so far that the kernel dies somewhere between the gunzip and start_kernel.

Try enabling DEBUG_LL to see if it's an machine ID error. If you see:

Error: unrecognized/unsupported processor variant.

or:

Error: unrecognized/unsupported machine ID...

Then you either don't have proper processor support enabled for your target
or your bootloader is passing in the wrong machine number.

If you still don't see anything, try hacking printk.c to call
printascii() (enabled for the DEBUG_LL case) to print directly to the
serial port w/o a driver, etc.,. You can find more details on these
low-level debugging hacks via a little googling...
</pre>

[[Category:Development Tools]]

Kernel Debugging Tips

2008-06-13T15:58:49Z

TimBird: add DEBUG_LL info

Here are some miscellaneous tips for debugging a kernel:

== Accessing the printk buffer after a silent hang on boot ==
Sometimes, if the kernel hangs early in the boot process, you get no
messages on the console before the hang. However, there may still
be messages in the printk buffer, which can give you an idea of
where the problem is.

The kernel starts putting messages into the printk buffer as soon
as it starts. They stay buffered there until the console code
has a chance to initialize the console device (often the serial
port for embedded devices). Eve though these messages
are no printed before the hang, it is still possible in some circumstances
to dump the printk buffer and see the messages.

Quinn Jensen writes:

Something I've found handy when the console is
silent is to dump the printk buffer from the boot
loader. To do it you have to know how your boot
loader maps memory compared to the kernel.

=== Redboot example on a Freescale ADS board ===
Quinn says: Here's what I do with Redboot on i.MX31:

fgrep printk_buf System.map

this shows the linked address of the printk_buf, e.g.:

c02338f0 b printk_buf.16194

The address "c02338f0" is in kernel virtual, which,
in the case of i.MX31 ADS, redboot will have mapped
to 0x802338f0. So, after resetting the target board,
but without letting it try to boot again, at the redboot
prompt,

dump -b 0x802338f0 -l 10000

And you see the printk buffer that never got flushed
to the UART. Knowing what's there can be '''very'''
useful in debugging your console.

=== U-boot example on an OMAP OSK board ===
Tim Bird tried these steps and they worked:

grep __log_buf System.map

or

grep __log_buf /proc/kallsyms

These show:

c0352d88 B __log_buf

In the case of the OSK, this address maps to
0x10352d88. So I reset the target board and use the following:

OMAP5912 OSK # md 10352d88
10352d88: 4c3e353c 78756e69 72657620 6e6f6973 <5>Linux version
10352d98: 362e3220 2e32322e 612d3631 6e5f706c 2.6.22.16-alp_n
10352da8: 7428206c 64726962 6d697440 6b736564 l (tbird@timdesk
10352db8: 2e6d612e 796e6f73 6d6f632e 67282029 .am.sony.com) (g
10352dc8: 76206363 69737265 33206e6f 342e342e cc version 3.4.4
10352dd8: 34232029 45525020 54504d45 65755420 ) #4 PREEMPT Tue
...

== Debugging very early boot problems ==
If the kernel fails before the serial console is enabled, you can use CONFIG_DEBUG_LL
to change the way the printk code outputs characters.

Here is an e-mail exchange seen on the linux-embedded mailing list (with answer by George Davis):
<pre>
> When we try to boot a 2.6.21 kernel after uncompressing the kernel the boot process dies somehow.
> We've figured out so far that the kernel dies somewhere between the gunzip and start_kernel.

Try enabling DEBUG_LL to see if it's an machine ID error. If you see:

Error: unrecognized/unsupported processor variant.

or:

Error: unrecognized/unsupported machine ID...

Then you either don't have proper processor support enabled for your target
or your bootloader is passing in the wrong machine number.

If you still don't see anything, try hacking printk.c to call
printascii() (enabled for the DEBUG_LL case) to print directly to the
serial port w/o a driver, etc.,. You can find more details on these
low-level debugging hacks via a little googling...
</pre>

[[Category:Development Tools]]

Kernel Function Trace

2008-06-12T21:20:17Z

TimBird: /* kft log output (excerpt) */ upload sample kfi log

== Introduction ==
Kernel Function Trace (KFT) is a kernel function tracing system, which uses the "-finstrument-functions" capability of the gcc compiler to add
instrumentation callouts to every function entry and exit. The KFT system provides for capturing these callouts and generating a trace of events, with
timing details. KFT is excellent at providing a good timing overview of kernel procedures, allowing you to see where time is spent in functions and
sub-routines in the kernel.

The main mode of operation with KFT is to use the system with a dynamic trace configuration. That is, you can set a trace configuration after kernel
startup, using the <code>/proc/kft</code> interface, and retrieve trace data immediately. However, another (special) mode of operation is available, called STATIC_RUN
mode, where the configuration for a KFT run is configured and compiled statically into the kernel. This mode is useful for getting a trace of kernel
operation during system bootup (before user space is running).

The KFT configuration lets you specify how to automatically start and stop a trace, whether to include interrupts as part of the trace, and whether to
filter the trace data by various criteria (for minimum function duration, only certain listed functions, etc.) KFT trace data is retrieved by reading from
<code>/proc/kft_data</code> after the trace is complete.

Tools are supplied to convert numeric trace data to kernel symbols, and to process and analyze the data in a KFT trace.

== Basic Use ==
Documentation for KFT is available (as of 2.6.12) in Documentation/kft.txt, after applying the kft-all-in-one.patch.

An online guide is provided at [[Using Kernel Function Trace]]

Here's a presentation about KFT usage:
* Presentation: [[Media:KFI-presentation.pdf|Learning the Kernel and Finding Performance Problems with KFI]]
* Sample trace used with presentation: [[Media:omap-serial_init.trace.txt|omap-serial_init.trace.txt]]

KFT used to be called KFI (for Kernel Function Instrumentation). For prior releases of KFT, see KernelFunctionInstrumentation

== Download ==
=== Patches ===
* Download directory with recent versions: ftp://dslab.lzu.edu.cn/pub/kft/
** This is a fairly slow link - you can download the patch for 2.6.21 here: [[Media:kft-all-in-one-2.6.21.patch|kft-all-in-one-2.6.21.patch]]
* Patches for Linux 2.6.8.1, 2.6.11 and 2.6.12: see the [[Patch Archive]] page (available as an all-in-one patch or a tar archive of broken-out patches)
* Patch for Linux 2.6.11: (can just download [[Media:kfi-2.patch|kfi-2.patch]])
* Patch for Linux 2.6.7 (for x86 only): [[Media:kfi-26-test1.patch|kfi-26-test1.patch]]
* Patch for CELF kernel (based on linux-2.4.20): [[Media:kfi-24-test4.patch|kfi-24-test4.patch]]

=== KFT utilities ===
KFT includes several helper scripts which are located in the kernel <code>scripts</code> directory:
* addr2sym - convert function addresses to symbols in the trace data
* kd - KFT dump - does filtering, sorting, analysis and trace formatting of KFT trace logs
* mkkftrun.pl - used during building the kernel to convert a configuration file into a C file to be compiled into the kernel
* sym2addr - convert function names to addresses in a KFT configuration file (for a dynamic trace)

See Documentation/kft.txt, in the kernel source tree after applying the patch, for instructions on using these programs.

== How To Use ==
* download both the patch
* apply the patch in the kernel top-level directory:
* patch -p1 <kft.patch
* read the rest of the instructions in the Documentation/kft.txt file. (my apologies for being lazy!)

=== Adding platform support for the kft clock source ===
The current patch (from Sep 2005), uses sched_clock() as the clock source for kft_readclock(). sched_clock() is new in the 2.6 kernel, and returns a 64-bit value containing nanoseconds
(not necessarily relative to any particular time base, but assumed to be monotonically increasing, and relatively frequency-stable.)

If your platform has good support for sched_clock(), then KFT should work for you unmodified. If not, you may wish to do one of two things:
* improve support for sched_clock() in your board port, or
* write a custom kft_readclock() routine.

A "good" sched_clock() routine will provide at least microsecond resolution on return values. Some architectures have sched_clock() returning values based on the <code>jiffy</code> variable,
which on many embedded platforms only has resolution to 10 milliseconds.

There are some sample custom kft_readclock() routines in the current patch for different architectures.

== Issues ==
Here is a list of things that need more work:
* may need to add noinstrument attributes for some time-critical code (need to check this)
** maybe check "Function Trace in KDB" patch for help with this

=== Overhead ===
Mitsubishi measured the overhead of KFI (the predecessor to KFT). The period is from start_kernel() to smp_init().

Platform was: SH7751R 240MHz (Memory Clock 80MHz)

<code><tt>
With KFI      : 922.419 msec<br/>
Without KFI   : 666.982 msec<br/>
Overhead      : 27.69%
</tt></code>

== Similar technologies ==
There are other technologies for doing call traces or kernel profiling that are similar to KFT. Some of these are mentioned on the [[Kernel Instrumentation]] page. One that is very similar is a kernel trace mechanism for use with KDB. A patch was posted to LKML in January of 2002.
See the message: http://www.uwsg.iu.edu/hypermail/linux/kernel/0201.3/0888.html

== Filter Q&A ==
Tim asked the question:

Q. Is there a way to adjust the trigger or filters to reduce the memory usage?

A. The memory usage is determined by the size of the log, which is specified by <code>logentries</code> in the KFT configuration. If <code>logentries</code> is not specified, it defaults to a rather large number (20,000 in the current code). To use a smaller trace log, specify a smaller number of logentries in the KFT configuration.

The use of triggers and filters can help you fit more data (or more pertinent data) into the log, so you can more readily see the information you are interested in.

By setting start and stop triggers with a narrower "range" of operation, then the amount of data put into the log will be more limited. For example, the default configuration for a static trace uses

<code>trigger start entry start_kernel<br/>
trigger stop entry to_userspace </code>

This will trace EVERYTHING that the kernel does between those two routines. However, you can limit tracing to a much smaller time area of kernel initialization using better triggers. Here is an example showing a triggers for just watching mem_init():
<code>
trigger start entry mem_init<br/>
trigger stop exit mem_init<br/>
</code>

Filters are also vital to reduce the number of entries the trace log. With no time filters in place, KFT will log every single function executed by the kernel. This will quickly overrun the log (no matter what size you have reserved with <code>logentries</code>.

When using KFT to find long-duration functions in the kernel, we usually are not interested in routines that execute quickly, and instead use something like "filter mintime 500" to filter out routines taking less than 500 microseconds.

== Sample results ==
Here is an excerpt from a KFI log trace (processed with addr2sym). It shows all functions which lasted longer than 500 microseconds, from when the kernel entered start_kernel() to when it entered to_userspace().

=== kft log output (excerpt) ===
<code>
Kernel Instrumentation Run ID 0

Logging started at 6785045 usec by entry to function start_kernel
Logging stopped at 8423650 usec by entry to function to_userspace

Filters:
500 usecs minimum execution time

Filter Counters:

Execution time filter count = 896348
Total entries filtered = 896348
Entries not found = 24

Number of entries after filters = 1757

Entry Delta PID Function Called At
1 0 0 start_kernel L6+0x0
14 8687 0 setup_arch start_kernel+0x35
39 891 0 setup_memory setup_arch+0x2a8
53 872 0 register_bootmem_low_pages setup_memory+0x8f
54 871 0 free_bootmem register_bootmem_low_pages+0x95
54 871 0 free_bootmem_core free_bootmem+0x34
930 7432 0 paging_init setup_arch+0x2af
935 7427 0 zone_sizes_init paging_init+0x4e
935 7427 0 free_area_init zone_sizes_init+0x83
935 7427 0 free_area_init_node free_area_init+0x4b
935 3759 0 __alloc_bootmem_node free_area_init_node+0xc5
935 3759 0 __alloc_bootmem_core __alloc_bootmem_node+0x43
4694 3668 0 free_area_init_core free_area_init_node+0x75
4817 3535 0 memmap_init_zone free_area_init_core+0x2bd
8807 266911 0 time_init start_kernel+0xb6
8807 261404 0 get_cmos_time time_init+0x1c
270211 5507 0 select_timer time_init+0x41
270211 5507 0 init_tsc select_timer+0x45
270211 5507 0 calibrate_tsc init_tsc+0x6c
275718 1638 0 console_init start_kernel+0xbb
275718 1638 0 con_init console_init+0x59
275954 733 0 vgacon_save_screen con_init+0x288
277376 6730 0 mem_init start_kernel+0xf8
277376 1691 0 free_all_bootmem mem_init+0x52
277376 1691 0 free_all_bootmem_core free_all_bootmem+0x24
284118 25027 0 calibrate_delay start_kernel+0x10f
293860 770 0 __delay calibrate_delay+0x62
293860 770 0 delay_tsc __delay+0x26
294951 1534 0 __delay calibrate_delay+0x62
294951 1534 0 delay_tsc __delay+0x26
297134 1149 0 __delay calibrate_delay+0xbe
297134 1149 0 delay_tsc __delay+0x26
.
.
.
1638605 0 145 filemap_nopage do_no_page+0xef
1638605 0 145 __lock_page filemap_nopage+0x286
1638605 0 145 io_schedule __lock_page+0x95
1638605 0 145 schedule io_schedule+0x24
1638605 0 5 schedule worker_thread+0x217
1638605 0 1 to_userspace init+0xa6
</code>

The log is attached here: [[Media:Kfiboot-9.lst]]
A Delta value of 0 usually means the exit from the routine was not seen.

=== kft log analysis with 'kd' ===
Below is a <code>kd</code> dump of the data from the above log.

For the purpose of finding areas of big time in the kernel, the functions with high "Local" time are important. For example, <code>delay_tsc()</code> is called 156 times, resulting in 619 milliseconds of duration. Other time-consuming routines were: <code>isapnp_isolate()</code>, <code>get_cmos_time()</code>, <code>default_idle()</code>.

The top line showing schedule() called 192 times and lasting over 5 seconds, is accounted wrong due to the switch in execution control inside the schedule routine. (The count of 192 calls is correct, but the duration is wrong.)

<pre>
$ ~/work/kft/kft/kd -n 30 kftboot-9.lst
Function Count Time Average Local
------------------------- ----- -------- -------- --------
schedule 192 5173790 26946 5173790
do_basic_setup 1 1159270 1159270 14
do_initcalls 1 1159256 1159256 627
__delay 156 619322 3970 0
delay_tsc 156 619322 3970 619322
__const_udelay 146 608427 4167 0
probe_hwif 8 553972 69246 126
do_probe 31 553025 17839 68
ide_delay_50ms 103 552588 5364 0
isapnp_init 1 383138 383138 18
isapnp_isolate 1 383120 383120 311629
ide_init 1 339778 339778 22
probe_for_hwifs 1 339756 339756 103
ide_scan_pcibus 1 339653 339653 13
init_setup_piix 2 339640 169820 0
ide_scan_pcidev 2 339640 169820 0
piix_init_one 2 339640 169820 0
ide_setup_pci_device 2 339640 169820 242
probe_hwif_init 4 339398 84849 40
time_init 1 266911 266911 0
get_cmos_time 1 261404 261404 261404
ide_generic_init 1 214614 214614 0
ideprobe_init 1 214614 214614 0
wait_for_completion 6 194573 32428 0
default_idle 183 192589 1052 192589
io_schedule 18 171313 9517 0
__wait_on_buffer 14 150369 10740 141
i8042_init 1 137210 137210 295
i8042_port_register 2 135318 67659 301
__serio_register_port 2 135017 67508 0
</pre>

=== kft nested call trace with 'kd -c' ===
Below is a <code>kd -c</code> trace of the data from a log taken from a PPC440g platform, from a (dynamic) trace of the function do_fork().

Here is the configuration file that was used:
<code>new
begin
trigger start entry do_fork
trigger stop exit do_fork
end
</code>

Here is the first part of the trace in nested call format:
Times (Entry, Duration and Local) are in micro-seconds. Note the timer interrupt during the routine.
<code>
Entry Duration Local Pid Trace
4 20428 209 33 do_fork
7 6 6 33 | alloc_pidmap
18 2643 84 33 | copy_process
21 114 19 33 | | dup_task_struct
24 8 6 33 | | | prepare_to_copy
27 2 2 33 | | | | sub_preempt_count
35 22 9 33 | | | kmem_cache_alloc
38 2 2 33 | | | | __might_sleep
43 11 9 33 | | | | cache_alloc_refill
49 2 2 33 | | | | | sub_preempt_count
60 65 6 33 | | | __get_free_pages
63 59 14 33 | | | | __alloc_pages
65 3 3 33 | | | | | __might_sleep
71 3 3 33 | | | | | zone_watermark_ok
77 37 17 33 | | | | | buffered_rmqueue
80 4 4 33 | | | | | | __rmqueue
86 3 3 33 | | | | | | sub_preempt_count
92 3 3 33 | | | | | | bad_range
98 2 2 33 | | | | | | __mod_page_state
103 8 5 33 | | | | | | prep_new_page
106 3 3 33 | | | | | | | set_page_refs
117 2 2 33 | | | | | zone_statistics
141 25 4 33 | | do_posix_clock_monotonic_gettime
143 21 6 33 | | | do_posix_clock_monotonic_get
146 15 6 33 | | | | do_posix_clock_monotonic_gettime_parts
149 9 6 33 | | | | | getnstimeofday
152 3 3 33 | | | | | | do_gettimeofday
169 3 3 33 | | copy_semundo
174 41 17 33 | | copy_files
177 19 9 33 | | | kmem_cache_alloc
180 2 2 33 | | | | __might_sleep
185 8 5 33 | | | | cache_alloc_refill
188 3 3 33 | | | | | sub_preempt_count
200 3 3 33 | | | count_open_files
209 2 2 33 | | | sub_preempt_count
218 19 8 33 | | kmem_cache_alloc
220 2 2 33 | | | __might_sleep
225 9 6 33 | | | cache_alloc_refill
229 3 3 33 | | | | sub_preempt_count
241 2 2 33 | | sub_preempt_count
246 216 9 33 | | kmem_cache_alloc
249 199 199 33 | | | __might_sleep
!!!! start
253 151 63 33 timer_interrupt
256 8 6 -1 ! profile_tick
259 2 2 -1 ! ! profile_hit
267 61 15 -1 ! update_process_times
270 8 5 -1 ! ! account_system_time
273 3 3 -1 ! ! ! update_mem_hiwater
281 8 5 -1 ! ! run_local_timers
284 3 3 -1 ! ! ! raise_softirq
293 27 16 -1 ! ! scheduler_tick
.
.
.
</code>

To see the full trace, go to the [[KftDoForkTrace]] page.

[[Category:Boot Time]]
[[Category:Kernel Function Trace]]

File:Kfiboot-9.lst

2008-06-12T21:16:46Z

TimBird: sample kfi boot log

sample kfi boot log

Kernel Function Trace

2008-06-12T21:12:34Z

TimBird: /* kft log analysis with 'kd' */ fix table

== Introduction ==
Kernel Function Trace (KFT) is a kernel function tracing system, which uses the "-finstrument-functions" capability of the gcc compiler to add
instrumentation callouts to every function entry and exit. The KFT system provides for capturing these callouts and generating a trace of events, with
timing details. KFT is excellent at providing a good timing overview of kernel procedures, allowing you to see where time is spent in functions and
sub-routines in the kernel.

The main mode of operation with KFT is to use the system with a dynamic trace configuration. That is, you can set a trace configuration after kernel
startup, using the <code>/proc/kft</code> interface, and retrieve trace data immediately. However, another (special) mode of operation is available, called STATIC_RUN
mode, where the configuration for a KFT run is configured and compiled statically into the kernel. This mode is useful for getting a trace of kernel
operation during system bootup (before user space is running).

The KFT configuration lets you specify how to automatically start and stop a trace, whether to include interrupts as part of the trace, and whether to
filter the trace data by various criteria (for minimum function duration, only certain listed functions, etc.) KFT trace data is retrieved by reading from
<code>/proc/kft_data</code> after the trace is complete.

Tools are supplied to convert numeric trace data to kernel symbols, and to process and analyze the data in a KFT trace.

== Basic Use ==
Documentation for KFT is available (as of 2.6.12) in Documentation/kft.txt, after applying the kft-all-in-one.patch.

An online guide is provided at [[Using Kernel Function Trace]]

Here's a presentation about KFT usage:
* Presentation: [[Media:KFI-presentation.pdf|Learning the Kernel and Finding Performance Problems with KFI]]
* Sample trace used with presentation: [[Media:omap-serial_init.trace.txt|omap-serial_init.trace.txt]]

KFT used to be called KFI (for Kernel Function Instrumentation). For prior releases of KFT, see KernelFunctionInstrumentation

== Download ==
=== Patches ===
* Download directory with recent versions: ftp://dslab.lzu.edu.cn/pub/kft/
** This is a fairly slow link - you can download the patch for 2.6.21 here: [[Media:kft-all-in-one-2.6.21.patch|kft-all-in-one-2.6.21.patch]]
* Patches for Linux 2.6.8.1, 2.6.11 and 2.6.12: see the [[Patch Archive]] page (available as an all-in-one patch or a tar archive of broken-out patches)
* Patch for Linux 2.6.11: (can just download [[Media:kfi-2.patch|kfi-2.patch]])
* Patch for Linux 2.6.7 (for x86 only): [[Media:kfi-26-test1.patch|kfi-26-test1.patch]]
* Patch for CELF kernel (based on linux-2.4.20): [[Media:kfi-24-test4.patch|kfi-24-test4.patch]]

=== KFT utilities ===
KFT includes several helper scripts which are located in the kernel <code>scripts</code> directory:
* addr2sym - convert function addresses to symbols in the trace data
* kd - KFT dump - does filtering, sorting, analysis and trace formatting of KFT trace logs
* mkkftrun.pl - used during building the kernel to convert a configuration file into a C file to be compiled into the kernel
* sym2addr - convert function names to addresses in a KFT configuration file (for a dynamic trace)

See Documentation/kft.txt, in the kernel source tree after applying the patch, for instructions on using these programs.

== How To Use ==
* download both the patch
* apply the patch in the kernel top-level directory:
* patch -p1 <kft.patch
* read the rest of the instructions in the Documentation/kft.txt file. (my apologies for being lazy!)

=== Adding platform support for the kft clock source ===
The current patch (from Sep 2005), uses sched_clock() as the clock source for kft_readclock(). sched_clock() is new in the 2.6 kernel, and returns a 64-bit value containing nanoseconds
(not necessarily relative to any particular time base, but assumed to be monotonically increasing, and relatively frequency-stable.)

If your platform has good support for sched_clock(), then KFT should work for you unmodified. If not, you may wish to do one of two things:
* improve support for sched_clock() in your board port, or
* write a custom kft_readclock() routine.

A "good" sched_clock() routine will provide at least microsecond resolution on return values. Some architectures have sched_clock() returning values based on the <code>jiffy</code> variable,
which on many embedded platforms only has resolution to 10 milliseconds.

There are some sample custom kft_readclock() routines in the current patch for different architectures.

== Issues ==
Here is a list of things that need more work:
* may need to add noinstrument attributes for some time-critical code (need to check this)
** maybe check "Function Trace in KDB" patch for help with this

=== Overhead ===
Mitsubishi measured the overhead of KFI (the predecessor to KFT). The period is from start_kernel() to smp_init().

Platform was: SH7751R 240MHz (Memory Clock 80MHz)

<code><tt>
With KFI      : 922.419 msec<br/>
Without KFI   : 666.982 msec<br/>
Overhead      : 27.69%
</tt></code>

== Similar technologies ==
There are other technologies for doing call traces or kernel profiling that are similar to KFT. Some of these are mentioned on the [[Kernel Instrumentation]] page. One that is very similar is a kernel trace mechanism for use with KDB. A patch was posted to LKML in January of 2002.
See the message: http://www.uwsg.iu.edu/hypermail/linux/kernel/0201.3/0888.html

== Filter Q&A ==
Tim asked the question:

Q. Is there a way to adjust the trigger or filters to reduce the memory usage?

A. The memory usage is determined by the size of the log, which is specified by <code>logentries</code> in the KFT configuration. If <code>logentries</code> is not specified, it defaults to a rather large number (20,000 in the current code). To use a smaller trace log, specify a smaller number of logentries in the KFT configuration.

The use of triggers and filters can help you fit more data (or more pertinent data) into the log, so you can more readily see the information you are interested in.

By setting start and stop triggers with a narrower "range" of operation, then the amount of data put into the log will be more limited. For example, the default configuration for a static trace uses

<code>trigger start entry start_kernel<br/>
trigger stop entry to_userspace </code>

This will trace EVERYTHING that the kernel does between those two routines. However, you can limit tracing to a much smaller time area of kernel initialization using better triggers. Here is an example showing a triggers for just watching mem_init():
<code>
trigger start entry mem_init<br/>
trigger stop exit mem_init<br/>
</code>

Filters are also vital to reduce the number of entries the trace log. With no time filters in place, KFT will log every single function executed by the kernel. This will quickly overrun the log (no matter what size you have reserved with <code>logentries</code>.

When using KFT to find long-duration functions in the kernel, we usually are not interested in routines that execute quickly, and instead use something like "filter mintime 500" to filter out routines taking less than 500 microseconds.

== Sample results ==
Here is an excerpt from a KFI log trace (processed with addr2sym). It shows all functions which lasted longer than 500 microseconds, from when the kernel entered start_kernel() to when it entered to_userspace().

=== kft log output (excerpt) ===
<code>
Kernel Instrumentation Run ID 0

Logging started at 6785045 usec by entry to function start_kernel
Logging stopped at 8423650 usec by entry to function to_userspace

Filters:
500 usecs minimum execution time

Filter Counters:

Execution time filter count = 896348
Total entries filtered = 896348
Entries not found = 24

Number of entries after filters = 1757

Entry Delta PID Function Called At
1 0 0 start_kernel L6+0x0
14 8687 0 setup_arch start_kernel+0x35
39 891 0 setup_memory setup_arch+0x2a8
53 872 0 register_bootmem_low_pages setup_memory+0x8f
54 871 0 free_bootmem register_bootmem_low_pages+0x95
54 871 0 free_bootmem_core free_bootmem+0x34
930 7432 0 paging_init setup_arch+0x2af
935 7427 0 zone_sizes_init paging_init+0x4e
935 7427 0 free_area_init zone_sizes_init+0x83
935 7427 0 free_area_init_node free_area_init+0x4b
935 3759 0 __alloc_bootmem_node free_area_init_node+0xc5
935 3759 0 __alloc_bootmem_core __alloc_bootmem_node+0x43
4694 3668 0 free_area_init_core free_area_init_node+0x75
4817 3535 0 memmap_init_zone free_area_init_core+0x2bd
8807 266911 0 time_init start_kernel+0xb6
8807 261404 0 get_cmos_time time_init+0x1c
270211 5507 0 select_timer time_init+0x41
270211 5507 0 init_tsc select_timer+0x45
270211 5507 0 calibrate_tsc init_tsc+0x6c
275718 1638 0 console_init start_kernel+0xbb
275718 1638 0 con_init console_init+0x59
275954 733 0 vgacon_save_screen con_init+0x288
277376 6730 0 mem_init start_kernel+0xf8
277376 1691 0 free_all_bootmem mem_init+0x52
277376 1691 0 free_all_bootmem_core free_all_bootmem+0x24
284118 25027 0 calibrate_delay start_kernel+0x10f
293860 770 0 __delay calibrate_delay+0x62
293860 770 0 delay_tsc __delay+0x26
294951 1534 0 __delay calibrate_delay+0x62
294951 1534 0 delay_tsc __delay+0x26
297134 1149 0 __delay calibrate_delay+0xbe
297134 1149 0 delay_tsc __delay+0x26
.
.
.
1638605 0 145 filemap_nopage do_no_page+0xef
1638605 0 145 __lock_page filemap_nopage+0x286
1638605 0 145 io_schedule __lock_page+0x95
1638605 0 145 schedule io_schedule+0x24
1638605 0 5 schedule worker_thread+0x217
1638605 0 1 to_userspace init+0xa6
</code>

The log is attached here: kfiboot-9.lst
A Delta value of 0 usually means the exit from the routine was not seen.

=== kft log analysis with 'kd' ===
Below is a <code>kd</code> dump of the data from the above log.

For the purpose of finding areas of big time in the kernel, the functions with high "Local" time are important. For example, <code>delay_tsc()</code> is called 156 times, resulting in 619 milliseconds of duration. Other time-consuming routines were: <code>isapnp_isolate()</code>, <code>get_cmos_time()</code>, <code>default_idle()</code>.

The top line showing schedule() called 192 times and lasting over 5 seconds, is accounted wrong due to the switch in execution control inside the schedule routine. (The count of 192 calls is correct, but the duration is wrong.)

<pre>
$ ~/work/kft/kft/kd -n 30 kftboot-9.lst
Function Count Time Average Local
------------------------- ----- -------- -------- --------
schedule 192 5173790 26946 5173790
do_basic_setup 1 1159270 1159270 14
do_initcalls 1 1159256 1159256 627
__delay 156 619322 3970 0
delay_tsc 156 619322 3970 619322
__const_udelay 146 608427 4167 0
probe_hwif 8 553972 69246 126
do_probe 31 553025 17839 68
ide_delay_50ms 103 552588 5364 0
isapnp_init 1 383138 383138 18
isapnp_isolate 1 383120 383120 311629
ide_init 1 339778 339778 22
probe_for_hwifs 1 339756 339756 103
ide_scan_pcibus 1 339653 339653 13
init_setup_piix 2 339640 169820 0
ide_scan_pcidev 2 339640 169820 0
piix_init_one 2 339640 169820 0
ide_setup_pci_device 2 339640 169820 242
probe_hwif_init 4 339398 84849 40
time_init 1 266911 266911 0
get_cmos_time 1 261404 261404 261404
ide_generic_init 1 214614 214614 0
ideprobe_init 1 214614 214614 0
wait_for_completion 6 194573 32428 0
default_idle 183 192589 1052 192589
io_schedule 18 171313 9517 0
__wait_on_buffer 14 150369 10740 141
i8042_init 1 137210 137210 295
i8042_port_register 2 135318 67659 301
__serio_register_port 2 135017 67508 0
</pre>

=== kft nested call trace with 'kd -c' ===
Below is a <code>kd -c</code> trace of the data from a log taken from a PPC440g platform, from a (dynamic) trace of the function do_fork().

Here is the configuration file that was used:
<code>new
begin
trigger start entry do_fork
trigger stop exit do_fork
end
</code>

Here is the first part of the trace in nested call format:
Times (Entry, Duration and Local) are in micro-seconds. Note the timer interrupt during the routine.
<code>
Entry Duration Local Pid Trace
4 20428 209 33 do_fork
7 6 6 33 | alloc_pidmap
18 2643 84 33 | copy_process
21 114 19 33 | | dup_task_struct
24 8 6 33 | | | prepare_to_copy
27 2 2 33 | | | | sub_preempt_count
35 22 9 33 | | | kmem_cache_alloc
38 2 2 33 | | | | __might_sleep
43 11 9 33 | | | | cache_alloc_refill
49 2 2 33 | | | | | sub_preempt_count
60 65 6 33 | | | __get_free_pages
63 59 14 33 | | | | __alloc_pages
65 3 3 33 | | | | | __might_sleep
71 3 3 33 | | | | | zone_watermark_ok
77 37 17 33 | | | | | buffered_rmqueue
80 4 4 33 | | | | | | __rmqueue
86 3 3 33 | | | | | | sub_preempt_count
92 3 3 33 | | | | | | bad_range
98 2 2 33 | | | | | | __mod_page_state
103 8 5 33 | | | | | | prep_new_page
106 3 3 33 | | | | | | | set_page_refs
117 2 2 33 | | | | | zone_statistics
141 25 4 33 | | do_posix_clock_monotonic_gettime
143 21 6 33 | | | do_posix_clock_monotonic_get
146 15 6 33 | | | | do_posix_clock_monotonic_gettime_parts
149 9 6 33 | | | | | getnstimeofday
152 3 3 33 | | | | | | do_gettimeofday
169 3 3 33 | | copy_semundo
174 41 17 33 | | copy_files
177 19 9 33 | | | kmem_cache_alloc
180 2 2 33 | | | | __might_sleep
185 8 5 33 | | | | cache_alloc_refill
188 3 3 33 | | | | | sub_preempt_count
200 3 3 33 | | | count_open_files
209 2 2 33 | | | sub_preempt_count
218 19 8 33 | | kmem_cache_alloc
220 2 2 33 | | | __might_sleep
225 9 6 33 | | | cache_alloc_refill
229 3 3 33 | | | | sub_preempt_count
241 2 2 33 | | sub_preempt_count
246 216 9 33 | | kmem_cache_alloc
249 199 199 33 | | | __might_sleep
!!!! start
253 151 63 33 timer_interrupt
256 8 6 -1 ! profile_tick
259 2 2 -1 ! ! profile_hit
267 61 15 -1 ! update_process_times
270 8 5 -1 ! ! account_system_time
273 3 3 -1 ! ! ! update_mem_hiwater
281 8 5 -1 ! ! run_local_timers
284 3 3 -1 ! ! ! raise_softirq
293 27 16 -1 ! ! scheduler_tick
.
.
.
</code>

To see the full trace, go to the [[KftDoForkTrace]] page.

[[Category:Boot Time]]
[[Category:Kernel Function Trace]]

Events

2008-06-11T23:53:55Z

TimBird: /* Past events */

== Upcoming events ==
* Regional conference in Japan - Tokyo, Japan, July 4, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree21 Japan Technical Jamboree 21]
* Ottawa Linux Symposium 2008 - Ottawa, Canada, July 23-26
** Home page: http://www.linuxsymposium.org/2008/
* Embedded Linux Conference Europe - Ede, The Netherlands, November 6-7, 2008
** Home page - http://www.embeddedlinuxconference.com/elc_europe08/index.html
** Call for Presentations - http://tree.celinuxforum.org/CelfPubWiki/ELCE2008CallForPresentations

== Past events ==
Some information is at: [[Embedded linux events]]

Here is a list of past CELF events:
* Regional conference in Japan - Tokyo, Japan, April 25, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree20 Japan Technical Jamboree 20]
* Embedded Linux Conference, 2008 - Mountain View, California, USA, April 15-17, 2008
** Home page: http://www.embeddedlinuxconference.com/
** [http://tree.celinuxforum.org/CelfPubWiki/ELC2008CallForPresentations Call for sessions]
* Regional conference in Japan - Tokyo, Japan, February 21, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree19 Japan Technical Jamboree 19]
* Regional conference in Korea - Seoul, Japan, February 22, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree2 Korean Technical Jamboree 2]
* Regional conference in Japan - Tokyo, Japan, December 21, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree18 Japan Technical Jamboree 18]
*[http://www.celinux.org/elc2008/index.html Embedded Linux Conference - 2008] - Mountain View, California, USA, April 15-17, 2008
*[http://www.celinux.org/elc_europe07/elc_europe_index.html Embedded Linux Conference - Europe 2007] - Linz, Austria, November 2-4, 2007
** Presentations are being collected at: [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations ELC Europe 2007 Presentations]
* Regional conference in Japan - Tokyo, Japan, October 25, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree17 Japan Technical Jamboree 17]
*Regional conference in Japan - Tokyo, Japan, August 31, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree16 Japan Technical Jamboree 16]
*Ottawa Linux Symposium 2007 - Ottawa, Canada, June 27-30, 2007
** [[Ottawa Linux Symposium 2007]]
** [[OLS 2007 Embedded Linux BOF]] - June 27
** [[OLS 2007 Embedded Linux Wiki BOF]] - June 27
** [[OLS 2007 CELF BOF]] - June 29, 7-9pm, Westin Hotel
*Regional conference in Japan - Tokyo, Japan, June 29, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree15 Japan Technical Jamboree 15]
*Embedded System Expo & Conference in Japan - Tokyo, Japan, May 16-18
*Regional conference in Japan - Tokyo, Japan, April 27, 2007 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree14 Japan Technical Jamboree 14]
* Embedded Linux Conference, 2007 - San Jose, California, April 17-19, 2007 [http://www.celinux.org/elc2007/index.html ELC 2007]
** Presentations are available at http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations
*Regional conference in Japan - Tokyo, Japan, February 22, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree13 Japan Technical Jamboree 13]
*Regional conference in Japan - Tokyo, Japan, December 8, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree12 Japan Technical Jamboree 12]
*Embedded Technology 2006 - Yokohama, Japan, November 15..17,
*Regional conference in Japan - Tokyo, Japan, October 27, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree11 Japan Technical Jamboree 11]
*Regional conference in Japan - Tokyo, Japan, August 25, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree10 Japan Technical Jamboree 10]
*GNOME Embedded and Mobile (GMAE) forum first meetting at Guadec 2006 in Villanova, Spain. Have a look at the report: {{pdf|Gmae-report-for-celf-2006-08-10.pdf|GMAE Report}}
*Ottawa Linux Symposium 2006 - Ottawa, Canada, July 19-22, 2006
** We had a great time in Ottawa! See the following pages for more information:
** [[Ottawa Linux Symposium 2006]]
** [http://tree.celinuxforum.org/CelfPubWiki/OLS2006Demos OLS 2006 CELF Demos]
*Regional conference in Japan - Tokyo, Japan, July 13, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree9 Japan Technical Jamboree 9]
*Regional conference in Japan - Tokyo, Japan, May 26, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree8 Japan Technical Jamboree 8]
*CELF Embedded Linux Conference - San Jose, California, April 11-12, 2006 - [http://www.celinux.org/elc2006/index.html elc2006]
**Presentations from the conference are being collected at: [[ELC 2006 Presentations]]
*Regional conference in Japan - Tokyo, Japan, March 24, 2006 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree7 Japan Technical Jamboree 7]
*Regional conference in Japan - Tokyo, Japan, January 20, 2006 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree6 Japan Technical Jamboree 6]
*Regional conference in Japan - Tokyo, Japan, November 25, 2005 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree5 Japan Technical Jamboree 5]
*Regional conference in Japan - Tokyo, Japan, September 30, 2005 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree4 Japan Technical Jamboree 4]
*Ottawa Linux Symposium - Ottawa, Canada, July 20-23 - [http://www.linuxsymposium.org/ OLS]
**CELF was a sponsor again this year for the Ottawa Linux Symposium. We were permitted to show some demos at the event. CELF held a Birds-of-a-Feather (BOF) session on embedded Linux. Also, CELF handed out some prizes at the final address.
*Regional conference in Japan - Tokyo, Japan, July 15, 2005 [[Japan Technical Jamboree 3]]
*International technical conference - Yokohama, Japan, June 2005 [[International Technical Jamboree]]
*Regional conference in Korea - Seoul, Korea, May 14, 2005 - [[CELF Korea Tech Conference]]
*Linux Conf Australia - Canberra, Australia, April 18, 2005
**A few individuals attended, and Tim put up a poster of bootup-time results
*CELF Worldwide Technical Conference - San Jose, January 25, 26, 2005
**Conference program: [http://tree.celinuxforum.org/CelfPubWiki/TechnicalConference2005 CELF Technical Conference 2005]
**Presentations from various sessions: [http://tree.celinuxforum.org/CelfPubWiki/TechConference2005Docs Tech Conference 2005 Docs]
*Regional conference in Japan - December, 2004 - [[Japan Technical Jamboree 2]]
*Regional conference in Japan - October, 2004 - [[Japan Technical Jamboree]]
*Ottawa Linux Symposium, July 2004 - Tim gave a talk, and CELF held a BOF and gave out prizes
**see [http://www.linuxsymposium.org/proceedings/reprints/Reprint-Bird-OLS2004.pdf OLS2004]

== Links to Papers from other events ==
*Fosdem 2005 embedded kernel papers - [http://www.embedded-kernel-track.org/2005/papers.html FOSDEM]
*Ottawa Linux Symposium proceedings - [http://www.linuxsymposium.org/proceedings.php OLS]
** OLS 2007 - broken out paper links - https://ols2006.108.redhat.com/2007/Reprints/
*OLS proceedings collected on kernel.org - http://kernel.org/doc/ols/
[[Category:Events]]

Events

2008-06-11T23:53:35Z

TimBird: /* Upcoming events */ add ELCE 2008

== Upcoming events ==
* Regional conference in Japan - Tokyo, Japan, July 4, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree21 Japan Technical Jamboree 21]
* Ottawa Linux Symposium 2008 - Ottawa, Canada, July 23-26
** Home page: http://www.linuxsymposium.org/2008/
* Embedded Linux Conference Europe - Ede, The Netherlands, November 6-7, 2008
** Home page - http://www.embeddedlinuxconference.com/elc_europe08/index.html
** Call for Presentations - http://tree.celinuxforum.org/CelfPubWiki/ELCE2008CallForPresentations

== Past events ==
Some information is at: [[Embedded linux events]]

Here is a list of CELF events:
* Regional conference in Japan - Tokyo, Japan, April 25, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree20 Japan Technical Jamboree 20]
* Embedded Linux Conference, 2008 - Mountain View, California, USA, April 15-17, 2008
** Home page: http://www.embeddedlinuxconference.com/
** [http://tree.celinuxforum.org/CelfPubWiki/ELC2008CallForPresentations Call for sessions]
* Regional conference in Japan - Tokyo, Japan, February 21, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree19 Japan Technical Jamboree 19]
* Regional conference in Korea - Seoul, Japan, February 22, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree2 Korean Technical Jamboree 2]
* Regional conference in Japan - Tokyo, Japan, December 21, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree18 Japan Technical Jamboree 18]
*[http://www.celinux.org/elc2008/index.html Embedded Linux Conference - 2008] - Mountain View, California, USA, April 15-17, 2008
*[http://www.celinux.org/elc_europe07/elc_europe_index.html Embedded Linux Conference - Europe 2007] - Linz, Austria, November 2-4, 2007
** Presentations are being collected at: [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations ELC Europe 2007 Presentations]
* Regional conference in Japan - Tokyo, Japan, October 25, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree17 Japan Technical Jamboree 17]
*Regional conference in Japan - Tokyo, Japan, August 31, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree16 Japan Technical Jamboree 16]
*Ottawa Linux Symposium 2007 - Ottawa, Canada, June 27-30, 2007
** [[Ottawa Linux Symposium 2007]]
** [[OLS 2007 Embedded Linux BOF]] - June 27
** [[OLS 2007 Embedded Linux Wiki BOF]] - June 27
** [[OLS 2007 CELF BOF]] - June 29, 7-9pm, Westin Hotel
*Regional conference in Japan - Tokyo, Japan, June 29, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree15 Japan Technical Jamboree 15]
*Embedded System Expo & Conference in Japan - Tokyo, Japan, May 16-18
*Regional conference in Japan - Tokyo, Japan, April 27, 2007 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree14 Japan Technical Jamboree 14]
* Embedded Linux Conference, 2007 - San Jose, California, April 17-19, 2007 [http://www.celinux.org/elc2007/index.html ELC 2007]
** Presentations are available at http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations
*Regional conference in Japan - Tokyo, Japan, February 22, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree13 Japan Technical Jamboree 13]
*Regional conference in Japan - Tokyo, Japan, December 8, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree12 Japan Technical Jamboree 12]
*Embedded Technology 2006 - Yokohama, Japan, November 15..17,
*Regional conference in Japan - Tokyo, Japan, October 27, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree11 Japan Technical Jamboree 11]
*Regional conference in Japan - Tokyo, Japan, August 25, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree10 Japan Technical Jamboree 10]
*GNOME Embedded and Mobile (GMAE) forum first meetting at Guadec 2006 in Villanova, Spain. Have a look at the report: {{pdf|Gmae-report-for-celf-2006-08-10.pdf|GMAE Report}}
*Ottawa Linux Symposium 2006 - Ottawa, Canada, July 19-22, 2006
** We had a great time in Ottawa! See the following pages for more information:
** [[Ottawa Linux Symposium 2006]]
** [http://tree.celinuxforum.org/CelfPubWiki/OLS2006Demos OLS 2006 CELF Demos]
*Regional conference in Japan - Tokyo, Japan, July 13, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree9 Japan Technical Jamboree 9]
*Regional conference in Japan - Tokyo, Japan, May 26, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree8 Japan Technical Jamboree 8]
*CELF Embedded Linux Conference - San Jose, California, April 11-12, 2006 - [http://www.celinux.org/elc2006/index.html elc2006]
**Presentations from the conference are being collected at: [[ELC 2006 Presentations]]
*Regional conference in Japan - Tokyo, Japan, March 24, 2006 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree7 Japan Technical Jamboree 7]
*Regional conference in Japan - Tokyo, Japan, January 20, 2006 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree6 Japan Technical Jamboree 6]
*Regional conference in Japan - Tokyo, Japan, November 25, 2005 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree5 Japan Technical Jamboree 5]
*Regional conference in Japan - Tokyo, Japan, September 30, 2005 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree4 Japan Technical Jamboree 4]
*Ottawa Linux Symposium - Ottawa, Canada, July 20-23 - [http://www.linuxsymposium.org/ OLS]
**CELF was a sponsor again this year for the Ottawa Linux Symposium. We were permitted to show some demos at the event. CELF held a Birds-of-a-Feather (BOF) session on embedded Linux. Also, CELF handed out some prizes at the final address.
*Regional conference in Japan - Tokyo, Japan, July 15, 2005 [[Japan Technical Jamboree 3]]
*International technical conference - Yokohama, Japan, June 2005 [[International Technical Jamboree]]
*Regional conference in Korea - Seoul, Korea, May 14, 2005 - [[CELF Korea Tech Conference]]
*Linux Conf Australia - Canberra, Australia, April 18, 2005
**A few individuals attended, and Tim put up a poster of bootup-time results
*CELF Worldwide Technical Conference - San Jose, January 25, 26, 2005
**Conference program: [http://tree.celinuxforum.org/CelfPubWiki/TechnicalConference2005 CELF Technical Conference 2005]
**Presentations from various sessions: [http://tree.celinuxforum.org/CelfPubWiki/TechConference2005Docs Tech Conference 2005 Docs]
*Regional conference in Japan - December, 2004 - [[Japan Technical Jamboree 2]]
*Regional conference in Japan - October, 2004 - [[Japan Technical Jamboree]]
*Ottawa Linux Symposium, July 2004 - Tim gave a talk, and CELF held a BOF and gave out prizes
**see [http://www.linuxsymposium.org/proceedings/reprints/Reprint-Bird-OLS2004.pdf OLS2004]

== Links to Papers from other events ==
*Fosdem 2005 embedded kernel papers - [http://www.embedded-kernel-track.org/2005/papers.html FOSDEM]
*Ottawa Linux Symposium proceedings - [http://www.linuxsymposium.org/proceedings.php OLS]
** OLS 2007 - broken out paper links - https://ols2006.108.redhat.com/2007/Reprints/
*OLS proceedings collected on kernel.org - http://kernel.org/doc/ols/
[[Category:Events]]

Embedded linux events

2008-06-11T23:24:16Z

TimBird:

Here is information about Embedded Linux-related events (conferences and symposiums)

The main conferences each year are:

* Ottawa Linux Symposium (OSL)
* LinuxConf Australia (LCA)
* Linux Kongress (now defunct?)
* FOSDEM
* Embedded Linux Conference (ELC)
* Real-time Linux Workshop (RTLWS)

Miscellaneous other conferences:
* LinuxWorld?? - embedded track?

== Links to conference proceedings ==
Here are some links to various conference proceedings:

=== OLS ===
* All the OLS papers from 2002-2007 - http://kernel.org/doc/ols

Events

2008-06-11T23:17:34Z

TimBird: /* Past events */ add events information page

== Upcoming events ==
* Regional conference in Japan - Tokyo, Japan, July 4, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree21 Japan Technical Jamboree 21]
* Ottawa Linux Symposium 2008 - Ottawa, Canada, July 23-26
** Home page: http://www.linuxsymposium.org/2008/

== Past events ==
Some information is at: [[Embedded linux events]]

Here is a list of CELF events:
* Regional conference in Japan - Tokyo, Japan, April 25, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree20 Japan Technical Jamboree 20]
* Embedded Linux Conference, 2008 - Mountain View, California, USA, April 15-17, 2008
** Home page: http://www.embeddedlinuxconference.com/
** [http://tree.celinuxforum.org/CelfPubWiki/ELC2008CallForPresentations Call for sessions]
* Regional conference in Japan - Tokyo, Japan, February 21, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree19 Japan Technical Jamboree 19]
* Regional conference in Korea - Seoul, Japan, February 22, 2008 - [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree2 Korean Technical Jamboree 2]
* Regional conference in Japan - Tokyo, Japan, December 21, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree18 Japan Technical Jamboree 18]
*[http://www.celinux.org/elc2008/index.html Embedded Linux Conference - 2008] - Mountain View, California, USA, April 15-17, 2008
*[http://www.celinux.org/elc_europe07/elc_europe_index.html Embedded Linux Conference - Europe 2007] - Linz, Austria, November 2-4, 2007
** Presentations are being collected at: [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations ELC Europe 2007 Presentations]
* Regional conference in Japan - Tokyo, Japan, October 25, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree17 Japan Technical Jamboree 17]
*Regional conference in Japan - Tokyo, Japan, August 31, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree16 Japan Technical Jamboree 16]
*Ottawa Linux Symposium 2007 - Ottawa, Canada, June 27-30, 2007
** [[Ottawa Linux Symposium 2007]]
** [[OLS 2007 Embedded Linux BOF]] - June 27
** [[OLS 2007 Embedded Linux Wiki BOF]] - June 27
** [[OLS 2007 CELF BOF]] - June 29, 7-9pm, Westin Hotel
*Regional conference in Japan - Tokyo, Japan, June 29, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree15 Japan Technical Jamboree 15]
*Embedded System Expo & Conference in Japan - Tokyo, Japan, May 16-18
*Regional conference in Japan - Tokyo, Japan, April 27, 2007 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree14 Japan Technical Jamboree 14]
* Embedded Linux Conference, 2007 - San Jose, California, April 17-19, 2007 [http://www.celinux.org/elc2007/index.html ELC 2007]
** Presentations are available at http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations
*Regional conference in Japan - Tokyo, Japan, February 22, 2007 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree13 Japan Technical Jamboree 13]
*Regional conference in Japan - Tokyo, Japan, December 8, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree12 Japan Technical Jamboree 12]
*Embedded Technology 2006 - Yokohama, Japan, November 15..17,
*Regional conference in Japan - Tokyo, Japan, October 27, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree11 Japan Technical Jamboree 11]
*Regional conference in Japan - Tokyo, Japan, August 25, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree10 Japan Technical Jamboree 10]
*GNOME Embedded and Mobile (GMAE) forum first meetting at Guadec 2006 in Villanova, Spain. Have a look at the report: {{pdf|Gmae-report-for-celf-2006-08-10.pdf|GMAE Report}}
*Ottawa Linux Symposium 2006 - Ottawa, Canada, July 19-22, 2006
** We had a great time in Ottawa! See the following pages for more information:
** [[Ottawa Linux Symposium 2006]]
** [http://tree.celinuxforum.org/CelfPubWiki/OLS2006Demos OLS 2006 CELF Demos]
*Regional conference in Japan - Tokyo, Japan, July 13, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree9 Japan Technical Jamboree 9]
*Regional conference in Japan - Tokyo, Japan, May 26, 2006 - [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree8 Japan Technical Jamboree 8]
*CELF Embedded Linux Conference - San Jose, California, April 11-12, 2006 - [http://www.celinux.org/elc2006/index.html elc2006]
**Presentations from the conference are being collected at: [[ELC 2006 Presentations]]
*Regional conference in Japan - Tokyo, Japan, March 24, 2006 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree7 Japan Technical Jamboree 7]
*Regional conference in Japan - Tokyo, Japan, January 20, 2006 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree6 Japan Technical Jamboree 6]
*Regional conference in Japan - Tokyo, Japan, November 25, 2005 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree5 Japan Technical Jamboree 5]
*Regional conference in Japan - Tokyo, Japan, September 30, 2005 [http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree4 Japan Technical Jamboree 4]
*Ottawa Linux Symposium - Ottawa, Canada, July 20-23 - [http://www.linuxsymposium.org/ OLS]
**CELF was a sponsor again this year for the Ottawa Linux Symposium. We were permitted to show some demos at the event. CELF held a Birds-of-a-Feather (BOF) session on embedded Linux. Also, CELF handed out some prizes at the final address.
*Regional conference in Japan - Tokyo, Japan, July 15, 2005 [[Japan Technical Jamboree 3]]
*International technical conference - Yokohama, Japan, June 2005 [[International Technical Jamboree]]
*Regional conference in Korea - Seoul, Korea, May 14, 2005 - [[CELF Korea Tech Conference]]
*Linux Conf Australia - Canberra, Australia, April 18, 2005
**A few individuals attended, and Tim put up a poster of bootup-time results
*CELF Worldwide Technical Conference - San Jose, January 25, 26, 2005
**Conference program: [http://tree.celinuxforum.org/CelfPubWiki/TechnicalConference2005 CELF Technical Conference 2005]
**Presentations from various sessions: [http://tree.celinuxforum.org/CelfPubWiki/TechConference2005Docs Tech Conference 2005 Docs]
*Regional conference in Japan - December, 2004 - [[Japan Technical Jamboree 2]]
*Regional conference in Japan - October, 2004 - [[Japan Technical Jamboree]]
*Ottawa Linux Symposium, July 2004 - Tim gave a talk, and CELF held a BOF and gave out prizes
**see [http://www.linuxsymposium.org/proceedings/reprints/Reprint-Bird-OLS2004.pdf OLS2004]

== Links to Papers from other events ==
*Fosdem 2005 embedded kernel papers - [http://www.embedded-kernel-track.org/2005/papers.html FOSDEM]
*Ottawa Linux Symposium proceedings - [http://www.linuxsymposium.org/proceedings.php OLS]
** OLS 2007 - broken out paper links - https://ols2006.108.redhat.com/2007/Reprints/
*OLS proceedings collected on kernel.org - http://kernel.org/doc/ols/
[[Category:Events]]

System Size

2008-06-11T23:10:40Z

TimBird: add runtime size information

Here are some links to information and projects related to Linux system size.

== Technologies for decreasing system size ==
=== Kernel size reduction ===
==== Configuration Options ====
* [[Kernel Size Tuning Guide]] - document about measuring kernel size and configuring the kernel for smallest size

==== The Linux-tiny patchset ====
* The [[Linux Tiny]] patch set is a collection of patches which can be used to make the Linux kernel consume less space. The long-term goal of the Linux-tiny project is to mainline these patches. Several patches have been mainlined over the last few years, and work continues in this area.

==== Compiler options for reducing kernel size ====
An LWN article talks about three gcc options to shrink the kernel.

[http://lwn.net/Articles/67175/ Shrinking the Kernel with GCC]

The first option is -Os which is already in the tiny kernel patch.

The second option is new in gcc 3.4, -funit-at-a-time. This apparently makes gcc
do a much better job of inlining and dead code removal. It reduces the
size of both text and data. It depends on another inlining patch that I
think is in the tiny kernel patch (maybe same idea but different details).

The third option, -mregparm=3, seems to be x86 specific, it instructs the
compiler to use registers for the first three function arguments. by John Rigby

==== Runtime size of kernel ====
Often, the focus of memory size reduction for the kernel is on the size of the
statically compiled image for the kernel. However, the kernel also allocates
memory dynamically when it runs. On loading, the kernel creates several tables
for things like network and file system structures.

Here is a table showing different kernel hash tables, and their approximate
size for a 2.6 kernel. (Table taken from page 25 of
http://logfs.org/~joern/data_structures.pdf )

{| border="1" cellspacing="0" cellpadding="5" align="center"
!Hash Table !!memory < 512MiB RAM !! memory >=512MiB RAM
|-
! !!32b/64b !!32b/64b
|-
|TCP established ||96k/192k ||384k/768k
|-
|TCP bind || 64k/128k || 256k/512k
|-
|IP route cache || 128k/256k || 512k/1M
|-
|Inode-cache || 64k/128k || 64k/128k
|-
|Dentry cache || 32k/64k || 32k/64k
|-
||Total || 384k/768k || 1248k/2496k
|}

=== File system compression ===
For read-only data, it is useful to utilize a compressed file system.
The following are used heavily in embedded systems:
* JFFS2
* Cramfs
* SquashFS

See the [[File Systems]] page for more information.

=== Library savings ===
==== Use of a smaller libc ====
Glibc is the default C library used for Linux systems. Glibc is about 2 meg. in size. Other C libraries
are also available for Linux, and they offer varying degrees of compatibility and size savings.
In general, uClibc is considered a very good alternative to glibc, for systems where size is an issue.

* [http://uclibc.org/ uClibc] - small footprint but complete C library
* [http://www.fefe.de/dietlibc/ dietlibc] - another library to produce very small statically compiled executables.
* [http://www.kernel.org/pub/linux/libs/klibc/ klibc] - very small library for use in init ram filesystems
* Subset Libc Specification - CELF once considered the possibility of creating a subset libc specification. Some companies have also examined the possibility of modularizing glibc, so that parts of it can be made configurable. Preliminary research indicates that this could be a very difficult thing, since glibc has very messy function interdependencies.

==== Static Linking ====
If your set of applications is small, sometimes it makes more sense to statically link
your applications than to use shared libraries. Shared libraries by default include all
symbols (functions and data structures) for the features a library provides. However, when
you static link a program to a library, only the symbols that are actually referenced
are linked in and included in the program.

==== Library reduction ====
It is possible to reduce the size of shared libraries, by eliminating unused symbols.

MontaVista released a tool for library optimization. This tool scans the entire file system,
and can rebuild the shared libraries for the system, including only the symbols needed for
the set of applications in the indicated file system.

Care needs to be taken with this approach, since it may make it difficult to use add-on
programs or or do in-field upgrades (since symbols required by the new software may not
be present in the optimized libraries). But for some fixed-function devices, this can
reduce your library footprint dramatically.

See http://libraryopt.sourceforge.net/

==== Deferred Library Loading ====
It is possible to reduce the RAM runtime footprint for a product, by lazily loading shared
libraries, and by breaking up library dependencies. Panasonic did some research into
a process called Deferred Library Loading, which they presented at ELC 2007.

See the [http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations?action=AttachFile&do=get&target=DefferdDynamicLoading_20070417.pdf Deferred Dynamic Loading] presentation.

=== Execute-in-place ===
You can save RAM memory by using some text or data directly from flash.

==== Kernel XIP ====
By executing the kernel in-place from flash, it is possible to save RAM space.
*see [[Kernel XIP]]

==== Application XIP ====
By executing applications in-place from flash, it is possible to save RAM space.
*see [[Application XIP]]

==== Data Read In Place (DRIP) ====
This is a technique for keeping data in flash, until it is written to, and then
making a RAM page for it.
*see [[Data Read In Place]]

== Size measurement tools and techniques ==
=== Kernel size measurement data ===
* [http://testlab.celinuxforum.org/bloatwatch/index.cgi Bloatwatch] - a kernel size regression analysis tool.
** Bloatwatch provides a great amount of detail, and the ability to compare the size of kernel versions over time. The range of kernels covered is from 2.6.12-rc2 to 2.6.17-rc1. Unfortunately, the system to
collect kernels and test them broke about the time of 2.6.17, and the system stopped operating at that time.
** If you have interest in reviving this tool to make it operational again, please contact [[User:Tim Bird]]. [[CELF]] has some contract money earmarked for this project.

=== How to measure the kernel image size ===
*to see the size of the major kernel sections (code and data):
:<code><nowiki>size vmlinux */built-in.o</nowiki></code>
<pre><nowiki>
[tbird@crest ebony]$ size vmlinux */built-in.o
text data bss dec hex filename
2921377 369712 132996 3424085 343f55 vmlinux
764472 35692 22768 822932 c8e94 drivers/built-in.o
918344 22364 36824 977532 eea7c fs/built-in.o
18260 1868 1604 21732 54e4 init/built-in.o
39960 864 224 41048 a058 ipc/built-in.o
257292 14656 34516 306464 4ad20 kernel/built-in.o
34728 156 2280 37164 912c lib/built-in.o
182312 2704 736 185752 2d598 mm/built-in.o
620864 20820 26676 668360 a32c8 net/built-in.o
1912 0 0 1912 778 security/built-in.o
133 0 0 133 85 usr/built-in.o
</nowiki></pre>
*to see the size of the largest kernel symbols:
** <code><nowiki>nm --size -r vmlinux</nowiki></code>
<pre><nowiki>
[tbird@crest ebony]$ nm --size -r vmlinux | head -10
00008000 b read_buffers
00004000 b __log_buf
00003100 B ide_hwifs
000024f8 T jffs2_garbage_collect_pass
00002418 T journal_commit_transaction
00002400 b futex_queues
000021a8 t jedec_probe_chip
00002000 b write_buf
00002000 D init_thread_union
00001e6c t tcp_ack
</nowiki></pre>

=== How to measure the memory usage at runtime ===
See [[Runtime Memory Measurement]] for a description of ways to measure runtime memory usage in Linux.

Also, see [[Accurate Memory Measurement]] for a description of techniques (and patches) which can be used to measure the runtime memory more accurately.

=== Linux size increase from 2.4 to 2.6 ===
Linux increased in size by between 10% and 30% from version 2.4 to 2.6. This incremental growth in kernel size has been a big concern by forum members.

Please see the [[Szwg Linux 26Data]] page for supporting data.

=== GCC Code-Size Benchmarking ===
CSiBE is a code size benchmark for the GCC compiler. The primary purpose of CSiBE is to monitor the size of the code generated by GCC. In addition, compilation time and code performance measurements are also provided.

[http://www.inf.u-szeged.hu/csibe/ CSiBE]

== Case Studies ==
* Motorola reduction of system size (presumably for cell phones) using 2.4 Linux: MotSizeReduction.ppt - this is a placeholder for this Powerpoint as it was too big to upload to the wiki. Email btraynor at gmail.com if you need it immediately.

== Other Tidbits on System Size ==
=== Memory leak detection for the kernel ===
Catalin Marinas of ARM has been recently (as of 2.6.17?) been posting a memory leak detector for the Linux kernel. It may get mainlined in the future. Here's a link to the LKML discussions around it: http://lkml.org/lkml/2006/6/11/39

=== How System Size may affect performance ===
It has long been theorized that reducing system size could provide a performance benefit
because it could reduce cache misses. There does not appear to be hard data to support
this theory on Linux, but this has been discussed on the kernel mailing list.

See [http://groups.google.com/group/linux.kernel/msg/e1f9f579a946333e?hl=en& this post by Linus Torvalds]

[[Category:System Size]]

Power Management

2008-06-04T23:19:52Z

TimBird: add links to PM presentations from recent CELF conferences

This page has information about Power Management for Linux. Power Management exists because many products are handheld or mobile, and consumers are interested in using their products for as long as possible on a single battery charge.

== Power Management Technology/Project pages ==
* http://www.lesswatts.org/index.php - LessWatts.org
** LessWatts.org is about how you can save real watts, however you use Linux on your computer or computers.
** LessWatts is about creating a community around saving power on Linux, bringing developers, users, and sysadmins together to share software, optimizations, and tips and tricks.

== CELF Standards ==
See here [http://tree.celinuxforum.org/pubwiki/moin.cgi/CELFPmRequirements2006 CELF PM Requirements 2006]

== Documents ==
*Mapping of ACPI states to omap power states: {{pdf|Acpi-to-omap2-mapping.pdf|ACPI to OMAP2 Mapping}}

For some good overviews of different PM features relevant to embedded,
you may want to look at the following papers:

Every Microamp is Sacred - A Dynamic Voltage and Current Control
Interface for the Linux Kernel - Liam Girdwood
http://www.celinux.org/elc08_presentations/regulator-api-celf.pdf

Power Management Quality of Service and How You Could Use it in
Your Embedded Application - Mark Gross
http://www.celinux.org/elc08_presentations/elc2008_pm_qos_slides.pdf

Building Blocks for Embedded Power Management - Kevin Hilman
http://www.celinux.org/elc08_presentations/PM_Building_Blocks1.pdf

Linux Suspend-to-Disk Objectives for Consumer Electronic Devices -
Vitaly Wool
http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=view&target=std.pdf

Linux Clock Management Framework - Siarhei Yermalayeu
http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=view&target=ELC_2007_Linux_clock_fmw.pdf

== Open Source Projects/Mailing Lists ==
*[https://lists.osdl.org/mailman/listinfo/linux-pm linux-pm] mailing list (and list [http://lists.osdl.org/pipermail/linux-pm/ archives]).
*[http://dynamicpower.sourceforge.net Dynamic Power] at sourceforge.

[[Category:Power Management]]

File:Linux-tiny-revival-jamboree16.pdf

2007-09-19T17:56:19Z

TimBird: Presentation by Tim Bird for CELF Japan Technical Jamboree #16, describing the revival of the Linux-tiny project.

Presentation by Tim Bird for CELF Japan Technical Jamboree #16, describing the revival of the Linux-tiny project.

Linux Tiny

2007-09-19T17:54:57Z

TimBird: /* Resources */ add presentation from Jamboree 16

== Introduction ==
The linux-tiny patchset is a series of patches against the 2.6 mainline Linux kernel to reduce its memory
and disk footprint, as well as to add features to aid working on small systems. Target users are
developers of embedded system and users of small or legacy machines such as 386s and handhelds.

To the degree possible, the patchset should serve as a staging ground for patches, until they can
be mainlined. Therefore, over time the set of patches in the set will fluctuate as new patches
are submitted, and other patches are mainlined.

== Resources ==
* Project home page: [http://www.selenic.com/tiny-about/ Linux Tiny]
* Project mailing list: [http://selenic.com/mailman/listinfo/linux-tiny Mailing List]
* A Linux Weekly News article about the project is at: [http://lwn.net/Articles/63516/ LWN Article (Dec 2003)]
* [[Image:Alert.gif]] [http://tree.celinuxforum.org/CelfPubWiki/TechConference2005Docs?action=AttachFile&do=get&target=linux-tiny.pdf Linux-tiny Presentation] by Matt Mackall, delivered at CELF's Technical Conference in April 2005.
* {{pdf|Linux-tiny-revival-jamboree16.pdf|Linux-tiny revival}} presentation given by Tim Bird at the Japan Technical Jamboree #16 in August 2007
** This presentation describes the current status of the Linux-tiny patches, describes the improved memory accounting feature, gives some size number for various config options, and describes the project revival effort.

== Original Announcements and e-mail ==
The original (Dec 11, 2003) announcement about the patchset, to the kernel mailing list, is available here:
* [http://lwn.net/Articles/62858/ Announcement]

Here are some other announcements from Matt Mackall to LKML:
*[http://www.ussg.iu.edu/hypermail/linux/kernel/0312.3/0454.html 2.6.0-tiny1 Dec 27, 2003]
*[http://www.ussg.iu.edu/hypermail/linux/kernel/0401.0/0403.html 2.6.1-rc1-tin1 Jan 2, 2004]
*[http://www.ussg.iu.edu/hypermail/linux/kernel/0401.0/1256.html 2.6.1-rc1-tiny2 Jan 6, 2004]

Recent discussion thread on lkml is summarized at: [http://kt.zork.net/kernel-traffic/latest.html#6 LKML Thread Summary]
The thread is available at [http://www.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=19Kuz-872-3%40gated-at.bofh.it&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D19Kuz-872-3%2540gated-at.bofh.it here]

Note that currently, the smallest kernel that is reported in this thread is 197K compressed.

== Download ==
=== Last release (for 2.6.22.5) ===
A recent Linux-tiny patchset release is available here: [[Media:Tiny-quilt-2.6.22.5-1.tar.gz]]

=== Installation Instructions ===
These instructions were for the Linux-tiny release for 2.6.22.5. Adjust accordingly
for a different kernel version.

To apply the above patches, you need the referenced kernel (2.6.22) and quilt.
Follow these steps:
* wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.tar.bz2
* tar -xjf linux-2.6.22.tar.bz2
* wget http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.22.5.bz2
* wget http://elinux.org/images/7/79/Tiny-quilt-2.6.22.5-1.tar.gz
* cd linux-2.6.22
* bzcat ../patch-2.6.22.5.bz2 | patch -p1
* tar -xzf ../Tiny-quilt-2.6.22-5-1.tar.gz
* quilt push -a
* cd ..
* mv linux-2.6.22 linux-2.6.22.5-tiny1

=== Auxiliary tools ===
Here is a short shell script for making a tiny-quilt release: [[Media:release-tiny]]

=== Older releases ===

* Linux 2.6.22.1:
** [[Media:Tiny-quilt-2.6.22.1-1.tar.gz]]
* Linux 2.6.16.19
** broken-out patchset: [[Media:2.6.16.19-tiny1-broken-out.tar.bz2|2.6.16.19-tiny1-broken-out]]
** Porting notes: [[Media:linuxtinyNOTES.txt|notes]]
* Linux 2.6.0 to 2.6.14:
** Older Linux-tiny patchsets can be downloaded from: [http://selenic.com/tiny/ Linux Tiny Patchset]

== Test Project and Results ==
The CELF System Size working group has worked extensively with the Linux-tiny patch set. There is a script to produce a report of size reductions for the individual patches
in the patchset, and results from various vendors about their use of Linux-tiny. See [[Linux Tiny Test Project]]

There are some miscellaneous usage notes at: [[Linux Tiny Notes]]

== License ==
The Linux-tiny patches apply against the Linux kernel, and are provided under the GNU General
Public License (GPL), version 2 only [http://www.fsf.org/licensing/licenses/info/GPLv2.html]. (This is the same license as the Linux kernel.)

[[Category: Linux Tiny]]

Vendors

2007-09-11T15:28:06Z

TimBird: /* Overview */ add japan as country for lineo solutions

== Overview ==

This page lists companies who offer services around embedded Linux, such as training, support, etc. We also list companies who provide Linux distributions specifically targeting embedded uses. If you are looking for companies who build and sell devices with Linux as their operating system, please see the [[Companies]] page.

* [http://www.katdc.com KAT Digital Corp.]
* [http://www.sidebranch.com Sidebranch], The Netherlands.
* [http://www.mvista.com/ MontaVista]
* [http://www.timesys.com/ TimeSys]
* [http://www.windriver.com/ Wind River]
* [http://www.linutronix.de/ Linutronix], Germany
* [http://www.lineo.co.jp/eng/index.html Lineo Solutions], Japan
* [http://www.denx.de/ DENX Software Engineering]
* [http://www.drivingdevices.com/ Driving Devices Limited], United Kingdom

Linux Tiny

2007-09-06T11:58:14Z

TimBird: add license note

== Introduction ==
The linux-tiny patchset is a series of patches against the 2.6 mainline Linux kernel to reduce its memory
and disk footprint, as well as to add features to aid working on small systems. Target users are
developers of embedded system and users of small or legacy machines such as 386s and handhelds.

== Resources ==
* Project home page: [http://www.selenic.com/tiny-about/ Linux Tiny]
* Project mailing list: [http://selenic.com/mailman/listinfo/linux-tiny Mailing List]
* A Linux Weekly News article about the project is at: [http://lwn.net/Articles/63516/ LWN Article]
* [[Image:Alert.gif]] - [http://tree.celinuxforum.org/CelfPubWiki/TechConference2005Docs?action=AttachFile&do=get&target=linux-tiny.pdf Linux-tiny Presentation] by Matt Mackall, delivered at CELF's Technical Conference in 2005.

== Original Announcements and e-mail ==
The original (Dec 11, 2003) announcement about the patchset, to the kernel mailing list, is available here:
* [http://lwn.net/Articles/62858/ Announcement]

Here are some other announcements from Matt Mackall to LKML:
*[http://www.ussg.iu.edu/hypermail/linux/kernel/0312.3/0454.html 2.6.0-tiny1 Dec 27, 2003]
*[http://www.ussg.iu.edu/hypermail/linux/kernel/0401.0/0403.html 2.6.1-rc1-tin1 Jan 2, 2004]
*[http://www.ussg.iu.edu/hypermail/linux/kernel/0401.0/1256.html 2.6.1-rc1-tiny2 Jan 6, 2004]

Recent discussion thread on lkml is summarized at: [http://kt.zork.net/kernel-traffic/latest.html#6 LKML Thread Summary]
The thread is available at [http://www.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=19Kuz-872-3%40gated-at.bofh.it&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D19Kuz-872-3%2540gated-at.bofh.it here]

Note that currently, the smallest kernel that is reported in this thread is 197K compressed.

== Download ==
=== Last release (for 2.6.22.5) ===
A recent Linux-tiny patchset release is available here: [[Media:Tiny-quilt-2.6.22.5-1.tar.gz]]

=== Installation Instructions ===
These instructions were for the Linux-tiny release for 2.6.22.5. Adjust accordingly
for a different kernel version.

To apply the above patches, you need the referenced kernel (2.6.22) and quilt.
Follow these steps:
* wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.tar.bz2
* tar -xjf linux-2.6.22.tar.bz2
* wget http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.22.5.bz2
* wget http://elinux.org/images/7/79/Tiny-quilt-2.6.22.5-1.tar.gz
* cd linux-2.6.22
* bzcat ../patch-2.6.22.5.bz2 | patch -p1
* tar -xzf ../Tiny-quilt-2.6.22-5-1.tar.gz
* quilt push -a
* cd ..
* mv linux-2.6.22 linux-2.6.22.5-tiny1

=== Auxiliary tools ===
Here is a short shell script for making a tiny-quilt release: [[Media:release-tiny]]

=== Older releases ===

* Linux 2.6.22.1:
** [[Media:Tiny-quilt-2.6.22.1-1.tar.gz]]
* Linux 2.6.16.19
** broken-out patchset: [[Media:2.6.16.19-tiny1-broken-out.tar.bz2|2.6.16.19-tiny1-broken-out]]
** Porting notes: [[Media:linuxtinyNOTES.txt|notes]]
* Linux 2.6.0 to 2.6.14:
** Older Linux-tiny patchsets can be downloaded from: [http://selenic.com/tiny/ Linux Tiny Patchset]

== Test Project and Results ==
The CELF System Size working group has worked extensively with the Linux-tiny patch set. There is a script to produce a report of size reductions for the individual patches
in the patchset, and results from various vendors about their use of Linux-tiny. See [[Linux Tiny Test Project]]

There are some miscellaneous usage notes at: [[Linux Tiny Notes]]

== License ==
The Linux-tiny patches apply against the Linux kernel, and are provided under the GNU General
Public License (GPL), version 2 only. (This is the same license as the Linux kernel.)

[[Category: Linux Tiny]]

System Size

2007-09-05T06:21:30Z

TimBird: /* SquashFS file system */

Here are some links to information and projects related to Linux system size.

== Documentation on reducing kernel size ==
[[Kernel Size Tuning Guide]] is a draft of a document on the subject of measuring and reducing the size of the Linux kernel

* [[Kernel Size Tuning Guide]]
* http://www.halobates.de/memorywaste.pdf - Great paper by Andi Kleen, of SUSE Labs, about dynamic memory usage of Linux systems

== Technologies for decreasing system size ==
=== The Linux-tiny patchset ===
* see the [[Linux Tiny]] page. There is a project to characterize the sub-patches in the Linux-tiny patchset, in order to prioritize them for porting to non-x86 architectures.
* see [[Linux Tiny Test Project]]

=== Compiler options for reducing kernel size ===
An LWN article talks about three gcc options to shrink the kernel.

[http://lwn.net/Articles/67175/ Shrinking the Kernel with GCC]

The first option is -Os which is already in the tiny kernel patch.

The second option is new in gcc 3.4, -funit-at-a-time. This apparently makes gcc
do a much better job of inlining and dead code removal. It reduces the
size of both text and data. It depends on another inlining patch that I
think is in the tiny kernel patch (maybe same idea but different details).

The third option, -mregparm=3, seems to be x86 specific, it instructs the
compiler to use registers for the first three function arguments. by John Rigby

=== compressed file system ===
For read-only data, it is useful to utilize a compressed file system. The following are used heavily in embedded systems:
*Cramfs - [should put some information or link here]
*SquashFS - see the [[Squash Fs]] page

=== Use of a smaller libc ===
*[http://uclibc.org/ uClibc] - small footprint but complete C library
*[http://www.kernel.org/pub/linux/libs/klibc/ klibc] - very small library for use in init ram filesystems
*[http://www.fefe.de/dietlibc/ dietlibc] - another library to produce very small statically compiled executables.
*Subset Libc Specification - CELF is researching the possibility of creating a subset libc specification

=== Kernel XIP ===
By executing the kernel in-place from flash, it is possible to save RAM space.
*see [[Kernel XIP]]

=== Application XIP ===
By executing applications in-place from flash, it is possible to save RAM space.
*see ApplicationXIP

=== Data Read In Place (DRIP) ===
This is a technique for keeping data in flash, until it is written to, and then
making a RAM page for it.
*see [[Data Read In Place]]

== Size measurement tools and techniques ==
=== How to measure the kernel image size ===
*to see the size of the major kernel sections (code and data):
:<code><nowiki>size vmlinux */built-in.o</nowiki></code>
<pre><nowiki>
[tbird@crest ebony]$ size vmlinux */built-in.o
text data bss dec hex filename
2921377 369712 132996 3424085 343f55 vmlinux
764472 35692 22768 822932 c8e94 drivers/built-in.o
918344 22364 36824 977532 eea7c fs/built-in.o
18260 1868 1604 21732 54e4 init/built-in.o
39960 864 224 41048 a058 ipc/built-in.o
257292 14656 34516 306464 4ad20 kernel/built-in.o
34728 156 2280 37164 912c lib/built-in.o
182312 2704 736 185752 2d598 mm/built-in.o
620864 20820 26676 668360 a32c8 net/built-in.o
1912 0 0 1912 778 security/built-in.o
133 0 0 133 85 usr/built-in.o
</nowiki></pre>
*to see the size of the largest kernel symbols:
** <code><nowiki>nm --size -r vmlinux</nowiki></code>
<pre><nowiki>
[tbird@crest ebony]$ nm --size -r vmlinux | head -10
00008000 b read_buffers
00004000 b __log_buf
00003100 B ide_hwifs
000024f8 T jffs2_garbage_collect_pass
00002418 T journal_commit_transaction
00002400 b futex_queues
000021a8 t jedec_probe_chip
00002000 b write_buf
00002000 D init_thread_union
00001e6c t tcp_ack
</nowiki></pre>

=== How to measure the memory usage at runtime ===
See [[Runtime Memory Measurement]] for a description of ways to measure runtime memory usage in Linux.

Also, see [[Accurate Memory Measurement]] for a description of techniques (and patches) which can be used to measure the runtime memory more accurately.

=== Linux size increase from 2.4 to 2.6 ===
Linux increased in size by between 10% and 30% from version 2.4 to 2.6. This incremental growth in kernel size has been a big concern by forum members.

Please see the [[Szwg Linux 26Data]] page for supporting data.

=== GCC Code-Size Benchmarking ===
CSiBE is a code size benchmark for the GCC compiler. The primary purpose of CSiBE is to monitor the size of the code generated by GCC. In addition, compilation time and code performance measurements are also provided.

[http://www.inf.u-szeged.hu/csibe/ CSiBE]

== Case Studies ==
*Motorola reduction of system size (presumably for cell phones) using 2.4 Linux: MotSizeReduction.ppt - this is a placeholder for this Powerpoint as it was too big to upload to the wiki. Email btraynor at gmail.com if you need it immediately.

== Other Tidbits on System Size ==
=== Memory leak detection for the kernel ===
Catalin Marinas of ARM has been recently (as of 2.6.17?) been posting a memory leak detector for the Linux kernel. It may get mainlined in the future. Here's a link to the LKML discussions around it: http://lkml.org/lkml/2006/6/11/39

=== How System Size may affect performance ===
It has long been theorized that reducing system size could provide a performance benefit
because it could reduce cache misses. There does not appear to be hard data to support
this theory on Linux, but this has been discussed on the kernel mailing list.

See [http://groups.google.com/group/linux.kernel/msg/e1f9f579a946333e?hl=en& this post by Linus Torvalds]

[[Category:System Size]]

RTWG-discussion-points

2007-09-04T07:40:18Z

TimBird: /* shared Test Bed ideas */

== Review of test programs ==
=== lpptest ===
problems:
* requires 2 machines
* requires parallel port (not many embedded boards have this)
* uses TSC, which is i386-specific

benefits:
* built into the rt-preempt patch
* 2-machine system gives unbiased timing results
** instrumentation does not interfere with the timings

=== realfeel ===
benefits:
* is one-machine
* uses /dev/rtc, does not use timer interrupt
** this isolates the ISR handling from timer operations
* is a very simple test

problems:
* uses TSC, which is i386-specific
* doesn't have an instrumentation point in the kernel
** no measurement of int latency, only process start latency
* process start latency is "guessed" from expected interrupt time
** that is, it is not actually measured
* not all boards have a working /dev/rtc driver

=== igel test ===
This tests scheduling latency on receipt of a character on an SM501 uart.
The UART driver gets a timestamp on ISR start, and can be asked for them
from user-space after a run.
The user-space driver measures the time from ISR start to task start.
Test is specific to SH architecture.
Uses SH hardware timer.

SH4 running at 240 MHZ, 64 MB memory.

See http://tree.celinuxforum.org/CelfPubWiki/UserLevelDeviceDriver
(page is in Japanese)

See also:
[http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree14?action=AttachFile&do=get&target=preempt070427celfjambo14.odp CELF Jamboree 14 presentation]

* Yung Joon will ask Takao Ikoma to translate this page.
* Matsubara-san will update the driver and some of the text on the page.
** will attach latest driver source
* Tim will provide Ikoma-san e-mail

Test shows some important results:
* 2.6.16.4 has much better scheduling latency under load than 2.4.20
** test was with kernel preemption - withOUT RT-preempt patches loaded.
* signal delivery method of waking up tasks took a lot longer than unblocking an I/O operation
** signal delivery is a bad method to use for measuring RT performance

=== Interbench ===
Need to investigate, but looks like a test of scheduling latency.

See http://members.optusnet.com.au/ckolivas/interbench/

=== celleb test ===
Runs test with Linux on hypervisor. Hypervisor generates interrupt to Linux at periodic
intervals. The kernel measures the ISR start time, and can query the hypervisor for the
intended interrupt initiation time.

Results on page 7 are results from hdparm, normalized against a baseline configuration.
Note that page 7 shows results from a kernel with a bug (in the non-RT case).

set PPC64_TLB_BATCH_NR to 1
why?

In english translation lpar = "logical partition". This refers to a single environment under
the hypervisor. The lpar interrupt was used because it was periodic.

hdparm used for load, not for measurement. The test provided 3 different measurements of performance.

Each run is a shown as a separate path on the graph. The paths are separated to be able
to distinguish the lines. (They have different 0-bases on the graph).
point on graph shows amount of latency for each interrupt. Interrupt is on horizontal axis.

page 14 shows interrupt latency, under load.

All results are shown normalized, to avoid disclosing actual numbers for the CELL processor
and hypervisor.

Stair-step results in the graph are from hdparm being run in a loop. Sometimes hdparm was
putting load on the system, and sometimes it was not (at regular intervals).

page 15 has previous results, with non-rt kernel with bug.

page 16 shows corrected results

page 18 - load is netperf

page 26 - send performance of nonRT kernel is used as baseline for normalization.
Measurement is of network performance (with several different configurations).
Result of good performance for non-RT kernel, but with interupt threading is
not expected.

Page 27 - shows throughput performance for hdparm for various configurations.
Different udma modes are configured via hdparm. (try man hdparm)

Page 28 is Owa-san's hypothesis for why the network throughput is better in the
non-rt, with irq threading, case. There are fewer hardware interrupts.
It may be because the interrupts are masked longer, so context switches are avoided. Also, because
of longer duration interrupt-off times, the network card may buffer packets, and the
network stack may be able to process more data at a time.

Tried to test:
* did RT-preempt patch for PPC64 work?
** result: yes, to some extent
* wanted to see if RT-preempt affected throughput performance
** result: it does affect performance some, but it is not a big effect.

=== etri testing ===
* wanted to compare RT-preempt with regular kernel.
** worst case latency was good with RT-preempt patch
* Wanted to use modified realfeel code (realfeel-etri)
** it worked.
* wanted to know relationship between scheduling latency and throughput performance
** result: there were possible throughput problems with the RT-preempt kernel

* haven't used realfeel-etri on ARM, yet.

=== realfeel-etri ===
problems:
* uses TSC (but abstracts the get_ticks() interface
** have to use something else on ARM
* needs /dev/RTC (may not be available on other embedded platforms)

benefits:
* is better than realfeel, because it measures time from ISR start
* uses read-unblock, which has good code path through kernel.

=== cyclictest ===
User timestamps from timer system to measure performance of timer system.

benefits:
* seems to be what other people are using.
* it should be architecture-independent
** (after HRT arch support is provided in kernel)

problems:
* requires HRT support
* requires newer version of glibc and compiler
* requires newer structure or API for timer info (not on MIPS)
* it doesn't have kernel instrumentation point

Notes:
* it works on SH, on 2.6.22 or later.
* it works on ppc64
* it didn't work on MIPS for Tim

don't know how to interpret results (don't know what constitutes good values)

== table of test attributes ==
{|border="1" cellspacing="0" cellpadding="5"
|- style="background:#CCCCCC"
|attribute / test->
|rf-etri
|igel
|celleb
|cyclictest
|-
|platform specific?
|yes - uses TSC, requires /dev/rtc
|yes - uses SH timestamp
|yes - uses lpar interrupt, uses cell timebase regs.
|no, but requires HRT support. Uses linux time system for timestamps
|-
|data format/handling
|text->csv->excel
|csv text
|text->csv->excel
|none
|-
|presentation
|excel charts
|gnuplot
|excel charts
|none
|-
|interrupt source
|/dev/rtc - periodic interrupt
|serial port
|lpar interrupt (hypervisor)
|timer system (reprogrammed inter intterrupt)
|-
|# machines
|1
|1
|2
|1
|-
|What is measured?
|B->C
|B->C
|0->B
|C->C2
|-
|Load source
|find, ping, hackbench
|ping, lmbench
|hdparm, netperf
|none
|-
|performance measurment
|hackbench
|none, but host could measure serial throughput
|hdparm, netperf, ping
|none
|-
|has user space element?
|yes
|yes
|no
|yes
|-
|kernel patches needed
|yes - patches to /dev/rtc
|yes - needs UIO support (mainlined in 2.6.23)
needs kernel module
|yes - needs kernel module
instrumentation of lpar handling code
|no, but needs HRT support for arch.
|}

=== shared Test Bed ideas ===
See Darren Hart's tests at : http://www.dvhart.com/~dvhart/ols2007

His paper is at: https://ols2006.108.redhat.com/2007/Reprints/rostedt-Reprint.pdf