How kernel compiler c library work together

http://wiki.osdev.org/How_kernel,_compiler,_and_C_library_work_together

Scope, lifetime and Visability in C

 http://www.linuxforu.com/2011/10/joy-of-programming-scope-lifetime-and-visibility-in-c/


There are five scopes in C: program, file, function, block, and prototype.

void foo() {}

// "foo" has program scope

static void bar() {

    // "bar" has file scope

    printf("hello world");

    int i;

    // "i" has block scope

}

void baz(int j);

// "j" has prototype scope

print:

// "print" has function scope

All non-static functions have program scope, and they can be called from anywhere in the program.

Of course, to make such a call, the function needs to be first declared using extern, before being called, but the point is that it is available throughout the program.

 There are three lifetimes in C: static, automatic and dynamic.

Summery of differences

As you can see, scope, lifetime and visibility are related to each other, but are distinct. Scope is about the ‘availability’ of the declared variable: within the same scope, it is not possible to declare/define two variables of the same type with the same name. Lifetime is about the duration in which the variable is ‘alive’: it determines how long the named or unnamed variable has memory allocated to it.
Visibility is about the ‘accessibility’ of the declared variables: it arises because of the possibility of variables in outer scope having the same name as the ones in inner scopes, resulting in ‘hiding’.

gcc warning: function used but not defined

static

internal linkage

http://stackoverflow.com/questions/5526461/gcc-warning-function-used-but-not-defined

mkimage command not found

http://shuiqingwang.blogspot.com/2012/07/solvedmkimage-command-not-found-u-boot.html

Problem: "mkimage" command not found - U-Boot images will not be built

Solution: sudo apt-get install uboot-mkimage

               make the kernel again

http://forkbomb.dadacafe.org/blog/__34__mkimage__34___command_not_found_-_U-Boot_images_will_not_be_built/


http://processors.wiki.ti.com/index.php/Linux_Toolchain

Anatomy of real-time Linux architecture

http://www.ibm.com/developerworks/library/l-real-time-linux/

Hard real-time vs. soft real-time systems

An operating system that can support the desired deadlines of the real-time tasks (even under worst-case processing loads) is called a hard real-time system. But hard real-time support isn't necessary in all cases. If an operating system can support the deadlines on average, it's called a soft real-time system. Hard real-time systems are those in which missing a deadline can have a catastrophic result (such as deploying an airbag too late or allowing brake pressure to slip for too long). Soft real-time systems can miss deadlines without the overall system failing (such as losing a frame of video).

Although the thin kernel approach has its advantages (hard real-time support coexisting with a standard Linux kernel), the approach does have drawbacks. The real-time and non-real-time tasks are independent, which can make debugging more difficult. Also, non-real-time tasks do not have full Linux platform support (the thin kernel execution is called thin for a reason).

Examples of this approach include RTLinux (now proprietary and owned by Wind River Systems), Real-Time Application Interface (RTAI), and Xenomai.

Nano-kernel approach

Resource-kernel approach

This approach adds a module to a kernel to provide reservations for various types of resources. The reservations guarantee access to time-multiplexed system resources (CPU, network, or disk bandwidth).

Using a scheduling algorithm such as Earliest-Deadline-First (EDF), the kernel can then be used to handle the dynamic scheduling workload.

 CMU's Linux/RK,

TimeSys Linux/RT offering.

Today, in the 2.6 kernel, you can get soft real-time performance through a simple kernel configuration to make the kernel fully preemptable (see Figure 6). In the standard 2.6 Linux kernel, when a user space process makes a call into the kernel (through a system call), it cannot be preempted.

The new configuration option CONFIG_PREEMPT changes this behavior of the kernel by allowing processes to be preempted if high-priority work is available to do (even if the process is in the middle of a system call).

Trade-off

Although the option enables soft real-time performance and even under load makes the operating system execute more smoothly,

it does so at a cost. That cost is slightly lower throughput and a small reduction in kernel performance because of the added overhead of the CONFIG_PREEMPT option. This option is useful for desktop and embedded systems, but it may not be right in all scenarios (for example, servers).

Kernel 2.6 for high resolution timers

1us resolution (if supported by underlying hardware)

Timer management (implemented with Red-black tree) for efficiency.

O(1) scheduler 

Preempt_RT Patch 

The PREEMPT_RT patch provides several modifications to yield hard real-time support. 

Reimplementing some of the kernel locking primitives to be fully preemptable,

Priority Inheritance

in kernel mutexes, and converting interrupt handlers into kernel threads so that they are fully preemptable

This article gave a brief overview of some of the techniques used to bring real-time computing to the Linux kernel. Numerous early attempts used a thin-kernel approach to segregate the real-time tasks from the standard kernel. Later, nano-kernel approaches came on the scene that appear very much like the hypervisors used in virtualization solutions today. Finally, the Linux kernel provides its own means for real time, both soft and hard.

Which operating system book do you recommend?

http://programmers.stackexchange.com/questions/7340/which-operating-system-book-do-you-recommend

Characteristics of a Good API

How to Design a Good API and Why it Matters

Joshua Bloch

Principal Software Engineer

Easy to learn
Easy to use, even without documentation
Hard to misuse
Easy to read and maintain code that uses it
Sufficiently powerful to satisfy requirements
Easy to extend
Appropriate to audience

 Your job is to extract true requirements  Should take the form of use-cases

USE-cases

Can be easier and more rewarding to build something more general

Start with Short Spec 1 page is Ideal

At this stage, agility trumps over completeness

Bounce spec off as many people as possible

_ Listen to their input and take it seriously

If you keep the spec short, it’s easy to modify

Flesh it out as you gain confidence

