Date   

Re: [PROPOSAL] Compressed printk messages

Jean-Christophe PLAGNIOL-VILLARD
 

On 22:31 Wed 02 Oct , Bird, Tim wrote:
; Summary: Compressed printk messages
; Proposer: Tim Bird - Sony Mobile Communications

== Description ==
Attempts have been made in the past to compress printk messages to save kernel
runtime footprint. There is an option to disable all printks, but many embedded
developers do not use it, even when they find the space savings attractive, because
they still would like to see kernel debug messages.

This project would consist of researching mechanisms that could be used
to automatically (at compile-time) compress the kernel's printk messages,
and transparently expand them at runtime.

The goal would be to have no user-visible change in behaviour for the
kernel, as well as no required developer-visible changes in the source code.
Probably, a new kernel option would be used to control this
feature.

The work would involve parsing the kernel source code, extracting
the messages (and possibly replacing them in source, during the compilation),
compressing them, and replacing the original strings with references to
the compressed messages (in a way that the messages can be uncompressed
transparently at runtime.)

=== Miscelaneous issues ===
There may be an issue with finding all kernel messages, due to the number
of macros (probably in the hundreds) that are used to wrap printks.
This feature might still be useful, even if not all kernel messages
could be converted, as long as significant size savings were made
available by using the feature. Significant size savings would be
on the order of 50K to 100K.

There might also be some benefit from message consolidation. (I don't know
if the compiler already coalesces identical strings, but this system should
be able to.)
I'm intresseteing in it

we could use this too on barebox

Best Regards,
J.

== Related work ==
* Timothy Miller did some work on this in 2003
** See http://lwn.net/Articles/28935/
** See https://lkml.org/lkml/2003/6/6/207
* See also some ideas here:
** http://selenic.com/pipermail/linux-tiny/2005-June/000208.html

== Scope ==
Unknown - 4 to 8 weeks?

== Contractor Candidates ==
None yet.

== Comments ==
This project was proposed in 2012, but not sponsored that year.

[[Category:Project proposals 2012]]
[[Category:Project proposals 2013]]
_______________________________________________
Celinux-dev mailing list
Celinux-dev@...
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev


Re: [PROPOSAL] Android boot time improvements

Jean-Christophe PLAGNIOL-VILLARD
 

On 10:11 Thu 03 Oct , Geert Uytterhoeven wrote:
On Thu, Oct 3, 2013 at 9:31 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@...> wrote:
Android boot time could be dramatically improved by leveraging
checkpoints/snapshots approaches (might be sufficient for variety of
products/use cases), on the other side it would be great to study
deeper if Android cold boot speed could be improved, at least for
automotive/IVI scenarios (get display/video/audio enabled early)
what is the booting target?

I've done in the past on non optimised android < 30s from cold start to UI
on arm926ejs with base Android < 30s
on more complex and full feature Android on Cortex-A9 (5 MiB kernel) < 30s
with optimised bootloader (barebox)
Hmm, 30 seconds can be a long time ;-)

For user interaction, the typical guideline is: upon any user activity,
the system should respond within 500 ms, either by performing the
operation, or by giving an indication about it's progress.

if I e.g. fetch my camera and turn it on, I want to take a picture within
500 ms.
That is exactly the issue here what means boot time.

here I get board with a full system + QT UI in 300ms running from cold start.

You must specify what means boot time because boot time can be up to the
prompt or up to specific application feature that is customer specific not
general purpose

Best Regards,
J.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PROPOSAL] Android boot time improvements

Geert Uytterhoeven
 

On Thu, Oct 3, 2013 at 9:31 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@...> wrote:
Android boot time could be dramatically improved by leveraging
checkpoints/snapshots approaches (might be sufficient for variety of
products/use cases), on the other side it would be great to study
deeper if Android cold boot speed could be improved, at least for
automotive/IVI scenarios (get display/video/audio enabled early)
what is the booting target?

