커널에서 전역변수라는 errno 이거 하나땜에 진짜 징하게 고민중임.
일단, 심볼이라는걸 .out 이랑 .so 이런애들만 가지고 정리해놨는데
갑자기 새로운 구성원인 커널 이 등장해버리니까...
일단,
errno 보고
뭐야 이거 프로세스별로 시스템콜의 결과물을 저장하는게 다 다르니까,
int errno 이거보면 커널영역의 데이터(심볼/변수)라고 모두가 공유하는건 아니겠다.
했는데,
errno 의 구현이 매크로로 *geterrno() 이런식으로 function call 인걸 알고나니까
다시금, 모든 커널데이터는 공유된다는 추측에 힘이 쏠리고 있음.
그리고,
printf 같은애들도 그렇고 errno 도 그렇고,
어떻게 매크로가 symbol로 정의된건지는 신기함.
아마 어셈블리 레벨에서 OS만드신분들이 직접 때려넣으신거 아닌가 싶음
다가능한건 아니고 헤더파일에 명시된 심볼만 접근가능. errno는 어떤 심볼인지 모르겟네 커널ㅂ분석은 목적을 잡근ㄴ게 중요함 드라이버 연동인지, 스케줄러인지, 가상메모리인지 ㅇㅇ 안그럼 겁나해맴
심볼 매핑하는건 loader가 할꺼임 심볼에 맞는 주소를 작성된 커널모듈의 어셈블리코드에 박는거지
커널심볼이라는게 따로 있는건 아닐거같다는 생각이 들고 있기도 해. 인클루드한게 커널을 건드리는 느낌이 나니까 이게 내가 지금 헷갈리는건데, 그게 내부구현이 시스템콜이라면, 이게 인클루드라는것도 결국에는 동적 라이브러리의 심볼을 가져오는걸테니까, 커널쪽의 심볼이 아니라 해당 동적 라이브러리의 심볼일거같음
커널심볼은 커널모듈만 접근가능
ㅇㅇㅇㅇ ㄳ. 이게 맞는거같음. 내가 갑자기 임의의 프로세스에 대해서 커널들의 심볼도 알아야하나? 뭐 이런식으로 잘못 오해했는데, 다행히 세계관 확장은 안해도 될거같다
이게 가능한 이유는 모든 커널모듈들이 같은 가상주소공간에 적재되기 떄문임
이해했음. 각각의 프로세스가 모~든 커널영역을 메모리매핑받는건지, 아니면 각각이 맵핑받는 영역이 다를지는 몰라도, 하나의 커널영역에 해당하는 메모리의 사본은 없다고 이해하면 되는거 맞지?
당연히 그럴거라고 생각했는데, 최근 해당 프로세스가 실행한 시스템콜의 에러가 errno 라는 전역변수에 들어있다는 이야기를 듣고, 뭐야, 커널영역의 전역변수가 프로세스별로 달라져?? 그렇다면 이거는 해당 커널메모리의 복사본들이 여러개있다는거 아녀?? 이렇게 의식의 흐름이 진행됐었음
근데 구글링 해보니까, errno 라는게 int 형 변수가 아니라, geterrno 라는 함수의 호출로 이루어진거보니까 다시 안심임. 커널영역의 메모리(특히 커널스택이 지금 내가 관심삼는부분)은 메모리맵핑으로 공유한다고 생각하면 될거같아. ㅇㅈ?
1. 모든 프로세스는 커널영역을 공유한다. 2. 응용프로세스들은 커널 심볼 접근 불가능 3. 아.. 님이 말하는 심볼들은 응용프로그램들의 표준라이브러리 심볼들임
옙 감사합니다. 인클루드로 참조가능하다는거부터, 표준라이브러리(lib.so) 의 심볼인데 그것이 커널과 관련된다고 제가 착각했다는걸 깨달았어요. 덕분에 명쾌해졌습니다 ㅠㅠ. 인클루드로 참조하는 심볼들에 대해서, 뭐야 얘네들 원래부터 있던 심볼들이고 커널영역에 존재한다는건가?? 뭐 이런식으로 잘못 생각했었네요
더 정확히는 syscall이 맞음 syscall들은 syscall gate를 통해서 kernel에게 request를 날려주는 wrapper임
옙. 제가 변명을 좀 하자면, CS:app 에서 "전역 정수 변수인 errno를 세팅해서 무엇이 잘못되었는지를 나타낸다." 이거를 보고 깜짝 놀란거였어요. 근데 구글링 해보니까, errno 가 매크로로 getter로 구현되어있더라고요. 진짜 심볼은 __geterrno 이고, errno 는 *__geterrno() 를 통해서 동적으로 받아오는것 같습니다.
get_errno는 또 찾아보면 내부에 어셈블리 레벨 syscall 이 구현되어있을거라고 생각중입니다 ㅎㅎ
응원합니당 ㅎㅎ
211.251 : 응원합니당 ㅎㅎ
가상주소공간 별거아님 ㅇㅇ task_Struct 뜯어보면 금방 답나옴
ㅠㅠㅠ 아무래도 입문단계다보니 (운영체제쪽) 너무 시야가 좁고 답답해진거같음. 근데 격려해주셔서 감사합니다