_ This necessarily involves coding

Write to Your API Early and Often

Start before you've implemented the API

_ Saves you doing implementation you'll throw away

Continue writing to API as you flesh it out

_ Prevents nasty surprises

_ Code lives on as examples, unit tests

Writing to SPI is Even More Important

Service Provider Interface (SPI)

 Plug-in interface enabling multiple implementations 

Write multiple plug-ins before release

_ If you write one, it probably won't support another

_ If you write two, it will support more with difficulty

_ If you write three, it will work fine

Maintain Realistic Expectations

Most API designs are over-constrained

_ You won't be able to please everyone

_ Aim to displease everyone equally

Expect to make mistakes

_ A few years of real-world use will flush them out

_ Expect to evolve API

API Should Do One Thing and Do it Well

• Functionality should be easy to explain

_ If it's hard to name, that's generally a bad sign

_ Good names drive development

_ Be amenable to splitting and merging modules

API Should Be As Small As Possible But

No Smaller

When in doubt leave it out

_ Functionality, classes, methods, parameters, etc.

_ You can always add, but you can never remove

Look for a good power-to-weight ratio

This maximizes information hiding

• Allows modules to be used, understood, built,

tested, and debugged independently

Documentation Matters

Document every class, interface, method,

constructor, parameter, and exception

Class: what an instance represents

_ Method: contract between method and its client

_ Preconditions, postconditions, side-effects

_ Parameter: indicate units, form, ownership

 Document state space very carefully

• Take advantage of API-friendly features

_ Generics, varargs, enums, default arguments

• Know and avoid API traps and pitfalls

_ Finalizers, public static final arrays

Subclass Only Where It Makes Sense

• Subclassing implies substitutability (Liskov)

_ Subclass only when is-a relationship exists

_ Otherwise, use composition

Provide Programmatic Access to All

Data Available in String Form

Use most specific possible input parameter type

_ Moves error from runtime to compile time

• Don't use string if a better type exists

_ Strings are cumbersome, error-prone, and slow

• Don't use floating point for monetary values

_ Binary floating point causes inexact results!

• Use double (64 bits) rather than float (32 bits)

_ Precision loss is real, performance loss negligible

Avoid Long Parameter Lists

Three or fewer parameters is ideal

_ More and users will have to refer to docs

Long lists of identically typed params harmful

_ Programmers transpose parameters by mistake

_ Programs still compile, run, but misbehave!

Two techniques for shortening parameter lists

_ Break up method

_ Create helper class to hold parameters

Avoid Return Values that Demand

Exceptional Processing

return zero-length array or empty collection, not null

Scheduling Computing and Pipe/pipeline (Unix)

https://en.wikipedia.org/wiki/Scheduling_(computing)
Some scheduling disciplines

First in first out

Shortest Remaining time

Fixed priority pre-emptive scheduling

Round robin

Multilevel queue

Manual Scheduling

In real time environments, such as embedded systems for


the scheduler also must ensure that processes can meet deadlines; this is crucial for keeping the system stable

https://en.wikipedia.org/wiki/Pipeline_(Unix)

In most Unix-like systems, all processes of a pipeline are started at the same time, with their streams appropriately connected, and managed by the scheduler together with all other processes running on the machine. An important aspect of this, setting Unix pipes apart from other pipe implementations, is the concept of buffering: for example a sending program may produce 5000 bytes per second, and a receiving program may only be able to accept 100 bytes per second, but no data is lost. Instead, the output of the sending program is held in a queue. When the receiving program is ready to read data, the operating system sends its data from the queue, then removes that data from the queue. If the queue buffer fills up, the sending program is suspended (blocked) until the receiving program has had a chance to read some data and make room in the buffer. In Linux, the size of the buffer is 65536 bytes.

LearnCpp 8.7 — The hidden “this” pointer

http://www.learncpp.com/cpp-tutorial/87-the-hidden-this-pointer/

Most of the time, you never need to explicitly reference the “this” pointer. However, there are a few occasions where it can be useful:

1) If you have a constructor (or member function) that has a parameter of the same name as a member variable, you can disambiguate them by using “this”:

1 2 3 4 5 6 7 8 9 10 11

class Something { private:     int nData;   public:     Something(int nData)     {         this->nData = nData;     } };

Note that our constructor is taking a parameter of the same name as a member variable. In this case, “nData” refers to the parameter, and “this->nData” refers to the member variable. Although this is acceptable coding practice, we find using the “m_” prefix on all member variable names provides a better solution by preventing duplicate names altogether!

2) Occasionally it can be useful to have a function return the object it was working with. Returning *this will return a reference to the object that was implicitly passed to the function by C++.


One use for this feature is that it allows a series of functions to be “chained” together, so that the output of one function becomes the input of another function! The following is somewhat more advanced and can be considered optional material at this point.

class Calc

{

private:

    int m_nValue;

 

public:

    Calc() { m_nValue = 0; }

 

    Calc& Add(int nValue) { m_nValue += nValue; return *this; }

    Calc& Sub(int nValue) { m_nValue -= nValue; return *this; }

    Calc& Mult(int nValue) { m_nValue *= nValue; return *this; }

 

    int GetValue() { return m_nValue; }

};

Note that Add(), Sub() and Mult() are now returning *this, which is a reference to the class itself. Consequently, this allows us to do the following:

1 2	Calc cCalc; cCalc.Add(5).Sub(3).Mult(4);

The important point to take away from this lesson is that the “this” pointer is a hidden parameter of any member function. Most of the time, you will not need to access it directly. It’s worth noting that “this” is a const pointer — you can change the value of the object it points to, but you can not make it point to something else!