I've done in the past on non optimised android < 30s from cold start to UI
on arm926ejs with base Android < 30s
on more complex and full feature Android on Cortex-A9 (5 MiB kernel) < 30s
with optimised bootloader (barebox)
Hmm, 30 seconds can be a long time ;-)

For user interaction, the typical guideline is: upon any user activity,
the system should respond within 500 ms, either by performing the
operation, or by giving an indication about it's progress.

if I e.g. fetch my camera and turn it on, I want to take a picture within
500 ms.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PROPOSAL] Android boot time improvements

Jean-Christophe PLAGNIOL-VILLARD
 

On 10:27 Thu 03 Oct , Artemi Ivanov wrote:
; Summary: Android boot time improvements

; Proposer: Artemi Ivanov

== Description ==
Android boot time could be dramatically improved by leveraging
checkpoints/snapshots approaches (might be sufficient for variety of
products/use cases), on the other side it would be great to study
deeper if Android cold boot speed could be improved, at least for
automotive/IVI scenarios (get display/video/audio enabled early)
what is the booting target?

I've done in the past on non optimised android < 30s from cold start to UI
on arm926ejs with base Android < 30s
on more complex and full feature Android on Cortex-A9 (5 MiB kernel) < 30s

with optimised bootloader (barebox)


== Related work ==
* 0xlab survey - Shorten Device Boot Time for Automotive IVI and
Navigation Systems; Implement Checkpointing for Android; Android
Boot Time Optimization
* CELF Boot time page - http://elinux.org/Boot_Time

== Scope ==
* Leverage most powerful hw platforms (multicore Cortex-A15 SOCs, fast
storage, etc.)
more powerfull hw does not mean shorter boot time

to be able to comparare anything we need have similar hw feature as more
driver you have to load means more time to boot. I also could have hw design
issue on dev board that slow down the boot

* Get max of what could be optimized at bootcode/kernel level (this
could be done in a week or so - using boottime cook books)
* Try to get Android booting to UI/video/audio in a couple of seconds
range (i.e. custom/automotive-focused use-case)...
* Compare results with snapshots/checkpoints implementation

Efforts: 6-8 weeks

== Contractor Candidates ==


== Comments ==


[[Category:Project proposals 2013]]
_______________________________________________
Celinux-dev mailing list
Celinux-dev@...
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev


[PROPOSAL] Setup LTSI Testing/Validation infrastructure

artemi.ivanov@cogentembedded.com
 

; Summary: Setup LTSI Testing/Validation infrastructure

; Proposer: Artemi Ivanov / Hisao Munakata

== Description ==
It has been discussed recently: how LTSI project could attract new contributors, what are the key factors for product architects/decision makers to select LTSI kernel as a base line for their development, what are potential risks when productizing a selected LTSI release.

It would be nice to start bringing quality and test coverage metrics to the LTSI project. This could help with LTSI productization/adaptation efforts by ODM/OEMs and semiconductor vendors.
Building specifications and test coverage for LTSI is not a trivial task, it would require a few requirements gathering/discussion/prototyping cycles before finalizing "what needs to be tested", "how it needs to be tested", infrastructure, maintenance. Ultimate goal would be: LTSI quality specification (definition of features/components/configurations/performance/stability requirements), LTSI test coverage (definition of tests, parameters, thresholds), LTSI Testing Infrastructure (Test Automation framework, tracking system) and well-defined maintenance and contribution process.

While LTSI quality/testing discussion is ongoing It would be great to have LTSI Testing/Validation infrastructure prototype: setup test automation frameworks (Linaro LAVA and Jenkins), integrate a few popular/useful open source test suites (benchmarks - networking, graphics, storage; LTP/LTP-DDT; LAVA tests) and make it available for public. LTSI Test results, performance numbers, quality metrics should be available online (at least for a few selected hardware platforms/configurations). It is also expected that LTSI contributors could install/adapt same infrastructure for their environment (hopefully tests results and metrics are also reproducible)

== Related work ==
* Jenkins - http://jenkins-ci.org/
* LAVA - https://wiki.linaro.org/Platform/LAVA
* LTP DDT - http://processors.wiki.ti.com/index.php/LTP-DDT

