안녕하세요. 커널 강의 잘 듣고있습니다. set_ftrace.sh 스크립트 실행하다가 오류가 발생했는데21 번째 줄 ttw_do_wakeup 이 available_filter_functions에 없는 것으로 판단 됩니다.  do_wakeup 대신 do_activate로 바뀐 거 같은데 맞는 걸까요? 커널 버전은 6.6 입니다!

안녕하세요.이 강의 수강신청 전 강의자료 문의 올렸었는데 답변 달아주신 거 보았습니다.^^물론 실습 위주고, 머릿속에 다 넣는 것이 가장 중요하지만추후에 어떤 형태라도 강의 자료 올려주신다면 더 도움이 될 것 같아 조심스럽게 요청드려봅니다.!최선 다해 들어보겠습니다.감사합니다.

첫번째 인덱스 강의에 브랜치 노드 부분을 생략하고 설명해주셨는데이 브랜치 노드가 부분을 알고 싶습니다.1부터 100까지 int타입의 값이 있는 property_id라는 column에 인덱스를 만들고where property_id=30을 하면30은 브랜치 노드에 있을 것 같은데설명해주신 부분에서는 데이터 포인터는 리프 노드에만 있다고 하셔서 이부분이 머리속에서 해깔립니다. 

- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요! 수업 잘 듣고 있습니다. 수업에서 진행하는 ppt? pdf같은 것은 따로 제공은 안 하고 있는 걸까요? 예제들은 모두 받아서 워크스페이스에 올려두었습니다.

실수 방지 드라이버 만들기에서 debugfs 파일을 추가하고 Makefile 수정 후 build.sh 스크립트로 재빌드 하였는데, 처음부터 다시 빌드가 되어서 시간이 너무 오래걸리는 것 같아 질문 드립니다. 강의 영상에서는 변경 부분만 빌드 되는것으로 보입니다. 빌드 환경 점검 방법이 있을까요?감사합니다. 

커널 코드 실행 중 인터럽트가 발생한 경우에는 thread_info 구조체의 preemption_count 값을 통해 preemptive schedule 가능 여부를 판단하고, 유저 코드 실행 중에 발생한 경우에는 flags 값을 통해 preemptive schedule 가능 여부를 판단하는 것을 이해했는데, 둘이 왜 확인 방법이 다른지 궁금합니다

링크드리스트의 경우어레이에 비하면 cud의 시간복잡도가 더 좋아서 O(1)이라고 해주셨는데요,( 해당 노드 참조주소만 바꾸면되니까 )  근데 생각해보면 n번째 노드 다음의 데이터를 삭제하거나 추가하거나 삭제하려고할때  해당 노드까지는 찾아가서 포인터(다음노드 주소)를 찾아야하면 결국은 crud 전부다 시간복잡도가 o(n)일 것 같다고 생각이 드는데 어떻게 이해를 하면 될까요?

메모리 관리자는 어디에 위치해있나요? cpu 와 메모리 관리자는 따로 존재한다는 위키를 확인했습니다!그럼 Segment Table Base Register이랑 Page Table Base Register은 메모리 관리자 안에 있다는 강의를 봤거든요. 어떻게 그렇게 될까요..?메모리와 연결되어 있기때문에 STBR이랑 PTBR이 메모리관리자 안에 있을 수 있는 걸까요?

논리주소에서 세그먼트번호는 어떻게 알 수 있나요?페이지드 세그멘테이션 강의 2:50 부분페이징 분할 방식은 고정된 크기로 메모리를 분할하기에 페이지번호는 논리주소 / 페이지 크기로 구할 수 있었는데요. 논리주소에서 세그먼트 번호를 어떻게 추출하는지 궁금해요. 프레임 번호 + 세그멘테이션 테이블의 페이지 개수(bound adress)가 물리주소가 되는게 이해가 되지 않아요.페이지드 세그멘테이션 강의 3:40~ 3:50 부분주소가 변환 과정을 거칠때 세그멘테이션 테이블 참조 -> 페이지 테이블 참조 -> 프레임 번호 + 세그멘테이션 테이블의 페이지 개수(bound adress)를 더해서 물리주소를 구한다고 설명해주셨는데, 세그먼트의 시작 주소부터 얼마까지의 limit을 나타내는 bound adress를 더하는게 잘 이해가 가지않아서요. 오히려 오프셋을 더해야 하는거 아닌지 싶은데, 이부분 한번 더 설명해주시면 감사합니다.

