'Linux'에 해당되는 글 8건
- Setting CPU Affinity | 2009/12/21
- [Linux] Disk Driver 추가하기 | 2008/11/12
- Sysenter Based System Call Mechanism in Linux 2.6 | 2007/07/16
- VMWare에서 해상도가 맞지 않을때.. (2) | 2007/05/21
- Port to Linux ( 리눅스로 포팅을 하자! ) (12) | 2006/12/17
- Linux Function Reference | 2006/12/05
- 라이브러리 찾기 (2) | 2006/11/22
- QT/X11 설치 | 2006/11/15
Setting CPU Affinity :: 2009/12/21 14:32
특정 Process를 원하는 core에서만 실행하고자 할 때가 있다. 이 경우 아래 명령어를 사용해 준다.
Linux
$ taskset -c 0 ./a.out
a.out을 0번 core에서만 실행을 함
Solaris 10
$ psrset -c 3
$ psrset -e 1 ./a.out
첫번째 명령어로 processor set을 설정해준다.
처음 설정해 주면 3번 코어가 1번째 processor set으로 설정이된다.
이후에 그 다음 명령어를 사용해서 첫번째 processor set으로 설정된 3번 코어를 이용해서 프로그램을 실행한다.
Trackback Address :: http://insidexino.net/trackback/2757347
[Linux] Disk Driver 추가하기 :: 2008/11/12 00:54
[root]# fdisk /dev/hdb |
출처 : http://www.yolinux.com/TUTORIALS/LinuxTutorialAdditionalHardDrive.html
Trackback Address :: http://insidexino.net/trackback/2757298
Sysenter Based System Call Mechanism in Linux 2.6 :: 2007/07/16 13:52
Starting with version 2.5, linux kernel introduced a new system call entry mechanism on Pentium II+ processors. Due to performance issues on Pentium IV processors with existing software interrupt method, an alternative system call entry mechanism was implemented using SYSENTER/SYSEXIT instructions available on Pentium II+ processors. This article explores this new mechanism. Discussion is limited to x86 architecture and all source code listings are based on linux kernel 2.6.15.6.
1. What are system calls?
System calls provide userland processes a way to request services from the kernel. What kind of services? Services which are managed by operating system like storage, memory, network, process management etc. For example if a user process wants to read a file, it will have to make 'open' and 'read' system calls. Generally system calls are not called by processes directly. C library provides an interface to all system calls.
2. What happens in a system call?
A kernel code snippet is run on request of a user process. This code runs in ring 0 (with current privilege level -CPL- 0), which is the highest level of privilege in x86 architecture. All user processes run in ring 3 (CPL 3). So, to implement system call mechanism, what we need is 1) a way to call ring 0 code from ring 3 and 2) some kernel code to service the request.
3. Good old way of doing it
Until some time back, linux used to implement system calls on all x86 platforms using software interrupts. To execute a system call, user process will copy desired system call number to %eax and will execute 'int 0x80'. This will generate interrupt 0x80 and an interrupt service routine will be called. For interrupt 0x80, this routine is an "all system calls handling" routine. This routine will execute in ring 0. This routine, as defined in the file /usr/src/linux/arch/i386/kernel/entry.S, will save the current state and call appropriate system call handler based on the value in %eax.
4. New shiny way of doing it
It was found out that this software interrupt method was much slower on Pentium IV processors. To solve this issue, Linus implemented an alternative system call mechanism to take advantage of SYSENTER/SYSEXIT instructions provided by all Pentium II+ processors. Before going further with this new way of doing it, let's make ourselves more familiar with these instructions.
4.1. SYSENTER/SYSEXIT instructions:
Let's look at the authorized source, Intel manual itself. Intel manual says:
The SYSENTER instruction is part of the "Fast System Call" facility introduced on the Pentium® II processor. The SYSENTER instruction is optimized to provide the maximum performance for transitions to protection ring 0 (CPL = 0). The SYSENTER instruction sets the following registers according to values specified by the operating system in certain model-specific registers.
- CS register set to the value of (SYSENTER_CS_MSR)
- EIP register set to the value of (SYSENTER_EIP_MSR)
- SS register set to the sum of (8 plus the value in SYSENTER_CS_MSR)
- ESP register set to the value of (SYSENTER_ESP_MSR)
Looks like processor is trying to help us. Let's look at SYSEXIT also very quickly:
The SYSEXIT instruction is part of the "Fast System Call" facility introduced on the Pentium® II processor. The SYSEXIT instruction is optimized to provide the maximum performance for transitions to protection ring 3 (CPL = 3) from protection ring 0 (CPL = 0). The SYSEXIT instruction sets the following registers according to values specified by the operating system in certain model-specific or general purpose registers.
- CS register set to the sum of (16 plus the value in SYSENTER_CS_MSR)
- EIP register set to the value contained in the EDX register
- SS register set to the sum of (24 plus the value in SYSENTER_CS_MSR)
- ESP register set to the value contained in the ECX register
SYSENTER_CS_MSR, SYSENTER_ESP_MSR, and SYSENTER_EIP_MSR are not really names of the registers. Intel just defines the address of these registers as:
SYSENTER_CS_MSR 174h
SYSENTER_ESP_MSR 175h
SYSENTER_EIP_MSR 176h
In linux these registers are named as:
/usr/src/linux/include/asm/msr.h:
101 #define MSR_IA32_SYSENTER_CS 0x174
102 #define MSR_IA32_SYSENTER_ESP 0x175
103 #define MSR_IA32_SYSENTER_EIP 0x176
4.2. How does linux 2.6 uses these instructions?
- Linux sets up these registers during initialization itself.
/usr/src/linux/arch/i386/kernel/sysenter.c:
36 wrmsr(MSR_IA32_SYSENTER_CS, __KERNEL_CS, 0);
37 wrmsr(MSR_IA32_SYSENTER_ESP, tss->esp1, 0);
38 wrmsr(MSR_IA32_SYSENTER_EIP, (unsigned long) sysenter_entry, 0);Please note that 'tss' refers to the Task State Segment (TSS) and tss->esp1 thus points to the kernel mode stack. [4] explains the use of TSS in linux as:
The x86 architecture includes a specific segment type called the Task State Segment (TSS), to store hardware contexts. Although Linux doesn't use hardware context switches, it is nonetheless forced to set up a TSS for each distinct CPU in the system. This is done for two main reasons:
- When an 80 x 86 CPU switches from User Mode to Kernel Mode, it fetches the address of the Kernel Mode stack from the TSS.
- When a User Mode process attempts to access an I/O port by means of an in or out instruction, the CPU may need to access an I/O Permission Bitmap stored in the TSS to verify whether the process is allowed to address the port.
So during initialization kernel sets up these registers such that after SYSENTER instruction, ESP is set to kernel mode stack and EIP is set to sysenter_entry.
- Kernel also setups system call entry/exit points for user processes. Kernel creates a single page in the memory and attaches it to all processes' address space when they are loaded into memory. This page contains the actual implementation of the system call entry/exit mechanism. Definition of this page can be found in the file
/usr/src/linux/arch/i386/kernel/vsyscall-sysenter.S. Kernel calls this page virtual dynamic shared object (vdso). Existence of this page can be confirmed by looking atcat:/proc/`pid`/mapsslax ~ # cat /proc/self/maps
08048000-0804c000 r-xp 00000000 07:00 13 /bin/cat
0804c000-0804d000 rwxp 00003000 07:00 13 /bin/cat
0804d000-0806e000 rwxp 0804d000 00:00 0 [heap]
b7ea0000-b7ea1000 rwxp b7ea0000 00:00 0
b7ea1000-b7fca000 r-xp 00000000 07:03 1840 /lib/tls/libc-2.3.6.so
b7fca000-b7fcb000 r-xp 00128000 07:03 1840 /lib/tls/libc-2.3.6.so
b7fcb000-b7fce000 rwxp 00129000 07:03 1840 /lib/tls/libc-2.3.6.so
b7fce000-b7fd1000 rwxp b7fce000 00:00 0
b7fe7000-b7ffd000 r-xp 00000000 07:03 1730 /lib/ld-2.3.6.so
b7ffd000-b7fff000 rwxp 00015000 07:03 1730 /lib/ld-2.3.6.so
bffe7000-bfffd000 rwxp bffe7000 00:00 0 [stack]
ffffe000-fffff000 ---p 00000000 00:00 0 [vdso]For binaries using shared libraries, this page can be seen using ldd also:
slax ~ # ldd /bin/ls
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib/tls/librt.so.1 (0xb7f5f000)
...Observe linux-gate.so.1. This is no physical file. Content of this vdso can be seen as follows:
==> dd if=/proc/self/mem of=linux-gate.dso bs=4096 skip=1048574 count=1
1+0 records in
1+0 records out
==> objdump -d --start-address=0xffffe400 --stop-address=0xffffe414 linux-gate.dso
ffffe400 <__kernel_vsyscall>:
ffffe400: 51 push %ecx
ffffe401: 52 push %edx
ffffe402: 55 push %ebp
ffffe403: 89 e5 mov %esp,%ebp
ffffe405: 0f 34 sysenter
...
ffffe40d: 90 nop
ffffe40e: eb f3 jmp ffffe403 <__kernel_vsyscall+0x3>
ffffe410: 5d pop %ebp
ffffe411: 5a pop %edx
ffffe412: 59 pop %ecx
ffffe413: c3 retIn all listings, ... stands for omitted irrelevant code.
- Initiation: Userland processes (or C library on their behalf) call __kernel_vsyscall to execute system calls. Address of __kernel_vsyscall is not fixed. Kernel passes this address to userland processes using AT_SYSINFO elf parameter. AT_ elf parameters, a.k.a. elf auxiliary vectors, are loaded on the process stack at the time of startup, alongwith the process arguments and the environment variables. Look at [1] for more information on Elf auxiliary vectors.
After moving to this address, registers %ecx, %edx and %ebp are saved on the user stack and %esp is copied to %ebp before executing sysenter. This %ebp later helps kernel in restoring userland stack back. After executing sysenter instruction, processor starts execution at sysenter_entry. sysenter_entry is defined in
/usr/src/linux/arch/i386/kernel/entry.Sas: (See my comments in [ ])179 ENTRY(sysenter_entry)
180 movl TSS_sysenter_esp0(%esp),%esp
181 sysenter_past_esp:
182 sti
183 pushl $(__USER_DS)
184 pushl %ebp [%ebp contains userland %esp]
185 pushfl
186 pushl $(__USER_CS)
187 pushl $SYSENTER_RETURN [%userland return addr]
188
....
201 pushl %eax
202 SAVE_ALL [pushes registers on to stack]
203 GET_THREAD_INFO(%ebp)
204
205 /* Note, _TIF_SECCOMP is bit number 8, and so it needs testw and not testb */
206 testw $(_TIF_SYSCALL_EMU|_TIF_SYSCALL_TRACE|_TIF_SECCOMP|_TIF_SYSCALL_AUDIT),
TI_flags(%ebp)
207 jnz syscall_trace_entry
208 cmpl $(nr_syscalls), %eax
209 jae syscall_badsys
210 call *sys_call_table(,%eax,4)
211 movl %eax,EAX(%esp)
...... - Inside sysenter_entry: between line 183 and 202, kernel is saving the current state by pushing register values on to the stack.
Observe that $SYSENTER_RETURN is the userland return address as defined inside
/usr/src/linux/arch/i386/kernel/vsyscall-sysenter.Sand %ebp contains userland ESP as %esp was copied to %ebp before calling sysenter. - After saving the state, kernel validates the system call number stored in %eax. Finally appropriate system call is called using instruction:
210 call *sys_call_table(,%eax,4)
This is very much similar to old way.
- After system call is complete, processor resumes execution at line 211. Looking further in sysenter_entry definition:
210 call *sys_call_table(,%eax,4)
211 movl %eax,EAX(%esp)
212 cli
213 movl TI_flags(%ebp), %ecx
214 testw $_TIF_ALLWORK_MASK, %cx
215 jne syscall_exit_work
216 /* if something modifies registers it must also disable sysexit */
217 movl EIP(%esp), %edx (EIP is 0x28)
218 movl OLDESP(%esp), %ecx (OLD ESP is 0x34)
219 xorl %ebp,%ebp
220 sti
221 sysexit - Copies value in %eax to stack. Userland ESP and return address (to-be EIP) are copied from kernel stack to %edx and %ecx respectively. Observe that the userland return address, $SYSENTER_RETURN was pushed on to stack in line 187. After that 0x28 bytes have been pushed on to the stack. That's why 0x28(%esp) points to $SYSENTER_RETURN.
- After that SYSEXIT instruction is executed. As we know from previous section, sysexit copies value in %edx to EIP and value in %ecx to ESP. sysexit transfers processor back to ring 3 and processor resumes execution in userland.
5. Some Code
#include <stdio.h>
int pid;
int main() {
__asm__(
"movl $20, %eax \n"
"call *%gs:0x10 \n" /* offset 0x10 is not fixed across the systems */
"movl %eax, pid \n"
);
printf("pid is %d\n", pid);
return 0;
}
This does the getpid() system call (__NR_getpid is 20) using __kernel_vsyscall instead of int 0x80. Why %gs:0x10? Parsing process stack to find out AT_SYSINFO's value can be a cumbersome task. So, when libc.so (C library) is loaded, it copies the value of AT_SYSINFO from the process stack to the TCB (Thread Control Block). Segment register %gs refers to the TCB.
Please note that the offset 0x10 is not fixed across the systems. I found it out for my system using GDB. A system independent way to find out AT_SYSINFO is given in [1].
Note: This example is taken from http://www.win.tue.nl/~aeb/linux/lk/lk-4.html after little modification to make it work on my system.
6. References
Here are some references that helped me understand this.
- About Elf auxiliary vectors By Manu Garg
- What is linux-gate.so.1? By Johan Peterson
- This Linux kernel: System Calls By Andries Brouwer
- Understanding the Linux Kernel, By Daniel P. Bovet, Marco Cesati
- Linux Kernel source code
Trackback Address :: http://insidexino.net/trackback/2757260
VMWare에서 해상도가 맞지 않을때.. :: 2007/05/21 11:21
/etc/X11/xorg.conf를 아래 내용으로 바꿔준다.
xorg.conf# Xorg configuration |
출처 : http://www.vmware.com/community/
Trackback Address :: http://insidexino.net/trackback/2757256
Port to Linux ( 리눅스로 포팅을 하자! ) :: 2006/12/17 21:10
Preface
Windows 프로그램을 리눅스로 포팅을 할때 가장 문제가 되는 것은 프로세스 쓰레드 관련 함수와 각종 IPC들이다. 소켓이나 기본적인 함수들은 모두 같이 사용이 되거나 용례가 비슷한데 반해서 이들은 완전히 독립적으로 동작이 되기 때문에 설계 자체를 바꿔야 하는 경우도 있다. 이를 좀더 쉽게 하기 위해서 각각에 대해서 어떻게 포팅을 해야 하는지를 정리해 보았다.
Process & Thread
Windows와 Linux가 process와 thread에 관련된 내부적 구조체 및 동작 방식은 완전히 다르다. 하지만, 이들을 조작하는 함수에는 거의 차이가 없다. 함수에 따라 거의 1:1로 변환이 가능하다.
| Windows | Linux |
CreateProcess() |
fork()exec() |
TerminateProcess() |
kill() |
WaitForSingleObject() |
waitpid() |
SetThreadpriority()GetThreadPriority() |
setpriority()getpriority() |
GetCurrentProcessID() |
getpid() |
Exitprocess() |
exit() |
CreateThread() |
pthread_create() |
ThreadExit() |
pthread_exit() |
Events
Evnet는 Windows에서 특정 사건이 발생했음을 알려주기 위해서 사용한다. Linux에서는 이를 위한 특별한 장치가 존재하지 않으므로 semaphore를 이용해서 이를 구현해 준다. 다만 초기화시에 초기값을 0으로 주기만 하면 된다.
| Windows | Linux |
CreateEvent() |
sem_init() |
SetEvent() |
sem_post() |
WaitForSingleObject() |
sem_wait() |
CloseHandle() |
sem_destroy() |
Semaphore
Semaphore는 Windows와 Linux의 용례가 비슷하다. Linux에서는 Windows의 event구현과 비슷하게 하면 되지만, 초기값을 얼마로 가지느냐만 다르게 설정을 해 주면 된다.
| Windows | Linux |
CreateSemaphore() |
sem_init() |
ReleaseSemaphore() |
sem_post() |
WaitForSingleObject() |
sem_wait() |
CloseHandle() |
sem_destroy() |
Critical Section
Critical Section은 Windows에서 여러 쓰레드가 접근하지 못하는 임계 영역을 지정하기 위해서 사용된다. Critical Section은 Windows에서는 User객체로만 사용되며, 리눅스에서는 mutex로 구현을 해 주면 된다.
| Windows | Linux |
InitializeCriticalSection() |
pthread_mutex_init() |
DeleteCriticalSection() |
pthread_mutex_destroy() |
EnterCriticalSection() |
pthread_mutex_lock() |
LeaveCriticalSection() |
pthread_mutex_unlock() |
Mutex
Mutex가 Windows의 Critical Section과의 차이점은 User영역 개체인지 Kernel 개체인지의 차이이다. Critical Section은 User모드 개체이기 때문에 하나의 프로세스 안에서 쓰레드 간의 임계영역 설정에 사용이 되지만, Mutex는 커널 모드 개채이므로 여러 프로세스간에 임계 영역 설정에 사용할 수 있다. Linux에서는 프로세스와 쓰레드간의 차이가 없으므로 mutex로만 구현되어 있다.
| Windows | Linux |
CreateMutex() |
pthread_mutex_init() |
CloseHandle() |
pthread_mutex_destroy() |
WaitForSingleObject() |
pthread_mutex_lock() |
ReleaseMutex() |
pthread_mutex_unlock() |
Wrap up
Windows에서 Linux로 포팅할때 가장 신경써야 할 부분은 WaitForSingleObject와 WaitForMultipleObjects이다. 이 함수를 Linux로 가지고 갈때는 인자가 되는 핸들이 어느것이냐에 따라서 어떤 함수로 바꿔야 하는지가 결정이 되기 때문이다. 특히나 WaitForMultipleObjects에서 여러개의 핸들을 기다리면서 특정 이벤트가 일어나면 처리를 하는 경우에, 프로세스, 쓰레드, 뮤텍스, 소켓 등을 동시에 기다리면 이것들을 각기 다른 함수들로 분리를 해 줘야 하는데 이것은 정말 골치 아픈 일이다. 만약에 포팅을 염두에 두고 있다는 이러한 점에 각별히 신경을 쓰고 프로그래밍을 하도록 하자.
Trackback Address :: http://insidexino.net/trackback/2757238
Linux Function Reference :: 2006/12/05 01:59
리눅스 함수가 잘 정리되어 있는 레퍼런스 페이지.
http://jamesthornton.com/linux/man/
http://www.die.net/doc/linux/
Trackback Address :: http://insidexino.net/trackback/2757231
라이브러리 찾기 :: 2006/11/22 19:32
특정한 라이브러리를 써서 컴파일을 하다가 보면 링크 에러가 날때가 있다.
이럴때는 라이브러리를 링크해주어야 한다.
라이브러리를 찾을때는 아래와 같이한다.
# nm -A /usr/lib/*.a 2>/dev/null |grep [function_name] |
nm 명령어로 모든 함수명을 출력한다.
2>/dev/null은 오류 메시지를 표시 하지 않는다는 뜻이다.
1은 표준 출력 2는 오류 출력을 의미하며 이걸 null device로 리다이렉트 시키면 출력이 되지 않는다.
여기서 원하는 라이브러리 명을 찾았다면 이것을 링크시에 추가시켜 주면 된다.
만약에 찾은 라이브러리 명이 pthread라면 앞에 -l을 붙여서 컴파일을 해 주면 된다.
# gcc -o hello hello.c -lpthread |
Trackback Address :: http://insidexino.net/trackback/2757222
QT/X11 설치 :: 2006/11/15 19:09
QT/X11의 간단한 설치법이다. 웹을 찾아서 정리한 내용이므로 틀리수도 있다.
버젼은 3.x를 기준으로 하였다.
2.x는 qmake가 없으므로 progen과 tmake를 가지고 컴파일을 해 주어야한다.
기본 폴더는 /qt에 qt-x11-free-3.3.7.tar.bz2 파일을 가지고 있다고 생각하고 시작을 해 준다.
1.파일의 복사
[root@localhost qt]# tar xjf qt-x11-free-3.3.7.tar.bz2 |
- 생성된 디렉토리의 이름을 바꾸어준다 (정해진것은 아니다.)
[root@localhost qt]# mv qt-x11-free-3.3.7 qte |
2.설정을 해준다.
[root@localhost qt]# vi qte.env |
QTDIR=/qt/qte
PATH=$QTDIR/bin:$PATH
MANPATH=$QTDIR/doc/man:$MANPATH
LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
export QTDIR PATH MANPATH LD_LIBRARY_PATH
:wq (저장하고 빠져나온다)
여기서 qte.env의 내용을 부팅시 적용하게 할수도 있지만,
그럴경우 readhat 9.0에서 로그인시에 쉘이 죽는 문제가 생길수도 있다.
3.설정을 적용한다.
[root@localhost qt]# cd qte |
4.configuration
[root@localhost qte]# ./configure |
라이센스를 물어보면 'yes'라고 입력한다.
5.컴파일
[root@localhost qte]# make |
컴파일을 하게 되며 시간이 걸린다.
6.설치
[root@localhost qte]# make install |
root가 아니라면 su -c "make install" 를 해준다.
7.설치가 완료 되었다.
----------------------------------------------------------------------
QT designer에서 만든 UI를 컴파일하기.
1.프로젝트 파일 생성
# qmake -project |
UI파일이 있는 폴더로 가서 qmake -project 를 실행해준다.
이 과정은 그 폴더에 있는 모든 파일을 이용해서 project파일을 만들어준다.
별도의 옵션을 주면 프로젝트에 추가할 파일만 설정할수 있지만 해보지 않아서 모르겠다.
2.Makefile생성
# qmake -makefile |
이것을 해 주면 project파일에 있는 파일을을 가지고 Makefile을 만들어준다.
3.컴파일
# make |
이것으로 컴파일이 완료된다.
Trackback Address :: http://insidexino.net/trackback/2757220