== Scope ==
* Hardware infrastructure setup: setup a few selected hardware platforms, including automated recovery/powercycling

* Software infrastructure setup: setup test frameworks, integrate and tune tests so they are could be run unattended

Efforts: 5 weeks?

== Contractor Candidates ==
Artemi Ivanov (Cogent Embedded)

== Comments ==


[[Category:Project proposals 2013]]


[PROPOSAL] Android boot time improvements

artemi.ivanov@cogentembedded.com
 

; Summary: Android boot time improvements

; Proposer: Artemi Ivanov

== Description ==
Android boot time could be dramatically improved by leveraging checkpoints/snapshots approaches (might be sufficient for variety of products/use cases), on the other side it would be great to study deeper if Android cold boot speed could be improved, at least for automotive/IVI scenarios (get display/video/audio enabled early)

== Related work ==
* 0xlab survey - Shorten Device Boot Time for Automotive IVI and Navigation Systems; Implement Checkpointing for Android; Android Boot Time Optimization
* CELF Boot time page - http://elinux.org/Boot_Time

== Scope ==
* Leverage most powerful hw platforms (multicore Cortex-A15 SOCs, fast
storage, etc.)
* Get max of what could be optimized at bootcode/kernel level (this
could be done in a week or so - using boottime cook books)
* Try to get Android booting to UI/video/audio in a couple of seconds
range (i.e. custom/automotive-focused use-case)...
* Compare results with snapshots/checkpoints implementation

Efforts: 6-8 weeks

== Contractor Candidates ==


== Comments ==


[[Category:Project proposals 2013]]


Re: [PROPOSAL] CPU Shielding capability

Lucas De Marchi <lucas.demarchi@...>
 

Hi Tim,

On Wed, Oct 2, 2013 at 5:27 PM, Bird, Tim <Tim.Bird@...> wrote:
; Summary: CPU Shielding capability

; Proposer: Tim Bird, Sony Mobile

== Description ==
In multi-processor realtime systems, it is sometimes desirable to isolate some CPUs in
the system to enhance their capability to maintain realtime performance.

Normally, when the Linux kernel is running in an SMP configuration, any CPU may take an interrupt
or run a process. Under realtime conditions, the operations of scheduling multiple processes
or handling an interrupt may interfere with a particular process meeting it's realtime deadlines.

It would be nice to be able to isolate a realtime process on a CPU such that it was shielded
from the scheduling of other processes and from handling interrupts.

This project would create a new 'shield' command, which would restrict a particular CPU
to execution of an particular process (or set of processes), and also prevent that CPU
from handling interrupts. This might involve modifying the kernel scheduler and using
IRQ affinity features in the kernel to achieve this result.

cgroups supports such a feature, called 'cpusets', but if the feature can be provided outside
of cgroups, that would be better, since cgroups is generally incompatible with realtime embedded Linux.
Why not use the isolcpus on the kernel command line? It doesn't depend
on cgroups. Do you really need to configure this at runtime?

Lucas De Marchi


[PROPOSAL] Add support for CONFIG_NUMA to ARM

Bird, Tim <Tim.Bird@...>
 

; Summary: Add support for CONFIG_NUMA to ARM
; Proposer: Tim Bird, Sony Mobile

== Description ==
ARM does not currently support CONFIG_NUMA. In some embedded products,
it is useful to treat separate sections of memory as non-uniform, even
if the hardware is only presenting a single, uniform range of memory.

The NUMA features in the kernel allow portions of physical memory to
represented by different NUMA nodes. The NUMA code also handles
initialization of memory management for the nodes on a per-node basis. Also, the
description of the division of memory into nodes can be passed from the kernel
commandline by end users.

Thus after the system is booted up the the memory management code
can use this partitioning/division of memory to provide features
which are based on memory nodes. For example, some memory regions
can be made read-only while others can be made read-write.

