[PintOS] User Programs - FAQs
The kernel always panics when I run pintos -p file -- -q.
파일 시스템을 포맷했나요? ('pintos -f'로)
파일 이름이 너무 깁니까? 파일 시스템은 파일 이름을 14자로 제한합니다. 'pintos -p ../../examples/echo -- -q'와 같은 명령은 제한을 초과합니다.
대신 'pintos -p ../../examples/echo -a echo -- -q'를 사용하여 파일을 'echo'라는 이름으로 저장하세요.
파일 시스템이 가득 찼나요? 파일 시스템에 이미 16개의 파일이 있습니까? 기본 Pintos 파일 시스템은 16개의 파일 제한이 있습니다.
파일 시스템이 너무 조각화되어 파일에 충분한 연속적인 공간이 없을 수 있습니다.
When I run pintos -p ../file --, ‘file’ isn’t copied.
기본적으로 파일은 참조하는 이름으로 작성됩니다. 따라서 이 경우 복사된 파일은 'file'이라는 이름으로 될 것입니다.
아마도 pintos -p ../file -a file --를 실행하고 싶을 것입니다. 파일 시스템에 있는 파일을 나열하려면 pintos -q ls를 사용할 수 있습니다.
All my user programs die with page faults.
이는 인수 전달을 구현하지 않았거나 (또는 올바르게 구현하지 않았을 경우) 발생할 수 있습니다. 사용자 프로그램을 위한 기본 C 라이브러리는 argc와 argv를 스택에서 읽으려고 시도합니다. 스택이 제대로 설정되지 않았으면 이로 인해 페이지 폴트가 발생합니다.
All my user programs die with system call!
다른 것을 보기 전에 시스템 호출을 구현해야 합니다. 모든 합리적인 프로그램은 적어도 하나의 시스템 호출(exit())을 시도하고 대부분의 프로그램은 그 이상을 시도합니다. 특히 printf()는 write 시스템 호출을 호출합니다. 기본 시스템 호출 핸들러는 단순히 'system call!'을 출력하고 프로그램을 종료합니다. 그 전까지는 hex_dump()을 사용하여 인수 전달이 올바르게 구현되었는지 확인할 수 있습니다(3.5.1 [프로그램 시작 세부 사항] 참조).
How can I disassemble user programs?
사용자 프로그램을 분해하는 방법은 objdump(80x86) 또는 i386-elf-objdump(SPARC) 유틸리티를 사용하는 것입니다. objdump -d file로 호출할 수 있습니다. 개별 함수를 분해하려면 GDB의 disassemble 명령을 사용할 수도 있습니다(섹션 E.5 [GDB] 참조).
Why do many C include files not work in Pintos programs? Can I use libfoo in my Pintos programs?
많은 C 포함 파일이 Pintos 프로그램에서 작동하지 않는 이유는 Pintos가 실제 운영 체제의 C 라이브러리에서 기대되는 많은 기능을 포함하지 않기 때문입니다. C 라이브러리는 운영 체제(및 아키텍처)에 특별히 빌드되어야 합니다. 왜냐하면 I/O 및 메모리 할당을 위해 시스템 호출을 수행해야 하기 때문입니다. (물론 모든 함수가 그렇지는 않지만 일반적으로 라이브러리는 단위로 컴파일됩니다.)
원하는 라이브러리가 Pintos에서 구현되지 않은 C 라이브러리의 일부를 사용할 가능성이 높습니다. Pintos에서 작동하도록 만들기 위해 최소한 어느 정도의 이식 작업이 필요할 것입니다. 특히 Pintos 사용자 프로그램 C 라이브러리에는 malloc() 구현이 없습니다.
How do I compile new user programs?
Modify ‘src/examples/Makefile’, then run make
Can I run user programs under a debugger?
Yes, with some limitations. See Section E.5 [GDB], page 105.
What’s the difference between tid_t and pid_t?
tid_t는 커널 스레드를 식별하며, 이 스레드에는 사용자 프로세스가 실행될 수 있습니다 (process_execute()로 생성된 경우) 또는 실행되지 않을 수 있습니다 (thread_create()로 생성된 경우). 이는 커널에서만 사용되는 데이터 형식입니다.
pid_t는 사용자 프로세스를 식별합니다. 이는 사용자 프로세스와 exec 및 wait 시스템 호출에서 커널에서 사용됩니다.
tid_t와 pid_t에 적합한 유형을 선택할 수 있습니다. 기본적으로 둘 다 int입니다. 동일한 값이 둘 다 동일한 프로세스를 식별하도록 일대일 매핑을 만들 수 있거나 더 복잡한 매핑을 사용할 수 있습니다. 선택은 당신에게 달려 있습니다.
Can I just cast a struct file * to get a file descriptor? Can I just cast a struct thread * to a pid_t?
이러한 설계 결정은 직접 해야 합니다. 대부분의 운영 체제는 파일 디스크립터 (또는 pid)와 그들의 커널 데이터 구조의 주소를 구별합니다. 커밋하기 전에 이러한 구분을 왜 하는지에 대해 고민해 보는 것이 좋습니다.
Can I set a maximum number of open files per process?
권장하지는 않지만 128개까지 늘릴 수는 있다.
What happens when an open file is removed?
파일에 대해 표준 Unix 의미론을 구현해야 합니다. 즉, 파일이 삭제되면 해당 파일에 대한 파일 디스크립터가 있는 모든 프로세스는 해당 디스크립터를 계속 사용할 수 있습니다. 이는 파일에서 읽고 쓸 수 있다는 것을 의미합니다. 파일은 이름이 없게 되며, 다른 프로세스는 해당 파일을 열 수 없지만, 모든 파일 디스크립터가 닫힐 때까지 또는 기계가 종료될 때까지 계속 존재할 것입니다.
How can I run user programs that need more than 4 kB stack space?
각 프로세스에 대해 하나 이상의 페이지를 스택 공간으로 할당하도록 스택 설정 코드를 수정할 수 있습니다. 다음 프로젝트에서 더 나은 해결책을 구현할 것입니다.
What should happen if an exec fails midway through loading?
exec는 자식 프로세스가 어떤 이유로든 로드에 실패하면 -1을 반환해야 합니다. 이는 로드가 프로세스의 실행 중간에 실패하는 경우를 포함합니다(예: multi-oom 테스트에서 메모리가 부족한 경우). 따라서 부모 프로세스는 로드가 성공했는지 여부를 확인할 때까지 exec 시스템 콜에서 반환할 수 없습니다. 자식 프로세스는 부모에게 이 정보를 적절한 동기화 메커니즘을 사용하여(예: 세마포어) 통신해야 하며, 이를 통해 정보가 경쟁 상태 없이 통신되도록 보장해야 합니다.