해시테이블에서 콜리젼 해결방법의 꼬리질문으로 다음 질문을 받을 수 있다고 확인했습니다.  Open addressing 방식으로 해결한다고 하셨는데, 이 경우 데이터 삭제를 할 때 어떤 문제점이 생길 수 있을까요? 생각해보면 삭제된 경우에는 해당 영역은 적절히 사용되지 못하고 낭비되고있을 것 같은데요,  제 생각에는 해싱을 다시 해서 정렬해주는 방법(리해싱)밖에 없을 것 같은데 이런경우에는 성능 문제가 좀 크게 발생할 것 같아서요,, 혹시 이것 말고 다른 문제점도 있을까요?

모든 웹 API들을 레스트풀하게 만들면 좋을까요? 라는 질문에는 도대체 어떻게 답변을 해야할 지 감이 안오는데 간단히 가이드 주실수있을까요?  

- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 워킹셋의 경우 실행상태가 되는 컨텍스트 스위칭을 할 때 사용된다고 하셨는데, 이게 이런 의미인가요? 컨텍스트 스위칭을 할때 교체되는 페이지 10개 이중 워킹셋에 있는 페이지 4개 -> 즉, 6개만 메모리로 올라와서 스레싱을 방지한다.아니라면 컨텍스트 스위칭에 사용된다는게 어떤의미인지 궁금합니다.