== Related work ==
* In this commit id, Russel King removed DISCONTIGMEM support for ARM from the kernel and directed people to start using SPARSEMEM
** https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=be370302742ff9948f2a42b15cb2ba174d97b930
* Linaro has worked on NUMA support for ARM
** See https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
* Russell King has questioned the value of NUMA support, for machines that don't actually have physically non-uniform memory
** http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137119.html

== Scope ==
This one is probably pretty large. (But maybe not since Linaro already has something apparently working.)
Complete wild guess: 12 weeks.

== Contractor Candidates ==
Unknown

== Comments ==

[[Category:Project proposals 2013]]


Re: [PROPOSAL] Add device-tree support to the pn544 NFC driver

Bird, Tim <Tim.Bird@...>
 

On Wednesday, October 02, 2013 3:41 PM, Bird, Tim wrote:
== Description ==
The NXP PN544 NFC chipset is used in a very large number of Linux-based devices.
The driver in mainline was submitted by developers at Nokia, and was last
worked on in 2011.
OK - this is not right. For my research on the current driver, I was looking
at the wrong git tree. The driver in mainline has been worked on
much more recently than this, by the fine folks at Intel.

Sorry for the mis-information.
-- Tim


[PROPOSAL] Add device-tree support to the pn544 NFC driver

Bird, Tim <Tim.Bird@...>
 

; Summary: Add device-tree support to the pn544 NFC driver
; Proposer: Tim Bird, Sony Mobile

== Description ==
The NXP PN544 NFC chipset is used in a very large number of Linux-based devices.
The driver in mainline was submitted by developers at Nokia, and was last
worked on in 2011. It is missing any integration with device-tree. Such
integration would make it easier to use in current products. Some companies
are apparently using their own driver for the PN544. It would be worth
investigating if the driver in mainline is missing some functionality
that prevents its use, and fixing that as well.

This project would consist of adding device-tree awareness to the existing
driver, at drivers/nfc/pn544.c. This awareness would consist of integrating
the driver with the DT-isms for regulators (and/or gpios) and i2c.

== Related work ==
None that I can think of.

== Scope ==
Rough estimate is 2 to 4 weeks. Maybe quicker with someone familiar with
device-tree stuff.

== Contractor Candidates ==
None yet.

== Comments ==

[[Category:Project proposals 2013]]


[PROPOSAL] Mainline synaptics touchscreen driver

Bird, Tim <Tim.Bird@...>
 

(For the benefit of Christopher and Dmitry, who are CC'ed and might not
know what this is all about - the CE Workgroup of the Linux Foundation
periodically funds contract work for items of interest to member companies
or the industry in general. This is one such proposal, by Sony Mobile.
Please contact me individually if you have questions about this process
or this proposal, or see http://elinux.org/CEWG_Open_Project_Proposal_2013
for details.)

; Summary: Mainline synaptics touchscreen driver
; Proposer: Tim Bird, Sony Mobile

== Description ==
The synaptics touchscreen is used in many embedded project, particularly
phones and tablets. However, it does not have a driver in mainline.
This project would consist of mainlining it (submitting the driver
and responding to community requests for enhancements.)

The driver has been submitted a number of times previously, so code
is available, and many former issues have been addressed. This work was
submitted in late 2012 by Christoper Heiny (a developer at Synaptics).
Possibly, Synaptics engineers could assist with this effort.

Because there was not much resistance on the last submission attempt,
it is possible this just fell through the cracks, and just needs a slight
push to get it upstream. Or, there might be bigger issues.

It appears that the code was been accepted into Dmitry Korokhov's tree, but
not progressed past that point, as of Jan 2013. Part of this project
would be investigating why the code stalled, and resolving any outstanding
issues to Dmitry's satisfaction.

== Related work ==
* May 2010 lkml submission: http://lwn.net/Articles/389931/
* June 2011 lkml submission: http://lwn.net/Articles/449981/
* Nov 2012 lkml submission: http://lwn.net/Articles/525557/
* Jan 2013 changes: http://lwn.net/Articles/533550/
** The patch set is sitting in Dmitry Torokhov's tree at: https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/log/?h=synaptics-rmi4

