- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요 1602 LCD로 실습하려고 하는데, VCC,GND는 다 잘 연결했고, SDA, SCL CN 어디에 연결해야하는지.. 등등 프로젝트 세팅에 대해 아무것도 없어서 막혀있는 상태입니다 ㅜ

페이징 기법과 세그먼테이션 기법의 단편화 관련 질문이 있어서 드립니다. 페이징 기법이 페이지 크기로 나누어서 메모리에 불연속 분할할당을 하는걸로 이해했습니다.예를들어 한 프로세스가 100.1 크기를 가지고 있고, 페이지 단위가 1이라고 친다면 이걸 페이지로 다 나누게 되면 101개가 생기고 결국 내부단편화가 생기는 부분은 마지막 페이지의 0.9 밖에 없는게 맞나요? 결국 페이징 기법에서 내부 단편화는 한프로세스에서 마지막 페이지에서만 발생할 것이고 그 크기는 페이지 단위보다 무조건 작지않나요? 이러면 4kb 보다 작을테니 거의 없는 수준이라고 봐도 되고 무시할 만한 크기 아닌가요? 이와 비교했을 때, 세그먼테이션기법에서는 프로세스를 세그먼트 단위 즉 코드,데이터,스택,힙 이렇게 크게 4개로 나누니까 프로세스 크기를 100이라고 친다면 10, 20, 30, 40 이거나, / 20, 30, 15, 35/ 등 이런식으로 페이징으로 나누는 경우보다 훨씬 큰 단위일 것이며 외부단절화 크기가 페이징 기법에서보다 훨씬 클거라고 예상 되는게 이게 맞는지 궁금합니다.  

 1. output을 위한 api를 호출한다. 2. kernel 모드로 진입을 하며, 해당 기능의 system call을 수행한다. 3. 보낼 데이터를 비디오 카드(외부장치)가 예약한 메모리 영역에 저장 후,interrupt를 건다. -> 여기서 어떤 인터럽트를 왜 거는지 잘 모르겠습니다.dma 기능이 있는 경우.i/o manager가 dma에게 작업을 맡긴다.dma 기능이 없는 경우.i/o manager의 스케줄링에 따라 cpu가 driver의 함수를 이용 해 비디오 카드에 데이터 전송. 4. 비디오 카드의 작업이 끝나면 비디오 카드는 cpu에게 작업완료 인터럽트를 건다.dma가 있는 경우는 비디오 카드가 dma에게 작업완료 메시지를 보내고 dma가 작업완료 인터럽트 발생시킴. 추가질문 입니다.강의의 interrupt에서 directX까지 20:00에, system call이 메모리에 video card에 데이터를 전송 할 때 매 번 그런 건 아니지만, 메모리에 저장하고 interrupt를 건다고 하셨습니다. 메모리에 따로 다시 저장하지 않고, 장치에 전송 할 수도있나요? 

안녕하세요 큰돌 선생님, 질문이 있어서 여쭤봅니다. HTML에서도 커스텀 태그 제작이 가능하지 않나요? HTML 5에서 나온, data 속성을 활용해서, 필요한 데이터를 집어넣고, CSS나 Javascript를 활용하면, 고유 태그를 만들 수 있다고 볼 수 있지 않나요? 면접에서 질문이 나오면, 둘 다 가능하다고 대답해야할지 아니면 XML은 되지만 HTML은 고유 태그 못 만든다고 대답해야할지 헷갈려서 질문 드립니다. 항상 좋은 강의 감사합니다.

페이지 미스 중 1. 접근 권한 오류에 관련하여 개념이 헷갈려 질문 드립니다. 먼저 프로세스, 메모리, CPU 이런 과정에 대해 이해를 못한 것 같습니다. 예를 들어 어떤 프로그램을 실행 / 파일 읽기 / 웹브라우저 실행 등 어떤 행위를 했을 때 이게 프로세스가 되고, 프로세스는 메모리에 올라오고 CPU는 메모리에 올라와 있는 프로세스들을 처리한다 이렇게 이해하고 있는데 이게 맞나요? 그렇다면 접근 권한 오류 상황에서 이 과정이 어떻게 흘러가는건 지 헷갈립니다. 저 경우에서 파일 읽기가 금지된 행위라고 가정한다면 이건 프로세스가 되지 않는건가요? 이게 권한이 없는 행위가 프로세스가 아예 안되는건 지, 메모리에 아예 올라 가질 않는 건지 명확히 알고 싶습니다. 어떤 행위를 했을 때 어떤 과정으로 일어나는지 정확히 알고 싶습니다.

안녕하세요. 커널 강의 잘 듣고있습니다. 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 문의하기를 이용해주세요. 레지스터의 적은 용량을 이유로 캐시가 있다고 생각됩니다. 그럼 만약 캐시가 용량이 커지면, 그만큼 속도가 빨라지나요? 만약 그렇지 않다면 캐시 용량이 커지는 만큼 캐시내부의 검색속도가 오래걸려서 그런건가요?