root@raspberrypi:/project/linuxSrc # ./build.sh .. CC kernel/bounds.s CHKSHA1 /project/linuxSrc/linux/include/linux/atomic/atomic-arch-fallback.h DTCO arch/arm64/boot/dts/overlays/spi-rtc.dtbo DTCO arch/arm64/boot/dts/overlays/spi0-0cs.dtbo CHKSHA1 /project/linuxSrc/linux/include/linux/atomic/atomic-instrumented.h CHKSHA1 /project/linuxSrc/linux/include/linux/atomic/atomic-long.h DTCO arch/arm64/boot/dts/overlays/spi0-1cs.dtbo DTCO arch/arm64/boot/dts/overlays/spi0-2cs.dtbo DTCO arch/arm64/boot/dts/overlays/spi1-1cs.dtbo DTCO arch/arm64/boot/dts/overlays/spi1-2cs.dtbo DTCO arch/arm64/boot/dts/overlays/spi1-3cs.dtboIn file included from /project/linuxSrc/linux/arch/arm64/include/asm/lse.h:5, from /project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:14, from /project/linuxSrc/linux/arch/arm64/include/asm/atomic.h:16, from /project/linuxSrc/linux/include/linux/atomic.h:7, from /project/linuxSrc/linux/include/asm-generic/bitops/atomic.h:5, from /project/linuxSrc/linux/arch/arm64/include/asm/bitops.h:25, from /project/linuxSrc/linux/include/linux/bitops.h:68, from /project/linuxSrc/linux/include/linux/log2.h:12, from /project/linuxSrc/linux/kernel/bounds.c:13:/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:298:9: error: unknown type name ‘u128’ 298 | u128 full; | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:305:24: error: unknown type name ‘u128’ 305 | static __always_inline u128 \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:332:1: note: in expansion of macro ‘__CMPXCHG128’ 332 | __CMPXCHG128( , , ) | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:306:36: error: unknown type name ‘u128’ 306 | __ll_sc__cmpxchg128##name(volatile u128 *ptr, u128 old, u128 new) \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:332:1: note: in expansion of macro ‘__CMPXCHG128’ 332 | __CMPXCHG128( , , ) | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:306:47: error: unknown type name ‘u128’ 306 | __ll_sc__cmpxchg128##name(volatile u128 *ptr, u128 old, u128 new) \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:332:1: note: in expansion of macro ‘__CMPXCHG128’ 332 | __CMPXCHG128( , , ) | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:306:57: error: unknown type name ‘u128’ 306 | __ll_sc__cmpxchg128##name(volatile u128 *ptr, u128 old, u128 new) \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:332:1: note: in expansion of macro ‘__CMPXCHG128’ 332 | __CMPXCHG128( , , ) | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:305:24: error: unknown type name ‘u128’ 305 | static __always_inline u128 \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:333:1: note: in expansion of macro ‘__CMPXCHG128’ 333 | __CMPXCHG128(_mb, dmb ish, l, "memory") | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:306:36: error: unknown type name ‘u128’ 306 | __ll_sc__cmpxchg128##name(volatile u128 *ptr, u128 old, u128 new) \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:333:1: note: in expansion of macro ‘__CMPXCHG128’ 333 | __CMPXCHG128(_mb, dmb ish, l, "memory") | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:306:47: error: unknown type name ‘u128’ 306 | __ll_sc__cmpxchg128##name(volatile u128 *ptr, u128 old, u128 new) \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:333:1: note: in expansion of macro ‘__CMPXCHG128’ 333 | __CMPXCHG128(_mb, dmb ish, l, "memory") | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:306:57: error: unknown type name ‘u128’ 306 | __ll_sc__cmpxchg128##name(volatile u128 *ptr, u128 old, u128 new) \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/atomic_ll_sc.h:333:1: note: in expansion of macro ‘__CMPXCHG128’ 333 | __CMPXCHG128(_mb, dmb ish, l, "memory") | ^~~~~~~~~~~~ DTCO arch/arm64/boot/dts/overlays/spi2-1cs.dtbo/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:134:15: error: unknown type name ‘u128’ 134 | static inline u128 __cmpxchg128##name(volatile u128 *ptr, \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:141:1: note: in expansion of macro ‘__CMPXCHG128’ 141 | __CMPXCHG128( ) | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:134:48: error: unknown type name ‘u128’ 134 | static inline u128 __cmpxchg128##name(volatile u128 *ptr, \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:141:1: note: in expansion of macro ‘__CMPXCHG128’ 141 | __CMPXCHG128( ) | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:135:39: error: unknown type name ‘u128’ 135 | u128 old, u128 new) \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:141:1: note: in expansion of macro ‘__CMPXCHG128’ 141 | __CMPXCHG128( ) | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:135:49: error: unknown type name ‘u128’ 135 | u128 old, u128 new) \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:141:1: note: in expansion of macro ‘__CMPXCHG128’ 141 | __CMPXCHG128( ) | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:134:15: error: unknown type name ‘u128’ 134 | static inline u128 __cmpxchg128##name(volatile u128 *ptr, \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:142:1: note: in expansion of macro ‘__CMPXCHG128’ 142 | __CMPXCHG128(_mb) | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:134:48: error: unknown type name ‘u128’ 134 | static inline u128 __cmpxchg128##name(volatile u128 *ptr, \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:142:1: note: in expansion of macro ‘__CMPXCHG128’ 142 | __CMPXCHG128(_mb) | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:135:39: error: unknown type name ‘u128’ 135 | u128 old, u128 new) \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:142:1: note: in expansion of macro ‘__CMPXCHG128’ 142 | __CMPXCHG128(_mb) | ^~~~~~~~~~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:135:49: error: unknown type name ‘u128’ 135 | u128 old, u128 new) \ | ^~~~/project/linuxSrc/linux/arch/arm64/include/asm/cmpxchg.h:142:1: note: in expansion of macro ‘__CMPXCHG128’ 142 | __CMPXCHG128(_mb) | ^~~~~~~~~~~~ DTCO arch/arm64/boot/dts/overlays/spi2-1cs-pi5.dtbo DTCO arch/arm64/boot/dts/overlays/spi2-2cs.dtbo DTCO arch/arm64/boot/dts/overlays/spi2-2cs-pi5.dtbo DTCO arch/arm64/boot/dts/overlays/spi2-3cs.dtbo DTCO arch/arm64/boot/dts/overlays/spi3-1cs.dtbo DTCO arch/arm64/boot/dts/overlays/spi3-1cs-pi5.dtbo DTCO arch/arm64/boot/dts/overlays/spi3-2cs.dtbo DTCO arch/arm64/boot/dts/overlays/spi3-2cs-pi5.dtbo DTCO arch/arm64/boot/dts/overlays/spi4-1cs.dtbomake[3]: *** [/project/linuxSrc/linux/scripts/Makefile.build:116: kernel/bounds.s] Error 1make[2]: *** [/project/linuxSrc/linux/Makefile:1201: prepare0] Error 2make[2]: *** Waiting for unfinished jobs.... DTCO arch/arm64/boot/dts/overlays/spi4-2cs.dtbo DTCO arch/arm64/boot/dts/overlays/spi5-1cs.dtbo DTCO arch/arm64/boot/dts/overlays/spi5-1cs-pi5.dtbo DTCO arch/arm64/boot/dts/overlays/spi5-2cs.dtbo.. DTCO arch/arm64/boot/dts/overlays/vc4-kms-v3d-pi5.dtbo DTCO arch/arm64/boot/dts/overlays/vc4-kms-vga666.dtbo DTCO arch/arm64/boot/dts/overlays/vga666.dtbo DTCO arch/arm64/boot/dts/overlays/vl805.dtbo DTCO arch/arm64/boot/dts/overlays/w1-gpio.dtbo DTCO arch/arm64/boot/dts/overlays/w1-gpio-pi5.dtbo DTCO arch/arm64/boot/dts/overlays/w1-gpio-pullup.dtbo DTCO arch/arm64/boot/dts/overlays/w1-gpio-pullup-pi5.dtbo DTCO arch/arm64/boot/dts/overlays/w5500.dtbo DTCO arch/arm64/boot/dts/overlays/watterott-display.dtbo DTCO arch/arm64/boot/dts/overlays/waveshare-can-fd-hat-mode-a.dtbo DTCO arch/arm64/boot/dts/overlays/waveshare-can-fd-hat-mode-b.dtbo DTCO arch/arm64/boot/dts/overlays/wittypi.dtbo DTCO arch/arm64/boot/dts/overlays/wm8960-soundcard.dtbo DTC arch/arm64/boot/dts/overlays/overlay_map.dtb DTC arch/arm64/boot/dts/overlays/hat_map.dtbmake[1]: *** [/project/linuxSrc/linux/Makefile:234: __sub-make] Error 2make[1]: Leaving directory '/project/linuxSrc/out'make: *** [Makefile:234: __sub-make] Error 2 