== Scope ==
It is notoriously difficult to estimate the time it takes to mainline something.
Given the comments on the most recent submittal, however, this driver looks like
it is pretty close. I would estimate 4 person-weeks.

== Contractor Candidates ==
None yet.

== Comments ==

[[Category:Project proposals 2013]]


Re: [PROPOSAL] Overwrite detection for kernel text and read-only data

Bird, Tim <Tim.Bird@...>
 

On Wednesday, October 02, 2013 1:32 PM, Bird, Tim wrote:

A significant difficulty is that the kernel memory for ARM is currently mapped by
section (that is, using 1MB sections). This means that small memory areas
cannot be individually re-mapped RO on page boundaries. If the kernel has code
which must be writable for some reason, then with that current mapping, at least
a 1MB section would be used for that writable code.
FYI - Sony has patches to support 4KB mappings for the kernel, for ARM,
which they've been using internally. These might be useful
for this feature.


[PROPOSAL] Support asymetric RSA in Crypto API

Bird, Tim <Tim.Bird@...>
 

; Summary: Support asymetric RSA in Crypto API
; Proposer: Tim Bird, Sony Mobile

== Description ==
The current AF_ALG interface to user space only
supports hash and symmetric algorithms.
Some user applications may want to utilize HW
crypto engine's asymetric algorithm, like RSA.
The purpose of this project would be to add full RSA
support in the kernel, extending the crypto API if needed.

