'Linux'에 해당되는 글 11건
# This xorg configuration file is meant to be used
# to start a dummy X11 server.
# For details, please see:
# https://www.xpra.org/xorg.conf
# Here we setup a Virtual Display of 1920x1200 pixels
Section "Device"
Identifier "Configured Video Device"
Driver "dummy"
#VideoRam 4096000
#VideoRam 256000
VideoRam 192000
EndSection
Section "Monitor"
Identifier "Configured Monitor"
HorizSync 5.0 - 1000.0
VertRefresh 5.0 - 200.0
Modeline "1920x1200" 193.25 1920 2056 2256 2592 1200 1203 1209 1245
Modeline "1440x900" 106.50 1440 1528 1672 1904 900 903 909 934
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Virtual 1920 1200
EndSubSection
EndSection
Get modeline parameters by "cvt 1920 1200" on terminal.
Ref: http://cosmolinux.no-ip.org/raconetlinux2/dummy_radeon_nvidia.html
[Ref: http://askubuntu.com/questions/331538/what-is-the-right-way-to-downgrade-kernel]
apt-cache policy linux-image-*
Also, the Tab Completion feature is very handy and you should learn to use it. Open a terminal and write
sudo apt-get install linux-image-
Then hit Tab key twice and read the list, can you see 3.2 kernel ?
do I need to install linux-header package too, are there more package I should install?
Every linux-image has its own linux-headers version, so it is preferable to install them too.
sudo apt-get install linux-headers-
and use the same Tab Completion feature (as in linux-image- above) to locate the appropriate ones.
If older version is not applicable, try below command.
sudo apt-get remove linux-OLD_VERSION
Installing required packages (Ubuntu 12.04)
You will need a 64-bit version of Ubuntu. Ubuntu 12.04 is recommended. Building using an older version of Ubuntu is not supported on master or recent releases.
$ sudo apt-get install git gnupg flex bison gperf build-essential \
zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev \
libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 \
libgl1-mesa-dev g++-multilib mingw32 tofrodos \
python-markdown libxml2-utils xsltproc zlib1g-dev:i386
$ sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so
https://source.android.com/source/downloading.html 에서 Downloading the Android Source Tree 까지 따라한다.
https://developers.google.com/android/nexus/drivers#hammerhead 에서 3개의 .tgz 파일 다운 받고,
android source 최상위 디렉토리에 압축을 푼다. 그리고 나서 각각의 스크립트 실행.
"I ACCEPT" 로 라이센스에 동의.
$ . build/envsetup.sh
$ lunch aosp_hammerhead-eng (https://source.android.com/source/building-running.html 참고.)
$ make -j4
약 6시간 동안 빌드 진행.
boot.img 및 system.img 를 NRT 같은 툴을 이용해서 포팅하면 끝!
------
일부만 수정하고 빌드하려는 경우엔
$ . build/envsetup.sh
$ lunch aosp_hammerhead-eng
하고 나서,
해당 파트의 Android.mk가 있는 위치에서 'mm' command 활용.
또는 mmm '파트 위치'
make snod 통해 이미지를 다시 생성한다.
du -h --apparent-size TARGET_DIR
You can see only the size of TARGET_DIR by adding -s option.
echo `seq -f "%.0f" 12345 12370`
(Ref: http://codewiki.wikidot.com/c:system-calls:dup2)
dup2 is a system call similar to dup in that it duplicates one file descriptor, making them aliases, and then deleting the old file descriptor. This becomes very useful when attempting to redirect output, as it automatically takes care of closing the old file descriptor, performing the redirection in one elegant command. For example, if you wanted to redirect standard output to a file, then you would simply call dup2, providing the open file descriptor for the file as the first command and 1 (standard output) as the second command.
#include <unistd.h>
int dup2(int fildes, int fildes2);
| Field | Description |
|---|---|
| int fildes | The source file descriptor. This remains open after the call to dup2. |
| int fildes2 | The destination file descriptor. This file descriptor will point to the same file as filedes after this call returns. |
| return value | dup2 returns the value of the second parameter (fildes2) upon success. A negative return value means that an error occured. |
Using dup2(), we can redirect standard output to a file, as follows:
#include <iostream> #include <unistd.h> #include <fcntl.h> using namespace std; int main() { //First, we're going to open a file int file = open("myfile.txt", O_APPEND | O_WRONLY); if(file < 0) return 1; //Now we redirect standard output to the file using dup2 if(dup2(file,1) < 0) return 1; //Now standard out has been redirected, we can write to // the file cout << "This will print in myfile.txt" << endl; return 0; }//end of function main
(Reference: http://rethinkdb.com/blog/lock-free-vs-wait-free-concurrency/)
There are two types of non-blocking thread synchronization algorithms - lock-free, and wait-free. Their meaning is often confused. In lock-free systems, while any particular computation may be blocked for some period of time, all CPUs are able to continue performing other computations. To put it differently, while a given thread might be blocked by other threads in a lock-free system, all CPUs can continue doing other useful work without stalls. Lock-free algorithms increase the overall throughput of a system by occassionally increasing the latency of a particular transaction. Most high- end database systems are based on lock-free algorithms, to varying degrees.
By contrast, wait-free algorithms ensure that in addition to all CPUs continuing to do useful work, no computation can ever be blocked by another computation. Wait-free algorithms have stronger guarantees than lock-free algorithms, and ensure a high thorughput without sacrificing latency of a particular transaction. They're also much harder to implement, test, and debug. The lockless page cache patches to the Linux kernel are an example of a wait-free system.
In a situation where a system handles dozens of concurrent transactions and has soft latency requirements, lock-free systems are a good compromise between development complexity and high concurrency requirements. A database server for a website is a good candidate for a lock-free design. While any given transaction might block, there are always more transactions to process in the meantime, so the CPUs will never stay idle. The challenge is to build a transaction scheduler that maintains a good mean latency, and a well bounded standard deviation.
In a scenario where a system has roughly as many concurrent transactions as CPU cores, or has hard real-time requirements, the developers need to spend the extra time to build wait-free systems. In these cases blocking a single transaction isn't acceptable - either because there are no other transactions for the CPUs to handle, minimizing the throughput, or a given transaction needs to complete with a well defined non-probabilistic time period. Nuclear reactor control software is a good candidate for wait-free systems.
RethinkDB is a lock-free system. On a machine with N CPU cores, under most common workloads, we can gurantee that no core will stay idle and no IO pipeline capacity is wasted as long as there are roughly N * 4 concurrent transactions. For example, on an eight core system, no piece of hardware will sit idle if RethinkDB is handling roughly 32 concurrent transactions or more. If there are fewer than 32 transactions, you've likely overpaid for some of the cores. (Of course if you only have 32 concurrent transactions, you don't need an eight-core machine).
Modifying the Default Behavior
The default behavior can be modified by setting options to various combinations of the WNOHANG and WUNTRACED constants:
. WNOHANG: Return immediately (with a return value of 0) if none of the child processes in the wait set has terminated yet. The default behavior suspends the calling process until a child terminates. This option is useful in those cases where you want to continue doing useful work while waiting for a child to terminate.
. WUNTRACED: Suspend execution of the calling process until a process in the wait set becomes either terminated or stopped. Return the PID of the terminated or stopped child that caused the return. The default behavior returns only for terminated children. This option is useful when you want to check for both terminated and stopped children.
. WNOHANG|WUNTRACED: Return immediately, with a return value of 0, if none of the children in the wait set has stopped or terminated, or with a return value equal to the PID of one of the stopped or terminated children.
Checking the Exit Status of a Reaped Child
If the status argument is non-NULL, then waitpid encodes status information about the child that caused the return in the status argument. The wait.h include file defines several macros for interpreting the status argument:
. WIFEXITED(status): Returns true if the child terminated normally, via a call to exit or a return.
. WEXITSTATUS(status): Returns the exit status of a normally terminated child. This status is only defined if WIFEXITED returned true.
. WIFSIGNALED(status): Returns true if the child process terminated because of a signal that was not caught.
. WTERMSIG(status): Returns the number of the signal that caused the child process to terminate. This status is only defined if WIFSIGNALED(status) returned true.
. WIFSTOPPED(status): Returns true if the child that caused the return is currently stopped.
. WSTOPSIG(status): Returns the number of the signal that caused the child to stop. This status is only defined if WIFSTOPPED(status) returned true.