스택오버플로우 관련 문제가있어 질문드립니다.FreeRTOSConfig.h 에 configCHECK_FOR_STACK_OVERFLOW 를 정의했는데 task.c 에 vApplicationStackOverflowHook 함수가 활성화가 되지않아 문의드립니다.  

- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 레지스터의 적은 용량을 이유로 캐시가 있다고 생각됩니다. 그럼 만약 캐시가 용량이 커지면, 그만큼 속도가 빨라지나요? 만약 그렇지 않다면 캐시 용량이 커지는 만큼 캐시내부의 검색속도가 오래걸려서 그런건가요?

이전 강의에서 커널빌드 한 후 용량을 확인해보니 out디렉토리가 28G를 차지해버려서 뒤에 삼바를 설치하는 작업을 못하고있습니다.. 강의와 다른건 커널6.6버전입니다. 해결법이 있을까요??

'메모리관리 개요' 강의에서 궁금한 사항 질문드립니다.CPU 64bit + OS 64bit => 64bit 플랫폼이라고 하셨는데,CPU와 OS의 bit가 다르다면 플랫폼 bit는 낮은 쪽으로 맞춰지는 것인가요?

질문) 상호배제 기법중에서 세마포어와 모니터 이외에 뮤텍스도 있던데 혹시 강의 내용에서 뮤텍스가 빠진 이유가 있을까용?