== Related work ==
* RSA signature checking was added to the kernel in version 3.7
** See http://stackoverflow.com/questions/15152379/how-to-use-rsa-in-linux-kernel
** [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=612e0fe99965a4028359cd1da5af56b7f6caf7f6 git commit]
* http://www.ietf.org/rfc/rfc3447.txt
* [http://thesweeheng.files.wordpress.com/2007/11/6451.pdf The Linux Kernel Cryptographic API]

== Scope ==
Unknown

== Contractor Candidates ==
None yet.

== Comments ==

[[Category:Project proposals 2013]]


[PROPOSAL] Kernel module binary compatibility with debug features

Bird, Tim <Tim.Bird@...>
 

; Summary: Kernel module binary compatibility with debug features
; Proposer: Tim Bird, Sony Mobile

== Description ==
Sometimes, the workflow for embedded systems include obtaining kernel modules from
3rd party vendors or other software teams. In certain situations, it can be difficult
to re-compile and re-install these 3rd party modules, even though the kernel on a system
can be re-configured, rebuilt and re-installed.

This feature proposes to isolate the kernel module interface from changes in certain
kernel debug features, so that turning on those feature will not create binary incompatibility
with a newly configured and deployed kernel.

For example, if a kernel is compiled with CONFIG_DEBUG_SPINLOCK, then modules which
use spinlocks may not be able to be supported without being re-compiled with the same
debug option. It is believed that this same restriction applies to the following kernel
debug features:
* ftrace
* perf
* kprobe
* SLUB_DEBUG
* DEBUG_SPINLOCK

It would be nice to be able to enable and disable debug features in the kernel
without changing the kernel's module binary compatibility.

This would involve somehow insulating the kernel from problems when it was
configured with a particular debug feature, but a module does not support
that configuration. This is mainly targetted at things like structure extensions
in the debug case, and having the kernel core detect multiple structure formats
at runtime, and deal with them correctly. It might also involve making sure that
function calls which bypassed the debug infrastructure (such as a spinlock debug
wrappers or a trace wrappers) by the original compiled module continued to work correctly.

== Related work ==
* Module symbol versioning may be related to this.
** See section 6 of: https://www.kernel.org/doc/Documentation/kbuild/modules.txt

== Scope ==
Unknown

== Contractor Candidates ==
None Yet.

== Comments ==

[[Category:Project proposals 2013]]


[PROPOSAL] Overwrite detection for kernel text and read-only data

Bird, Tim <Tim.Bird@...>
 

; Summary: Overwrite detection for kernel text and read-only data

; Proposer: Tim Bird, Sony Mobile

== Description ==
In embedded systems, drivers or other subsystems can easily (mistakenly)
overwrite kernel text or kernel read-only area. It can be very difficult to debug
who is overwriting kernel.

It would be nice to have some mechanism to detect kernel overwriting or corruption
by setting a write-protect attribute in page tables for kernel text or read-only data.
x86 already has this feature in the form of CONFIG_DEBUG_RODATA. This project
would consist of providing support for this feature in ARM, as well as possibly
creating exceptions for code which needs to modify the kernel text at runtime,
such as Kprobe or ftrace.

A significant difficulty is that the kernel memory for ARM is currently mapped by
section (that is, using 1MB sections). This means that small memory areas
cannot be individually re-mapped RO on page boundaries. If the kernel has code
which must be writable for some reason, then with that current mapping, at least
a 1MB section would be used for that writable code. Likely, the linking sections
of the source would have to be modified to support RO/RW attributes, to coalesce
the sections into correct categories.


== Related work ==
* [http://www.slideshare.net/prabindh/arm-memory-protection-techniques ARM Linux Embedded memory protection techniques]
** Presentation by Prabindh Sundareson in May, 2013 about the status of ARM memory protection features.
* Russel King comments on kernel memory and RO mapping: http://www.spinics.net/lists/arm-kernel/msg120951.html
* The implementation of CONFIG_DEBUG_RODATA in x86 may have some useful information.

== Scope ==
Unknown

== Contractor Candidates ==
None yet.

== Comments ==

[[Category:Project proposals 2013]]


[PROPOSAL] Support dumping user-space stack from kernel

Bird, Tim <Tim.Bird@...>
 

; Summary: Support dumping user-space stack from kernel

; Proposer: Tim Bird, Sony Mobile

== Description ==
Currently, a function like dump_stack() (which internally calls
dump_backtrace()) is limited to showing the the dump of kernel stack only.

In some situations it would be useful to get the call stack of the user
level process also, instead of just the kernel's call stack.
This feature could be used to determine what user-space activity
was responsible for what kernel actions.

It will be nice if this feature could be enabled with a kernel config option.

In conjunction with this, it would be nice to support a system-wide
tracing function, which could trace both user-space and kernel space.
This would include a simple method in userspace to show the both
user-space and kernel-space functions, with arguments and return values.

Other existing systems, such as strace, ltrace and ftrace, show parts of
the full sequence of execution, but not all of them.
It would be nice to create an easy tool similar to strace, which showed
the functions through all levels of the system.

As an example, when running a program called 'prog1', it would be nice to collect and display:
* all function/library all from prog1 in user-space,including the arguments for each call and the return values
* all system calls made by prog1, including arguments and return values
* all the function calls in kernel-space launched resulting from prog1 (all processes / threads) including what happens during system call, irq, softirq, and tasklets)

== Related work ==
* LTTng - has a user-space tracer (not the same as monitoring return values)

== Scope ==
Unknown

== Contractor Candidates ==
None yet.

== Comments ==

[[Category:Project proposals 2013]]


[PROPOSAL] Compressed printk messages

Bird, Tim <Tim.Bird@...>
 

; Summary: Compressed printk messages
; Proposer: Tim Bird - Sony Mobile Communications

== Description ==
Attempts have been made in the past to compress printk messages to save kernel
runtime footprint. There is an option to disable all printks, but many embedded
developers do not use it, even when they find the space savings attractive, because
they still would like to see kernel debug messages.

This project would consist of researching mechanisms that could be used
to automatically (at compile-time) compress the kernel's printk messages,
and transparently expand them at runtime.

The goal would be to have no user-visible change in behaviour for the
kernel, as well as no required developer-visible changes in the source code.
Probably, a new kernel option would be used to control this
feature.

The work would involve parsing the kernel source code, extracting
the messages (and possibly replacing them in source, during the compilation),
compressing them, and replacing the original strings with references to
the compressed messages (in a way that the messages can be uncompressed
transparently at runtime.)

=== Miscelaneous issues ===
There may be an issue with finding all kernel messages, due to the number
of macros (probably in the hundreds) that are used to wrap printks.
This feature might still be useful, even if not all kernel messages
could be converted, as long as significant size savings were made
available by using the feature. Significant size savings would be
on the order of 50K to 100K.

There might also be some benefit from message consolidation. (I don't know
if the compiler already coalesces identical strings, but this system should
be able to.)

== Related work ==
* Timothy Miller did some work on this in 2003
** See http://lwn.net/Articles/28935/
** See https://lkml.org/lkml/2003/6/6/207
* See also some ideas here:
** http://selenic.com/pipermail/linux-tiny/2005-June/000208.html

== Scope ==
Unknown - 4 to 8 weeks?

== Contractor Candidates ==
None yet.

== Comments ==
This project was proposed in 2012, but not sponsored that year.

[[Category:Project proposals 2012]]
[[Category:Project proposals 2013]]


[PROPOSAL] CPU Shielding capability

Bird, Tim <Tim.Bird@...>
 

; Summary: CPU Shielding capability

; Proposer: Tim Bird, Sony Mobile

== Description ==
In multi-processor realtime systems, it is sometimes desirable to isolate some CPUs in
the system to enhance their capability to maintain realtime performance.

Normally, when the Linux kernel is running in an SMP configuration, any CPU may take an interrupt
or run a process. Under realtime conditions, the operations of scheduling multiple processes
or handling an interrupt may interfere with a particular process meeting it's realtime deadlines.

It would be nice to be able to isolate a realtime process on a CPU such that it was shielded
from the scheduling of other processes and from handling interrupts.

This project would create a new 'shield' command, which would restrict a particular CPU
to execution of an particular process (or set of processes), and also prevent that CPU
from handling interrupts. This might involve modifying the kernel scheduler and using
IRQ affinity features in the kernel to achieve this result.

cgroups supports such a feature, called 'cpusets', but if the feature can be provided outside
of cgroups, that would be better, since cgroups is generally incompatible with realtime embedded Linux.

== Related work ==
* RedHawk Linux has a command called 'shield' which performs this function:
** http://wiki.simwb.com/swbwiki/swbdoc/UserManualFlash/SimConfig/optimizing/optimizing.htm
* http://www.janoszen.com/2013/02/06/limiting-linux-processes-cgroups-explained/

== Scope ==
Unknown

== Contractor Candidates ==
None yet.

== Comments ==

[[Category:Project proposals 2013]]


[PROPOSAL] More robust UBIFS support

Bird, Tim <Tim.Bird@...>
 

Well, deadlines are good for spuring last-minute action....
Here are a bunch of project proposals from Sony.

; Summary: More robust UBIFS support
; Proposer: Tim Bird, Sony Mobile

== Description ==
UBIFS is the preferred Linux filesystem for large raw NAND flash, but it still
has some stability issues.

This project would consist of robustness testing of UBIFS, with an eye towards
fixing any unstable or corruption bugs found.

== Related work ==
* See [[Start working on the "unstable_bits" issue to make UBIFS more robust]]
** This project was proposed in 2012

== Scope ==
Unknown

== Contractor Candidates ==
Artem Bityuski is the UBIFS maintainer. Wolfram Sang proposed the "unstable bits" project.

== Comments ==

[[Category:Project proposals 2013]]


Re: [PROPOSAL] Fix platform device irq domain support and gpio irq DT

Bird, Tim <Tim.Bird@...>
 

On Wednesday, October 02, 2013 2:13 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
Summary
=======

Fix IRQ Domain DT support issues and gpio IRQ
...

Jean-Christophe,

Given objections raised on the list, and my preference for easy submission
to the elinux wiki, can you re-submit this proposal with the following changes:

1) please use the format specified in the template at:
http://elinux.org/CEWG_Open_Project_Proposal_template

2) please fill in the Scope and Contractor Candidates sections
with your own wording.

This should not take too long.

Thanks,
-- Tim

321 - 340 of 1279