우분투 12.04를 설치 후 oracle java와 eclipse를 설치 하였다. oracle java부터 설치하였으며, eclipse 를 설치하고 실행하면 다음과 같은 error가 발생한다.




로그파일을 열어 보면 다음과 같다.




SWT library를 로드할 수 없다는 에러 메시지가 있었다.


다음과 같이 설정한 후 이 문제는 해결되었다.

$ cd ~/.swt/lib/linux/x86

$ ln -s /usr/lib/jni/* .





저작자표시

우분투 12.04 설치 후 다음의 과정으로 oracle java를 설치 하였다.


$ sudo add-apt-repository ppa:webupd8team/java

$ sudo apt-get update

$ sudo apt-get install oracle-jdk7-installer



java -version 명령으로 설치를 확인할 수 있다.




저작자표시


우분투 12.04에서 vmware 8.0.3 버젼을 설치하고, windows xp professional sp3 버젼을 설치 하였다.


한/영 키가 먹통인 현상이 발생하였는데, 다음과 같이 변경하니 정상 동작하였다.


/etc/vmware/config 파일에 다음의 내용을 추가하였다.


xkeymap.keysym.Hangul = 0x0f2

xkeymap.keysym.Hangul_Hanja = 0x0f1


위 설정 파일을 변경 한 후 vmware 서비스를 재시작하면 된다.


$ sudo /etc/init.d/vmware restart


저작자표시


우분투 12.04 에서 vmware 8.0.3 버젼을 설치한 후 처음 실행시키면  다음의 에러가 발생한다.


VMWare Virtual Network Devcie Error





http://weltall.heliohost.org/wordpress/2012/04/01/vmware-workstation-8-0-2player-4-0-2-and-7-1-x3-1-x-fix-for-linux-kernel-3-4-0/


위 링크로 가서 패치를 적용하면 위의 문제를 해결할 수 있다.



간단히 설명하자면 아래의 패치를 다운받은 후 적용하면 된다.


vmware802fixlinux340.tar.gz


먼저 아래 파일의 압축을 해제 한다.

$ tar xvzf vmware802fixlinux340.tar.gz


압축을 해제 하면 "patch-modules_3.4.0.sh" / "vmware3.4.0.patch" 파일 두 개가 생성 될 것이다.


vi 로 patch-modules_3.4.0.sh 을 편집한다.

vmreqver=8.0.2 => vmreqver=8.0.3 으로 변경한다.


변경 후 patch-modules_3.4.0.sh 패치를 실행하면, 패치 완료 된다.

$ sudo ./patch-modules_3.4.0.sh









저작자표시

svn 레포지터리 dump


$ svnadmin dump [repository directory path] > [repository.dump]


$ svnadmin dump -r [n] > [repository_n.dump]                    // 리비전 n부터 백업

$ svnadmin dump -r [n]:[m] > [repository_nm.dump]            // 리비전 n에서 m까지 백업



svn 레포지터리 적재


레포지터리 생성

$ svnadmin create [repository name]


데이터 적재

$ svnadmin load [repository name] < [repository.dump]







저작자표시

hexedit 사용법

  /   -> search

 F9   ->블록지정

 F7  ->블록복사

 F11 ->복사된 내용을 파일로 저장



[출처] 포렌식 4|작성자 미키

저작자표시


Canonical

터미널 입력은 새줄문자('\n'), EOF, 또는 EOL 문자들로 종료되는 한 라인으로 처리 된다. 어떤 입력도 사용자에 의해 한 라인 전체의 입력이 종료되기 전에 읽혀질 수 없고, read 함수는 얼마나 많은 바이트가 요청되었는지에 상관없이, 많아야 오직 한 줄의 입력을 반환할 뿐이다.

NonCanonical

문자들은 라인들로 묶여지지 않고, ERASE와 KILL 프로세싱은 수행되지 않는다. 비정규입력에서(NonCanonical) 읽혀진 바이트들은 MIN과 TIME을 설정함으로 인해서 제어 된다.

MIN -> 읽어 들은 문자 갯수

TIME -> MIN에서 읽어 들인 문자 갯수가 충족되지 않을시 설정한 시간에 OUT



int tcgetattr(int fd, struct termios *p)

파일기술자와 연관된 터이널 디바이스의 속성을 시험하는데 사용된다. 그 속성은 구조체 p가 가리키는 곳으로 반환된다.


int tcsetattr(int fd, int when, const struct  termios *p)

파일기술자와 연관된 터미널 디바이스의 속성을 설정한다. 새로운 속성들은 구조체  p가 가리키고 있는 곳으로부터 가져온다. when 인수는 이미 큐된(큐에 저장되어 있는) 입력과 출력을 어떻게 취급할 것인지를 정하는 것으로 다음 값들 중 하나를 사용할 수 있다.

TCSANOW

즉시 속성을 변경시켜라.

TCSADRAIN

큐에 저장된 출력이 쓰여질 때까지 기다린 후에 속성을 변경하라. 당신은 변경하는 파라미터가 출력에 영향을 미칠 때 이 옵션을 사용한다.

TCSAFLUSH

이것은 TCSADRAIN과 같지만, 큐에 저장된 입력을 버린다.

TCASASOFT

위에 있는 어떤 것과도 덧붙여 사용할 수 있는 플래그 비트이다. 이것은 하드웨어에 대한 상황의 변경을 금지하기 위한 것이다. 이것은 BSD 확장이다. BSD가 아닌 시스템에서는 아무런 영향을 받지 않는다.



O_NOTTY : open 하려는 process에 대해 device를 controlling terminal로 할당하지 말라는 것이다.

controlling terminal : process가 foreground이며, device가 현재 terminal을 제어함을 의미



/////////////////////////////////////////////////////////////////////////////////////////////////////////////////


c_cc에서 사용가능한 매크로

정규모드(canonical)에서 배열의 인덱스

 

-VEOF : EOF 문자

-VEOL : EOL 문자

-VERASE : ERASE 문자

-VINTR : INTR 문자

-VKILL : KILL 문자

-VQUIT : QUIT 문자

-VSUSP : SUSP 문자

-VSTART : START 문자

-VSTOP : STOP 문자

 

비정규 모드(non-canonical)에서 배열의 인덱스는 다음과 같다

-VINTR : INTR 문자

-VMIN : MIN 문자

-VQUIT : SUSP 문자

-VTIME : TIME 값

-VSTART : START 문자

-VSTOP : STOP 문자

특수 문자와 비정규 모드에서의 MIN과 TIME은 입력 문자를 발전적으로 처리하는데 있어서 매우 중요하다.

 

TIME 과 MIN 값 - 비정규 모드에서 사용되고, 입력으로 부터 읽어들이기를 제어 하는데 함께 사용된다. 프로그램이 터미널과 연관된 파일 기술자로 부터 읽기를 시도할때 일어나는 사건을 제어한다.

-MIN=0이고 TIME=0 : read는 항상 즉시 리턴한다.

-MIN=0이고 TIME>0 : read는 읽어들일 문자가 있거나, TIME/10초가 경과했을 때 리턴한다.

-MIN>0이고 TIME=0 : read는 MIN개의 문자를 읽을 때까지 기다릴 것이고, 읽어들인 문자의 개수를 리턴할 것이다. 파일의 끝이라면 0을 리턴한다.

-MIN>0이고 TIME>0 : read가 호출 되었을때 읽어들일 문자를 기다린다. 첫 번째 문자가 도착하면이제 타이머가 작동한다. read는 MIN개의 문자를 읽어들였거나 타이머가 TIME/10초 만큼 경과했을 때에 리턴할 것이다.


출 처 : http://hano1030.springnote.com/pages/2748626.xhtml







저작자표시

리눅스 커널 스택에 대해서 궁금합니다.

1.커널 스택은 프로세스마다 하나씩 생성되는 건가요 ?
2.커널 스택에는 어떤 정보가 들어가게 되나요 ? (얼핏 알기로는 해당 프로세스에 인터럽트가 걸리면 이에 필요한 정보들을 커널 스택에 저장해 놓고 사용한다고 하던데요...)
3.프로세스 하나는 4기가의 가상 공간을 사용한다고 들었습니다. 이 중에서 0~3기가 까지는 응용프로그램에서 사용하는 공간이고 3~4기가는 커널이 사용하는 공간이라고 알고 있는데요...
여기서 3~4기가 공간과 커널 스택이 어떠한 연관 관계가 있나요?

고수님들의 답변 부탁드립니다.

----------------------------------------------------------------------------------------------------------------------------------------


1. 커널 스택은 프로세스마다 하나씩 생성됩니다.
일반적인 프로세스는 User Mode 스택과 Kernel Mode 스택을 각각 하나씩 가지고 있습니다.
User Mode에서 Kernel Mode로의 전환은 시스템호출이나 인터럽트가 발생하면 일어납니다.
즉, esp 레지스터는 프로세스가 User Mode이면 User Mode 스택의 top을 가르키다가
Kernel Mode로 전환이 되면 Kernel Mode 스택의 top을 가르킵니다.

2. Kernel Mode 스택은 적어도 다음 두가지 목적으로 사용됩니다. 다른 사용처는 딱히 생각나지 않네요.
가. Kernel Mode로 전환된 프로세스는 언젠간 다시 User Mode로 되돌아가야 합니다.
따라서 User Mode로 전환하기위해 필요한 정보 중 일부를 저장합니다. (일부는 다른 곳에 저장합니다.)
나. Kernel Mode에서 함수를 호출하게 되면 그 함수의 지역변수는 Kernel Mode 스택에서 할당됩니다. (User Mode에서 함수를 호출하면 지역변수가 User Mode 스택에 할당되는 것과 같습니다.)
참고로 80x86 아키텍처에서 커널 스택으로 할당된 공간의 크기는 8KB로 고정되어있습니다. 프로세스 생성때 한번 할당되어 작아지지도 커지지도 않습니다. 따라서 커널에 있는 함수에서는 지역변수를 많이 할당하거나 재귀 함수 호출을 하면 좋지 않습니다.

3. 어떻게 설명드려야할 지 상당히 난해한 질문이군요.
커널은 주소 공간 3~4GB를 사용합니다. Kernel Mode 스택은 Kernel Mode에서만 사용되므로 커널 주소 공간에서 할당됩니다.
즉, User Mode 스택을 가르키는 esp 값을 읽어보면 0GB~3GB 사이의 값을 가지고 Kernel Mode 스택을 가르키는 esp 값을 읽어보면 3~4GB 사이의 값을 가지게 됩니다.

4. 기타

가. 프로세스의 User Address Space는 프로세스마다 각각 다르지만, Kernel Address Space는 모든 프로세스가 동일하게 봅니다. 즉, 프로세스 A와 프로세스 B의 특정 가상주소 (예를 들면 0xa0001000) 은 서로 다른 물리주소로 맵핑될 수 있습니다. 하지만 특정 커널 공간 주소 (예를 들면 0xc0001000) 는 모든 프로세스에서 동일한 물리주소로 맵핑됩니다.
이를 위해서 커널은 kernel master page table (swapper_pg_dir 변수가 가르킴)을 관리하고, 필요할 때마다 특정 엔트리를 kernel master page table에서 해당 프로세스의 page table에 복사를 합니다 -- 이런 작업은 Kernel Mode에서 페이지 폴트가 발생했을 때 페이지 폴트 핸들러가 수행합니다.

나. 시스템호출, 인터럽트 핸들러, 커널 모듈 등은 임의의 프로세스의 context를 이용합니다. 예를 들어, 프로세스 A가 User Mode에서 수행되고 있을 때 timer interrupt가 발생하는 경우 Kernel Mode로 전환하여 timer interrupt service routine을 수행하게 되는데 이때 프로세스 A의 page table과 Kernel Mode 스택을 빌어 쓰게됩니다.
Timer interrupt와 프로세스 A와는 별다른 연관이 없지만 interrupt 발생시점에 프로세스 A가 CPU를 점유하고 있었기 때문에 부하가 큰 context switch 등을 따로 하지 않고 프로세스 A의 context를 그대로 이용하는 것입니다. 다만 커널 모듈 등이 기능의 일부를 따로 커널 쓰레드를 생성하여 구현한 경우라면 그 커널 쓰레드의 context를 사용하겠죠.

출 처 : http://kldp.org/node/73308

저작자표시
커널 2.6.36에서는 file_operations 에서 ioctl 이 제거되었고
대신에 unlocked_ioctl 과 compat_ioctl 이 사용되게 되었다.

unlocked_ioctl 과 compat_ioctl 은 2.6.11 에서 처음 추가되었는데 그 이유는 BKL 이슈에 대한 것때문이다.
BKL 은 Big Kernel Lock 의 약자인데 커널에서 락을 이용하지 않게 하려는 시도가 꾸준히 있어왔다.

그 이유는 커널에서 특히 SMP 구조에서 락에 들어가는 비용이 너무 많기 때문이며, 효율적으로 사용하기 위해서다.
그런 이유로 도입된 것이 RCU(read copy update) 이다.

어쨋든 ioctl 이 호출되면 커널 락이 수행되고 자동적으로 SMP 구조에서는 비효율을 가져오고 있었다.
그래서 사용되는 것이 unlocked_ioctl 이다.

쉽게 얘기해서 모든 CPU에 대해서 lock 을 걸던것을 개별적인 lock 을 걸수 있게끔 바꾼것이다.

간단히 어떻게 해야 하는지 확인하자.

static int extio_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg)
{
int param_size;
unsigned int value;

if(_IOC_TYPE(cmd) != IOCTL_FN_ALARM) return -EINVAL;
if(_IOC_NR(cmd) >= ALARM_FN_MAXNR) return -EINVAL;

param_size = _IOC_SIZE(cmd);
if(param_size) {
if(_IOC_DIR(cmd) & _IOC_READ) {
if (unlikely(!access_ok(VERIFY_WRITE, (void *)arg, param_size)))
return -EFAULT;
}
if(_IOC_DIR(cmd) & _IOC_WRITE) {
if (unlikely(!access_ok(VERIFY_READ, (void *)arg, param_size)))
return -EFAULT;
}
}

switch (cmd)
{
caseFN_IOCTL_GET:
{
copy_to_user((unsigned int *)arg, &value, sizeof(unsigned int));
return 0;
}
caseFN_IOCTL_PUT:
{
copy_from_user(&value, (unsigned int *)arg, sizeof(unsigned int));
return 0;
}
}

return -ENOTTY;
}

이것이 전통적인 방식의 ioctl 이다.
이제는 여기서 이렇게 바꾸어야 한다.
static DEFINE_MUTEX(extio_mutex);
static int extio_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg)
{
int param_size;
unsigned int value;

if(_IOC_TYPE(cmd) != IOCTL_FN_ALARM) return -EINVAL;
if(_IOC_NR(cmd) >= ALARM_FN_MAXNR) return -EINVAL;

param_size = _IOC_SIZE(cmd);
if(param_size) {
if(_IOC_DIR(cmd) & _IOC_READ) {
if (unlikely(!access_ok(VERIFY_WRITE, (void *)arg, param_size)))
return -EFAULT;
}
if(_IOC_DIR(cmd) & _IOC_WRITE) {
if (unlikely(!access_ok(VERIFY_READ, (void *)arg, param_size)))
return -EFAULT;
}
}

mutex_lock(&extio_mutex)
switch (cmd)
{
caseFN_IOCTL_GET:
{
copy_to_user((unsigned int *)arg, &value, sizeof(unsigned int));
mutex_unlock(&extio_mutex);
return 0;
}
caseFN_IOCTL_PUT:
{
copy_from_user(&value, (unsigned int *)arg, sizeof(unsigned int));
mutex_unlock(&extio_mutex);
return 0;
}
}

mutel_unlock(&extio_lock);
return -ENOTTY;
}
세가지가 추가되었다.
static DEFINE_MUTEX(extio_mutex);
mutex_lock(&extio_mutex);
mutex_unlock(&extio_mutex);

이제 동일한 ioctl 에 접근하는게 아니라면 SMP 구조에서도 mutex 로 보호되는 상태만 아니면 
동시에 ioctl 에 접근할수 있게 되었다.
또 하나 있는게 compat_ioctl 인데 이것은 32bit 와 64bit 간의 호환성을 갖도록 설계된 ioctl 이다.
자세한 것은 다음에 다시 설명하도록 합니다.

출처 :  http://forum.falinux.com/zbxe/?document_srl=553645
저작자표시
printk()

커널 함수에서 사용되는 출력 함수이다.
printf와의 차이는 메시지 기록관리를 위한 로그레벨을 지정할 수 있다는 것이다.

 로그레벨 명령어 의미
"<0>"  KERN_EMERG 시스템이 동작하지 않는다.
 "<1>"  KERN_ALERT 항상 출력
"<2>"  KERN_CRIT 치명적인 정보
 "<3>" KERN_ERR  오류 정보
 "<4>"  KERN_WARNING 경고 정보 
 "<5>"  KERN_NOTICE 정상적인 정보 
 "<6>"  KERN_INFO 시스템 정보 
 "<7>"  KERN_DEBUG  디버깅 정보

위처럼 로그레벨을 지정하는 이유는 kernel source 내에서 원하는 정보만 출력할 수 있게 함이다.

사용법은 다음과 같다

 printk(KERN_ERR"This is KERN_ERR option\n");

다음 명령을 실행해보면 현재의 로그레벨을 확인 할 수 있다.

 $cat /proc/sys/kernel/prink 
      7     4     1     7

[7] : 현재 로그레벨
       이 레벨보다 높은 메시지(숫자가 작은 수)만 출력을 해준다.
[4] : 기본 로그레벨
       printk()함수를 입력하면서 별도로 로그레벨을 입력하지 않을 경우
[1] : 최소 로그레벨
       부여할 수 있는 최소 로그레벨이다.
       이 값이 1이라면 우리가 printk 함수를 입력하면서 0을 부여할 수 없다.
[7] : 부팅시 로그레벨
        부팅시 출력될 레벨을 지정해주는 것이다.

출력되지 않았을 경우 다음과 같은 명령어로 로그버퍼에 기록된 내용을 볼 수 있다. (출력되지 않은 메시지도 볼 수 있음)
dmesg
# cat /proc/kmsg

출 처 :  http://ok2513.tistory.com/9  
저작자표시

+ Recent posts

티스토리툴바