안녕하세요 큰돌님 싱글톤 패턴 강의를 듣다가 예시 코드를 보고 궁금한 점이 있어서 질문 드립니다. 강의에서 보여주셨던 mongoDB의 커넥션 코드에서 싱글톤 패턴은 DB.instance가 존재하면, 기존의 DB.instance를 반환함으로써 인스턴스 생성에 대한 비용을 절감하는 것이라고 이해하였습니다.그런데 여기에서 connect()함수의 this.instance는 인스턴스 내부에 instance라는 속성이 없기 때문에 undefined가 되므로 DB.instance를 반환해야 하는게 아닌지 질문드립니다.

.exe 더블클릭 시 프로세스가 새로 생성되는 걸까요 아니면 0번 프로세스를 복사해서 사용하는 것일까요?강의에서는 강의에서 운영체제가 부팅 되었을 때 0번 프로세스가 생성되는데 이 작업은 부팅 시 최초 1번만 실행되고 이후의 프로세스 생성은 0번 프로세스를 fork() 복사해서 사용한다고 했습니다. 그리고 .exe파일을 실행하면 여러 과정을 거쳐 프로세스가 생성된다고 언급되었습니다. 프로세스는 부팅할 때 1번만 생성되는데 강의에서 언급하신 .exe파일을 클릭해서 프로세스를 생성하는 과정에 대해 의문이 생겼습니다. 그래서 리눅스 부팅방식에 대해 검색해봤는데리눅스에서 부팅이 되면 커널에서 0번 프로세스 생성(강의에서 배운방식) -> 이 0번 프로세스는 커널 내부의 프로세스로 사용자가 직접적인 관련이 없음. 실제로 사용자가 접하는 프로세스는 이 0번 프로세스를 fork() 한 1번 프로세스다.1번 프로세스는 최초 사용자 공간의 프로세스이고 init 또는 systemd를 생성한다.그 이후부터 강의에서 배운 내용처럼 1번 프로세스(강의에서 0번 프로세스)를 기준으로 fork() 하여 자식 프로세스들을 생성한다.라고 검색되었습니다. 그럼 모든 프로세스는 부팅시에 만들어진 0번 프로세스를 복사해서 만들어진 것일텐데 그럼 .exe를 실행했을 때 새로운 프로세스가 생기는 과정은 무엇인지 궁금합니다.2. 운영체제가 CPU스케줄링 알고리즘을 선택하게 할 수 있나요?검색했을 때 리눅스의 경우리눅스 기준으로 운영체제가 고정된 CPU 스케줄링 알고리즘 CFS 사용한다.운영체제는 특정 프로세스 그룹에 SCHED_RR을 적용하고, 다른 프로세스 그룹에 SCHED_FIFO나 다른 정책을 적용할 수 있다.라고 언급되었습니다. 만약 운영체제가 특정 알고리즘을 적절한 상황을 스스로 판단해서 해당 CPU 알고리즘을 스스로 사용하는것이라면, 사용자가 직접 MLFQ 스케줄 알고리즘을 사용해야 하는 작업을 RR등의 다른 스케줄링 알고리즘으로 작업하게끔 명령 할 수 있을까요? 3. 91초 - MLFQ 왜 90초가 아니라 91초인가?MLFQ 강의 3:59초I/O 사용율에서 P2가 기다린 시간이 91초가 아니고 90초가 아닌가용?타임 슬라이스가 100초이고 p1 프로세스가 10초를 사용하고 p2 프로세스가 그럼 90초를 기다린게 아닌가요?