데이즈

안녕하세요? 허니데이즈 블러그에 찾아주셔서 감사합니다. Fuchsia Friday에서 2018.7에 게시된 글을 읽고 그 내용을 공유하고자 포스팅합니다.

많은 사람들이 구글에서 퓨시아(Fuchsia)가 향후 5년 이내에 Android를 대체한다는 보고서를 보았고 독자 여러분 역시 뉴스를 통해 기사를 본적이 있을 겁니다. Google이 안드로이드가 가진 핵심 생태계를 어떻게 신속하게 대체할 수 있는지에 대한 많은 우려와 걱정이 공존하고 있습니다. 최근에는 퓨시아가 어디에 어떻게 쓰일지 많은 관심을 가지고 있으며 어떻게 구글이 안드로이드를 퓨시아로 생태계를 전환할 수 있는지 많은 사람들이 궁금해 하고 있습니다.

구글에서 최근 제시한 퓨시아 관련 보고서를 보면 조만간 퓨시아 장치 중 하나를 향후 3년 내 스마트 스피커를 볼 수 있을 것입니다. 이를 위해 Google은 퓨시아(Fuchsia)와 오늘날의 Google 홈에서 제공하는 플랫폼에 통합하는 작업에 어려움을 겪고 있습니다. 이 외에도 새로운 스마트 스피커를 구매할 가치가 있는 사람은 이미 가지고있는 장치, 특히 Android와 호환되는 장치와 상호 작용할 수 있어야 합니다. 그 중 일부는 블루투스와 같이 우리가 당연한 것으로 여기는 단순한 것들입니다. 구글은 이미 퓨시아와 안드로이드 기기간에 블루투스 연결이 작동하도록 자동화된 테스트를 이미 만들었습니다.

크롬캐스트(현재 오디오 전용)와 같은 일부 퓨시아(Fuchsia) 장치를 처리하여 기존 크롬캐스트 호환 음악, 팟 캐스트, 오디오북 앱과 호환될수 있도록 작업이 진행 중에 있습니다.

프로젝트 "가우스"가 곧 출시 될 퓨시아(Fuchsia)를 실행하는 제품인지는 분명하지 않지만 Google 홈의 복제본처럼 보일 수 있습니다. 이 장치는 더 중요하고 복잡한 장치로 이동하기 전에 현실 세계에서 OS의 생존 가능성을 입증하는데 도움이 될 것입니다.

그러나 이 전환과 관련하여 잠재적인 문제가 많습니다. 어느 누구도 새 Google 홈을 구입하지 않습니다. 이전 Google 홈이 하던 모든 작업만 수행 할 수 있는 새 홈은 전혀 볼 수없는 새로운 운영 체제용이기 때문입니다. Fuchsia의 첫 번째 장치가 잘 통합된다면 약 5년 후에 Android에서 Fuchsia로 운영체제가 바뀔 것입니다.

먼저, 앱을 가져올 수 있는지 여부에 대해 걱정할 필요가 없습니다. 구글은 이미 유튜브와 2017년 3월에 작업중인 구글 크롬 포트를 포함한 주요 제품에 네이티브 퓨시아 앱을 개발하고 있습니다. 아직 확인되지는 않았지만 Fuchsia는 안드로이드 런타임에 대한 지원을 받고있는 것으로 보이고, 안드로이드 런타임은 대부분의 안드로이드 앱이 퓨시아 폰에서 정상적으로 작동해야 함을 의미합니다.

그러나 운영체제를 전환해야 할 가능성이 여전히 염려되는 경우이를 명심해야 합니다. Fuchsia가 5년 계획을 갖고 있다면 Android에도 역시 5가지 계획이 있습니다. 안드로이드는 일반적으로 퓨시아가 의존하는 안정적인 네트워크 연결이 없는 10억 사용자에 대한 Google의 야심의 일부입니다. Fuchsia가 이러한 시장에 도달할 수 있는 방법을 찾지 않으면 안드로이드의 개발은 방해받지 않을 것입니다. 제 3의 제조사가 곧 모든 폰을 안드로이드 폰으로 만드는 일은 거의 없게 될 것입니다. 마지막 Android 기기가 만들어 지더라도 최소한 1년 또는 2년 동안 보안 업데이트로 지원해야 합니다.

확실히 전환은 완전히 완료되는데 수년이 걸릴 것입니다. Android에서 곧바로 전환하고 싶지 않은 경우 옵션을 사용할 수 있습니다. Fuchsia의 기본 응용 프로그램 프레임 워크로 Flutter를 사용하면 Android, iOS 용으로 만든 앱을 Fuchsia에서 쉽게 실행할 수있을뿐만 아니라 Fuchsia 용으로 만든 앱을 Android, iOS와의 호환성을 유지하도록 설계 할 수 있습니다. Fuchsia가 단순히 Android의 새 버전으로 판매 될 가능성이 항상 있음을 기억해야 합니다. 이 시점에서 아직 많이 모르는 부분이 있습니다.

우리는 몇 년 후에 일어날 일에 대해 이야기하고 있다는 것을 기억하는 것이 중요합니다. Google의 경우 변경 계획, 새로운 개발, 더 나은 전환 계획을 위한 충분한 시간입니다.

출처: https://9to5google.com/2018/07/27/fuchsia-friday-how-fuchsia-could-ease-into-the-google-ecosystem/

안녕하세요? 허니데이즈입니다. 오랜만에 포스팅 합니다. 그동안 회사에서 바쁜일이 있어서.ㅠㅠ 오늘은 핸들(Handles)에 대해서 이야기 해 보고자 합니다.

 개념

Handles은 사용자 모드에서 프로그램이 커널 객체를 참조할 수있게 해주는 커널 구조이다. Handle은 특정 커널 객체에 대한 세션이나 연결로 생각할 수 있다. 여러 프로세스가 서로 다른 Handle을 통해 동일한 객체에 동시에 접근하는 경우가 있다. 하지만 단일 Handle은 단일 프로세스에 바인딩되거나 커널에만 바인딩될 수 있다. 커널에 바인딩될 때 'in-transit'로 표현된다. 사용자 모드에서 Handle은 단순히 일부 시스템 호출에 의해 반환된 특정 번호이다. 전송 중이 아닌 핸들만 사용자 모드에서 볼 수 있다. Handle을 나타내는 정수는 해당 프로세스에 대해서만 의미가 있다. 다른 프로세스의 동일한 번호가 Handle에 맵핑되지 않거나 완전히 다른 커널 오브젝트를 가리키는 Handle에 맵핑 될 수 있다. Handle의 정수 값은 ZX_HANDLE_INVALID에 해당하는 값을 제외한 32비트인 숫자이다. 커널 모드의 경우 Handle은 세 개의 논리 필드를 포함하는 C++ 객체이다.

• A reference to a kernel object: 커널 객체에 대한 참조
• The rights to the kernel object: 커널 객체에 대한 권한
• The process it is bound to (or if it's bound to kernel): 바인딩된 프로세스

'rights'은 커널 객체의 어떤 작업이 허용되는지를 명시한다. 단일 프로세스가 다른 권한을 가진 동일한 커널 오브젝트에 대해 두 개의 서로 다른 Handle을 가질 수 있다.

 Handle 사용하기

새로운 커널 객체를 생성하고 Handle을 반환하는 많은 syscall이 존재한다. 몇 가지 예를 들면 다음과 같다.

• zx_event_create

• zx_process_create

• zx_thread_create

위 호출은 커널 객체와 이를 가리키는 첫 번째 Handle을 생성하게 된다. Handle은 syscall을 발행한 프로세스에 바인드되며 권한은 해당 유형의 커널 오브젝트에 대한 기본 권한이다. 같은 커널 객체를 가리키고 syscall을 실행한 동일한 프로세스에 바인딩된 Handle 사본을 만들 수있는 시스템 콜은 오직 하나뿐이다.

• zx_handle_duplicate

상응하는 Handle을 만들 수 있는 한 개의 시스템콜이 있다(권한이 적을 수 있음). 원래 Handle을 무효화 한다.

• zx_handle_replace

Handle을 파괴하는 시스템 호출이 있다.

• zx_handle_close

호출 프로세스에 바인딩 핸들을 받아 커널에 바인딩하는 두 개의 시스템 콜이 있다.(Handle을 전송 중입니다).

• zx_channel_write

• zx_socket_share

in-transit Handle을 사용하여 호출 프로세스에 바인딩하는 세 개의 syscall이 있다.

• zx_channel_read

• zx_channel_call

• zx_socket_accept

위의 채널과 소켓 syscalls는 한 프로세스에서 다른 프로세스로 Handle을 전송하는데 사용된다. 예를 들어 채널과 함께 두 개의 프로세스를 연결할 수 있다. 핸들을 전송하기 위해 타겟 프로세스는 zx_channel_write 또는 zx_channel_call을 호출하고 대상 프로세스는 동일한 채널에서 zx_channel_read를 호출한다. 마지막으로, 새 프로세스에 부트스트랩 Handle을 제공하는 단일 시스템콜이 있다. 즉, 다른 Handle을 요청하는데 사용할 수 있는 Handle이다.

• zx_process_start

부트 스트래핑 Handle은 전송 가능한 커널 객체일 수 있지만 가장 합리적인 경우는 채널의 한쪽 끝을 가리키는 것이므로 초기에 채널을 사용하여 새로운 프로세스에 추가 Handle을 보낼 수 있다.

 Garbage Collection

Handle이 유효하면 이를 가리키는 커널 오브젝트가 유효함을 보장한다. 이는 커널 객체가 참조 카운트되고 각 Handle이 커널 객체에 대한 참조를 보유하기 때문에 보장된다. 그 반대는 Handle이 종료되면 그 Handle이 종료된다는 의미가 아니다. 객체를 가리키는 다른 Handle이 있거나 커널 자체가 커널 객체에 대한 참조를 보유하고 있을 수 있다. 예를 들어 스레드에 대한 Handle로 스레드에 대한 마지막 Handle이 종료된다면 스레드가 종료되었음을 의미하지는 않는다. 커널 객체에 대한 마지막 참조가 해제되면 커널 객체가 파괴되거나 커널이 객체에 Garbage Collection을 표시한다. 객체는 현재 대기중인 작업 세트가 완료될 때 나중에 폐기된다.

Special Cases

Handle이 전송 중이고 쓰여진 채널이나 소켓이 종료되면 Handle이 닫히게 된다. 디버깅 세션에는 Handle에 대한 접근 권한을 얻기 위한 특별한 syscalls가 있을 수 있다.

출처: https://fuchsia.googlesource.com/zircon/+/master/docs/handles.md

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭! 

안녕하세요? 허니데이즈입니다.

스레드 객체는 시분할 공유 CPU 실행 컨텍스트를 나타내는 컨텍스트이다. 스레드 객체는 I/O와 계산에 필요한 다른 객체에 메모리와 Handle을 제공하는 특정 프로세스 객체와 관련되어 있다.

 Lifetime은 어떻게 되나요?
스레드는 호출 zx_thread_create()에 의해 생성 되지만, zx_thread_start()나 zx_process_start() 호출 될때만 실행을 시작한다. 두 syscalls은 실행할 초기 루틴의 진입점을 인수로 받는다. 전달된 스레드 zx_process_start()는 프로세스에서 실행을 시작하는 첫 번째 스레드여야 한다. 다음과 같은 경우에 스레드가 실행을 종료한다.

1. zx_thread_exit() 호출 시
2. zx_vmar_unmap_handle_close_thread_exit() 호출 시
3. zx_futex_wake_handle_close_thread_exit() 호출 시
4. 부모 프로세스가 종료 될 때
5. zx_task_kill()가 스레드의 핸들로 호출 시
6. 처리기가 없거나 처리기가 스레드를 종료하기로 결정한 예외를 생성할 시
진입점 루틴에서 리턴되면 실행이 종료되지 않는다. 진입점의 마지막 동작은 zx_thread_exit() 위에서 언급한 _exit() 변형 중 하나를 호출해야 한다.

스레드에 대한 마지막 Handle를 닫아도 실행이 종료되지 않는다. 사용 가능한 Handle이 없는 스레드를 강제 종료 zx_object_get_child()하려면 스레드의 Handle을 얻는데 사용해야 한다. 하지만 실행중인 스레드를 종료하면 프로세스가 손상된 상태가 될 수 있기 때문에 이 방법은 사용하지 않는 것이 좋다.

퓨시아 스레드는 항상 분리된다. 즉, 정상적인 종료를 수행하는데 필요한 join() 작업은 없다 . 그러나 C11이나 POSIX와 같은 커널 위의 일부 런타임은 스레드가 결합되어야 할 수도 있다.

 SYSCALLS은 어떤것이 있나요?
thread_create - 프로세스 내에서 새로운 스레드 생성하기
thread_exit - 현재 스레드 종료하기
thread_read_state - 스레드로부터 레지스터 상태를 읽기
thread_start - 새로운 thread가 실행을 시작하기
thread_write_state - 스레드의 레지스터 상태 수정하기
task_resume - 일시 중지된 작업을 계속 실행하기
task_bind_exception_port - 태스크에 예외 포트를 연결하기
task_kill - 작업 실행 중지하기

출처: https://fuchsia.googlesource.com/zircon/+/master/docs/objects/thread.md

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭! 

안녕하세요? 허니데이즈입니다. 오늘은 지르콘 커널의 구성 객체들이 무엇이 있는지 알아보도록 하겠습니다.

Zircon은 객체 기반 커널이다. 사용자 모드 코드는 거의 독점적으로 객체 Handle을 통해 OS 리소스와 상호 작용한다. Handle은 특정 리소스 범위의 특정 OS 하위 시스템과의 활성 세션으로 생각할 수 있다. 지르콘은 다음과 같은 자원을 적극적으로 관리한다.

 Processor time

 Memory and address spaces

 Device-io memory

 Interrupts

 Signaling and waiting

 응용 프로그램용 커널 객체는 뭐가 있나요?

IPC

1. Channel

2. Socket

3. FIFO

Tasks

1. Process

2. Thread

3. Job

4. Task

Signaling

1. Event

2. Event Pair

3. Futex

Memory and address space

1. Virtual Memory Object

2. Virtual Memory Address Region

3. bus_transaction_initiator

Waiting

1. Port

 드라이버용 커널 객체는 뭐가 있나요?

Interrupts

Resource

Log

 커널 객체와 LK

일부 커널 객체는 하나 이상의 LK 레벨 구조를 래핑한다. 예를 들어 Thread 객체는 하나의 thread_t를 래핑한다. 그러나 채널은 LK 레벨 오브젝트를 랩핑하지 않는다.

 커널 개체 라이프사이클은?

커널 개체는 ref-counting 된다. 대부분의 커널 객체는 syscall 중에 생성되며 syscall의 출력으로 주어진 Handle 값을 바인드하는 핸들에 의해 refcount = 1에서 활성 상태로 유지된다. Handle 오브젝트는 Handle Table에 첨부되어있는 동안 계속 유지한다. Handle은 Handle Table에서 분리되어(예를 들어 sys_close()를 통해) 커널 오브젝트의 refcount를 감소시킨다. 대개 마지막 Handle이 닫히면 커널 객체 refcount는 0에 도달하여 소멸자가 실행된다. refcount는 새로운 Handle(객체 참조)이 생성되고 직접 포인터 참조(일부 커널 코드에 의해)가 획득 될 때 증가한다. 그러므로 커널 객체의 수명은 프로세스를 생성한 프로세스의 수명보다 길 수 있다.

 Dispatchers의 역할은 무엇인가요?

커널 오브젝트는 Dispatcher에서 파생된 C++ 클래스로 구현되며 구현된 메소드를 대체한다. 예를 들어 Thread 객체의 코드는 ThreadDispatcher에서 찾을 수 있다. 일반적인 의미의 커널 객체만 신경 쓰는 코드가 많이 있다. 이 경우 fbl::RefPtr<Dispatcher>라는 이름이 사용된다.

 커널 개체 보안은 어떻게?

원칙적으로 커널 객체는 본질적인 보안 개념을 갖고 있지 않으며 권한 부여 검사를 수행하지 않는다. 보안 권한은 각 Handle에서 보유한다. 단일 프로세스는 동일한 권한을 가진 동일한 오브젝트에 대해 서로 다른 두 개의 핸들을 가질 수 있다.

출처: https://fuchsia.googlesource.com/zircon/+/master/docs/objects.md

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭! 

안녕하세요? 허니데이즈입니다. 오늘은 지르콘 커널에서 중요한 역할을 하는 프로세스에 대해서 준비해 봤습니다.

지르콘 프로세스는 전통적 의미에서 프로그램의 인스턴스라고 보면 된다. 리소스 모음과 함께 하나 이상의 스레드에서 실행되는 명령 집합이다. 프로세스 개체는 다음 리소스의 컨테이너로 운영된다.

 Handles
 Virtual Memory Address Regions
 Threads

일반적으로 프로세스는 강제 종료되거나 프로그램이 종료 될 때까지 실행중인 코드와 관련된다. 또한 프로세스는 작업에 의해 소유되며 하나 이상의 프로세스로 구성된 어플리케이션을 리소스, 사용 권한 한도, 수명 제어의 관점에서 단일 엔터티로 처리 할 수 ​​있다.

 Lifetime은 어떻게 되나요?
zx_process_create()를 통해 프로세스가 생성되고 실행은 zx_process_start()로 시작된다. 다음과 같은 경우에는 프로세스가 실행을 중지한다.

1. 마지막 스레드가 종료
2. 프로세스 호출 zx_process_exit()
3. 상위 작업이 프로세스를 종료
4. 상위 작업이 삭제
zx_process_start()에 대한 호출을 두 번 실행할 수 없다. 새 스레드는 시작된 프로세스에 추가될 수 없으며 마지막 스레드가 종료된다.

 SYSCALLS은 어떤 것이 있나요?
process_create - 작업 내에서 새 프로세스 만들기
process_read_memory - 프로세스의 주소 공간에서 읽기
process_start - 새 프로세스가 실행을 시작하기.
process_write_memory - 프로세스의 주소 공간에 쓰기
process_exit - 현재 프로세스 종료하기
job_create - 상위 작업 내에서 새 작업 만들기
vmar_map - 메모리를 주소 공간 범위에 매핑하기
vmar_protect - 주소 공간 범위의 권한 변경하기
vmar_unmap - 주소 공간 범위에서 메모리 맵 해제하기

출처: https://fuchsia.googlesource.com/zircon/+/master/docs/objects/process.md

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭! 

안녕하세요? 허니데이즈입니다. 오늘은 지르콘 커널이 과연 무엇이고, 어떤 구성요소로 되어 있는지 알아보겠습니다.

 지르콘 커널 개념
커널은 다양한 유형의 객체를 관리한다. 시스템 호출을 통해 직접 접근할 수있는 클래스는 Dispatcher 인터페이스를 구현하는 C++ 클래스라고 보면 된다. 이는 커널/객체에서 구현되며 많은 것이 자체 포함된 상위 수준의 객체이다. 하지만 일부는 하위 레벨의 LK 프리미티브를 래핑한다.

 System Calls
사용자 공간에 있는 코드는 시스템 호출을 통해 커널 객체와 Handle을 통해 상호작용한다. 사용자 공간에서 Handle은 32비트 정수(zx_handle_t 타입)로 표시된다. syscalls이 실행되면 커널은 Handle 매개변수가 호출 프로세스의 Handle 테이블에있는 실제 Handle을 참조하는지 확인한다. 커널은 Handle이 올바른 유형인지(Handle을 요구하는 syscall에 스레드 Handle을 전달하여 오류가 발생함) Handle 요청된 작업에 필요한 권한을 가지고 있는지 확인한다.

시스템 호출은 접근 관점에서 크게 세 가지 범주로 나뉘게 된다.

제한이 없는 호출은 매우 적다. 예를 들면 zx_clock_get()과 zx_nanosleep() 은 모든 스레드에서 호출 할 수 있다.
Handle을 첫 번째 매개변수로 사용하여 처리할 객체를 나타내며 zx_channel_write()와 zx_port_queue() 호출 등이 있다.

새로운 객체를 생성하지만 zx_event_create()와 zx_channel_create()이 같이 Handle을 사용하지 않는 호출이 있다. 이에 대한 접근과 그들에 대한 제한은 호출 프로세스가 포함된 작업에 의해 제어된다.
시스템 호출은 Zircon 커널이 사용자 공간에 제공하는 "가상" 공유 라이브러리인 libzircon.so에 의해 제공되며 가상 동적 공유 객체나 vDSO로 더 잘 알려져 있다. zx_noun_verb()나 zx_noun_verb_direct-object() 형태의 C ELF ABI 함수로 표현된다.

시스템 호출은 syscalls.abigen에 의해 정의되고 abigen 도구에 의해 libzircon의 include 파일, glue 코드와 커널의 libsyscalls로 처리된다.

 Handles and Rights
객체는 하나 이상의 프로세스에서 여러 개의 Handle을 참조 할 수 있다.

거의 모든 객체의 경우, 객체를 참조하는 마지막 열려있는 Handle이 닫히면 객체는 파괴되거나 취소 할 수없는 최종 상태가 된다.

Handle은 채널에 write(zx_channel_write() 사용)하거나 zx_process_start()를 사용하여 Handle을 새 프로세스의 첫 번째 스레드의 인수로 전달하여 한 프로세스에서 다른 프로세스로 이동할 수 있다.

Handles이나 Handles과 관련된 대상에서 취할 수 있는 행동은 해당 Handles과 관련된 권한에 의해 정해진다. 동일한 Object를 참조하는 두 개의 Handle은 다른 권한을 가질 수 있다.

zx_handle_duplicate()와 zx_handle_replace() 시스템 호출이 감소된 권한으로 임의로 Handle 전달과 같은 추가 오브젝트 참조 Handle을 얻기 위해 사용될  수 있다. zx_handle_close()와 zx_handle_close_many()는 Handle이 해당 객체의 마지막 경우 시스템 호출과 이를 참조하는 객체를 닫는 기능을 한다.

 Kernel Object IDs
커널의 모든 객체에는 "kernel object id" 나 "koid"가 있다. 객체를 식별하는데 사용할 수 있고 실행중인 시스템의 수명동안 고유 64비트 부호없는 정수로 표현된다. 이는 koid가 결코 재사용되지 않는다는 것을 의미한다.

두 가지 특별한 koid 값이 있다. ZX_KOID_INVALID 값이 0이고 "null" 센티널으로 사용되며 ZX_KOID_KERNEL 커널은 하나 뿐이며, 커널 자체가 있다.

 Running Code: Jobs, Processes, and Threads
스레드는 프로세스가 소유 한 주소 공간에서 실행 스레드(CPU 레지스터, 스택 등)를 알려준다. 프로세스는 다양한 자원 제한을 정의하는 Jobs 소유이다. 작업은 부모 작업에 의해 소유되며 부팅 할 때 커널에 의해 생성되고 사용자 부팅(userboot)으로 전달되는 루트 작업까지 진행되며 실행을 시작하는 첫 번째 사용자 공간 프로세스이다. 작업 Handle이 없으면 프로세스 내의 스레드가 다른 프로세스 나 다른 작업을 작성할 수 없다. 프로그램 로딩은 커널 계층 위의 사용자 공간 기능과 프로토콜에 의해 제공된다.

참조 : process_create, process_start, thread_create, thread_start

 Message Passing: Sockets and Channels

소켓과 채널 모두 양방향 및 양방향인 IPC 개체이다.

소켓은 스트림 지향(stream-oriented)이며 데이터는 하나 이상의 바이트 단위로 쓰거나 읽을 수 있다. 짧은 write(소켓의 버퍼가 가득 찬 경우)와 짧은 read(버퍼보다 많은 데이터가 요청 된 경우)가 가능하다.

채널은 데이터그램 지향(datagram-oriented)이며 최대 메시지 크기가 64K(변경될 가능성이 있으며 작을 수 있음)이며 메시지에 첨부된 최대 1024개의 Handle을 가질 수 있다(또한 변경 될 수 있으며 작을 수도 있음). 짧은 read나 write를 지원하지 않는다. 메시지가 적합하거나 그렇지 않다.

Handle이 채널에 기록되면 Handle은 송신 프로세스에서 제거된다. Handle이 있는 메시지를 채널에서 읽을 때, Handle은 수신 프로세스에 추가된다. 이 두 이벤트 사이에서 Handles은 작성된 채널의 끝이 닫히지 않는 한 계속해서 존재한다(참조된 객체가 계속 존재하는지 확인). 그 시점에서 해당 끝점으로 이동하는 메시지는 삭제된다. 포함된 Handle은 닫힌다.

참조 : channel_create , channel_read , channel_write , channel_call , socket_create , socket_read, socket_write

 Objects and Signals
객체는 현재 상태에 대한 정보를 나타내는 최대 32개의 신호(zx_signals_t 타입과 ZX_ SIGNAL로 정의)를 가질 수 있다. 예를 들어, 채널과 소켓은 READABLE 또는 WRITABLE일 수 있다. 프로세스 또는 쓰레드가 종료 될 수 있다. 스레드는 하나 이상의 객체에서 신호가 활성화 될 때까지 대기 할 수 있다.

 Waiting: Wait One, Wait Many, and Ports

쓰레드는 zx_object_wait_one() 을 사용하여 단일 Handle에서 신호가 활성화될 때까지 기다리거나 zx_object_wait_many()를 사용하여 여러 Handle에서 신호를 기다릴 수 있다. 두 통신 모두 신호가 보류중인 경우에도 반환 할 수있는 제한 시간을 허용한다.

스레드가 많은 수의 Handle을 기다릴 경우 다른 객체가 바인딩 될 수있는 객체인 포트를 사용하는 것이 더 효율적이다. 즉 신호가 신호를 받으면 포트는  보류중인 신호에 대한 정보를 포함하는 패킷을 수신한다.

참조 : port_create, port_queue, port_wait, port_cancel

 Events, Event Pairs

이벤트는 활성 신호 모음이 아닌 다른 상태가 없는 가장 간단한 개체이다.

이벤트 페어는 서로 신호를 보낼 수 있는 한 쌍의 이벤트 중 하나이다. 이벤트 페어의 유용한 속성은 한 페어의 한 쪽이 사라지면(다른 모든 쪽 Handle이 닫힌 경우) 반대쪽에 PEER_CLOSED 신호가 어서트된다.

참조 : event_create, eventpair_create .

 Shared Memory: Virtual Memory Objects (VMOs)

가상 메모리 개체는 메모리의 물리 페이지 집합이나 페이지의 potential을 나타낸다(which will be created/filled lazily, on-demand).

이는 zx_vmar_map()으로 프로세스의 주소 공간에 매핑되고 zx_vmar_unmap ()으로 매핑 해제될 수 있다. 매핑 페이지의 사용 권한은 zx_vmar_protect()를 사용하여 조정할 수 있다. VMO는 zx_vmo_read()와 zx_vmo_write()를 사용하여 직접 읽고 쓸 수 있다. 따라서 주소 공간에 매핑하는 비용은 "VMO 만들기, 데이터 세트 작성, 다른 프로세스로 사용"과 같은 단 한번의 작업으로 피할 수 있다.

 Address Space Management

가상 메모리 주소 영역(VMAR, Virtual Memory Address Regions)은 프로세스의 주소 공간을 관리하기 위한 추상화를 제공한다. 프로세스 생성시 루트 VMAR에 대한 Handle이 프로세스 생성자에게 제공된다. 이 Handle은 전체 주소 공간에 걸친 VMAR을 참조하게 된다. 이 공간은 zx_vmar_map()와 zx_vmar_allocate() 인터페이스를 통해 조각(carved up) 할 수 있다. zx_vmar_allocate()를 사용하여 주소 공간의 일부를 함께 그룹화하는데 사용할 수 있는 새로운 VMAR(하위 영역 또는 하위라고 함)을 생성 할 수 있다. 

참조 : vmar_map, vmar_allocate, vmar_protect, vmar_unmap, vmar_destroy ,

 Futexes

Futexes는 효과적인 동기화 기본 요소를 구현하기 위해 사용자 공간 원자 연산과 함께 사용되는 커널 기본 요소이다(예. Mutexes는 경합하는 경우에만 syscall을 작성해야 함). 일반적으로 이들은 표준 라이브러리의 구현 개발자에게만 관심이 있다. 지르콘의 libc와 libc++는 퓨텍스의 관점에서 구현된 뮤텍스, 조건 변수 등을 위한 C11, C++, pthread API를 제공한다.

출처: https://fuchsia.googlesource.com/zircon/+/master/docs/concepts.md

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭! 

안녕하세요? 허니데이즈입니다. 오늘은 지르콘 커널 개발에 기여하는 방법에 대해 알려드리도록 하겠습니다.

 지르콘에 패치(프로그램 수정) 기여하기
현재 지르콘 개발을 위해 많은 개발자들이 활발하게 활동하고 있으며, 새로운 기능보다는 작은 버그 수정을 통해 기여할 수 있다. 때문에 지르콘 개발을 위한 Process, Style, Documentation 등 3가지 지침(2018.08.02)이 있다.

 Process

1. GitHub에서 프로그램 패치 요청이 허용되지 않는다. 패치는 Gerrit Code Review를 통해서만 처리된다.

2. freenode irc Network의 #fuchsia 채널은 질의문탑하기 좋다.

3. 커밋 주제에 [tags]를 포함하면 모듈, 라이브러리, 앱 등이 변경의 영향을 받는다. 여기 스타일은 다소 비형식적으로 진행된다. 과거 변경사항을 살펴보고 이 변경사항이 어떻게 사용되는지 확인해야 한다. Gerrit Needs Label: Commit-Message-has-tags가 누락된 경우 변경사항을 플래그로 표시된다.

4. Test: <how this was tested> 커밋 메시지와 같은 라인을 포함하거나 그렇지 않으면 Gerrit가 변경 내용을 Needs Label: Commit-Message-has-TEST-line 플래그로 표시한다.

5. 전체 (Java 스타일) 정규 표현식은 (?i:test|tests|tested|testing)[ \t]*[=:] 이므로 TESTED=asdf 또는Testing : 1234 같은 행이 유효하며 Test: 만을 포함하는 행과 함께 다음 행의 세부 사항이 포함된다
6. [Googler 전용] 일반적으로 메시지는 문제 ID를 참조 할 수 있으며, 이 ID는 Gerrit UI에서 링크로 바뀌게 된다. 또한 문제는 BUG-123 #done 구문을 사용하여 자동으로 닫을 수 있다. 참고로 지르콘의 이슈 트래커는 현재 외부 참여자에게는 공개되지 않았다.

7. 지르콘은 모든 주요 타겟 (x86-64, arm64)을 변경할 때마다 빌드 가능해야 한다. ./scripts/build-all-zircon이 도움이 될 수 있다.

8. 단위 테스트를 위반하면 안된다. Zircon을 부팅하고 "runtests"를 실행하여 모두 통과하는지 확인해야 한다.

9. 공백(Whitespace)이나 스타일 변경을 피해야 한다.

10. 가능한 경우, 여러 모듈을 한꺼번에 변경하는 변경을 피해야 한다. 대부분의 변경사항은 단일 라이브러리, 드라이버, 앱 등으로 변경해야 한다.

 Style

코드 스타일은 대부분 다음을 제외하고 Google C++ 스타일 가이드를 따르면 된다.

1. 기존 코드를 편집할 때 로컬 스타일과 일치해야 한다. 이눈 다른 스타일 규칙보다 우선 시 된다.

2. 최대 라인 너비는 80 보다는 100자로 한다.

3. 들여쓰기는 두 개가 아닌 네 개의 공백이다. 탭은 사용하지 않으며 라인에 뒤 공백을 만들지 않는다. Gerrit는 diff에서 빨간색 배경을 사용하여 잘못된 공백 사용을 표시한다.

4. 지르콘은 포인터 선언 char* p로 표현한다. char *p로 표현하지 않는다. 지르콘은 asterisk-with-name 대신 asterisk-with-type으로 표준화 하였다.

switch 문에서 case 레이블은 들여 쓰지 않아야 한다.

5. Put curly braces around the body of any loop and in any if statement where the body is on another line (including any if statement that has an else if or else part). 다음과 같이 쓸수 있다.

다음과 같이 작성하지 않아야 한다.

다음과 같이 작성하지 않아야 한다.

이 규칙에 의해 시행되지 않으므로 clang-fmt 코드 작성이나 커밋 검토시 주의해야 한다.

6. ./scripts/clang-fmt 파일을 다시 포맷 하려면 실행할 수 있다 . 인수로 파일 이름을 전달하면 된다.

clang-fmt 스크립트가 자동으로 다운로드하고 clang-format 바이너리를 실행한다. 라인 길이를 제외하고 대부분의 스타일 문제 clang-format가 수정된다.

 Documentation

문서는 Markdown 파일에 있어야 한다. Google의 Markdown은 main repo browser의 Gitiles와 the mirrored repo의 Github에서 렌더링된다. 두 웹사이트에서 문서가 어떻게 렌더링되는지 확인해야 한다. 몇 가지 주목할만한 문서는 docs/syscalls.md에 syscall 목록이 있고, docs/kernel_cmdline.md에 커널 cmdline 옵션 목록이 있다. syscalls 또는 cmdlines를 편집하거나 추가할 때 문서를 업데이트 해야 한다! h2md 도구는 소스 파일을 뽑아 내장된 Markdown을 추출 할 수 있다. 현재는 DDK용 API 문서를 생성하는데 사용되고 있다. ./scripts/make-markdown 에는 system/ 트리의 모든 소스 파일에 대해 h2md를 실행한다.

출처: https://fuchsia.googlesource.com/zircon/+/master/docs/contributing.md

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭! 

안녕하세요? 허니데이즈입니다. 오늘은 퓨시아 운영체제의 기반이 되는 지르콘 커널 개발 환경을 만드는 방법에 대해 알아 보도록 하겠습니다.

 지르콘 소스코드는 어디에서 다운로드 받나요?

퓨시아 운영체제 소스에는 지르콘 커널 소스가 포함되어 있다. 때문에 퓨시아 문서를 참조하면 된다. 단, 지르콘 커널만 작업하려면 한다면 다음과 같이 실행하면 된다.
The Zircon Git repository: https://fuchsia.googlesource.com/zircon

만약, 본인의 환경에서 $SRC 변수를 설정하였다면 다음과 같이 클론을 활용하면 된다.

지르콘이 $SRC/zircon에서 체크아웃되고 툴체인, QEMU 등을 빌드하는 환경을 가정한다. 다양한 make 호출은 병렬 make를 위한 "-j32" 옵션과 함께 제공된다. 본인의 컴퓨터 사양에 따라 -j16 또는 -j8을 시도해 봐도 좋다.

 빌드 환경은 어떻게 하나요?

우분투를 사용하는 유저라면 다음과 같이 사전에 필수적으로 설치해야 하는 사항이 있다.

macOS 의 경우는 다음의 순서를 따른다.

1. Xcode 명령어 도구 설치

2. 필수적으로 설치해야 하는 사전 준비사항은 다음과 같다.

 - Homebrew를 사용한다면,

 - MacPorts 사용한다면,

 툴체인 설치는 어떻게 하나요?

Linux나 MacOS에서 개발중인 경우, 사전 작성된 툴체인 바이너리가 사용 가능하다. 지르콘 디렉토리에서 다음과 같이 스크립트를 실행하면 된다.

 툴체인이 무엇인가요? 주로 다른 컴퓨터 또는 시스템의 소프트웨어 제품을 만드는데 사용되는 컴퓨터 프로그램 개발 도구들의 집합이다. 일반적으로 여기에 포함된 개발 도구들은 연쇄적으로 사용된다. 즉, 어느 한 개발 도구의 출력은 다른 개발 도구의 입력이 된다. 그러나 이 용어는 서로 관련 있는 개발 도구들의 집합을 가리키는 의미로도 널리 사용된다. 간단한 툴체인은 소스 코드 편집을 위한 문서 편집기와 소스 코드를 실행 프로그램으로 변환하는 컴파일러와 링커, 그리고 운영 체제의 기능을 제공하는 라이브러리로 구성된다. 비디오 게임과 같은 복잡한 제품에서는 소리 효과와 음악, 텍스처, 3차원 모델, 애니메이션 등을 위한 개발 도구가 필요하며, 이를 한데 모아 완성된 제품으로 만드는 개발 도구도 있어야 한다.

 지르콘 커널 빌드는 어떻게 하나요?
빌드 결과는 $SRC/zircon/build-{arm64,x64} 에 생성이 되며 아래 예제의 $BUILDDIR 변수는 해당 빌드의 빌드 출력 디렉토리를 나타낸다.

Clang를 활용하여 지르콘 빌드는 어떻게? Clang을 타겟 툴체인으로 사용하여 지르콘을 빌드하려면 다음과 같이 USE_CLANG=true를 Make 호출 할 때 변수 설정해야 한다.

 모든 타겟에 지르콘을 빌드하려면?

모든 아키텍처에서 빌드가 작동하도록 제출하기 전에 모든 대상에 대해 빌드해야 한다.

 QEMU란?
실제 하드웨어에서 테스트하는 경우에는 필요 없지만 에뮬레이터는 빠른 로컬 테스트에 유용하며 일반적으로 사용할 가치가 있다. 지르콘과 함께 QEMU를 만들고 사용하는 방법에 대한 정보는 QEMU를 참조하면 된다.

 지르콘과 파일 복사하는 방법은?

로컬 링크 IPv6을 구성하면 호스트 도구 ./build-ARCH/tools/netcp를 사용하여 파일을 복사 할 수 있습니다.
유저를 위한 추가 공간 파일 포함해야 한다. 지르콘 빌드는 부팅할 시스템(장치 관리자, 일부 장치 드라이버 등)에 필요한 사용자 공간 구성요소가 들어있는 bootfs 이미지를 만든다. 커널은 QEMU나 부트로더가 램디스크 이미지로 제공하는 두 번째 bootfs 이미지를 포함 할 수 있다. bootfs 이미지를 만들려면 빌드의 일부로 생성된 zbi 도구를 사용해야 한다. 소스 디렉토리(지정된 디렉토리의 모든 파일과 서브 디렉토리가 포함되어 있음)나 include 할 파일을 파일별로 지정하는 Manifest 파일을 통해 bootfs 이미지를 어셈블 할 수 있다.

부팅 된 지르콘 시스템에서 bootfs의 파일은 /boot 아래에 표시되므로 위 예제에서 "hosts" 파일은 /boot/etc/hosts에 있다. QEMU의 경우, run-zircon-* 스크립트에 -x 옵션을 사용하여 추가 bootfs 이미지를 지정할 수 있다.

네트워크 부팅은 어떻게 하나요?
네트워크 부팅은 Gigaboot이나 Zirconboot의 두 가지 메커니즘을 통해 지원된다. Gigaboot는 EFI 기반 부트로더이며 zirconboot는 지르콘 시스템이 최소한의 부트로더 역할을 하도록하는 메커니즘이다.

EFI를 통해 부팅하는 시스템(예: Acer, NUC)에서 두 옵션 중 하나를 사용할 수 있다. 다른 시스템에서는 zirconboot가 네트워크 부팅을 위한 유일한 옵션 일 수 있다. Gigaboot를 통해 부팅을 시도한다면 GigaBoot20x6 부트로더는 사용하기 위해 특별한 호스트 구성이나 권한있는 액세스가 필요없는 간단한 네트워크 부팅 프로토콜(over IPV6 UDP)을 사용한다. 이는 IPV6 링크 로컬 어드레싱과 멀티 캐스트를 활용하여 부팅되는 장치가 부팅 가능성을 알리고 호스트가 이를 찾도록하고 시스템 이미지를 시스템에 보내도록 허용한다. GigaBoot20x6을 실행하는 장치(예: Broadwell이나 Skylake Intel NUC)가 있는 경우 먼저 스크립트를 사용하여 수동으로 USB 드라이브를 만들거나 (Linux 전용) 만들면 된다.

기본적으로 bootserver는 계속 실행되며 netboot 비컨을 볼 때마다 커널(이나 제공된 bootfs)을 해당 장치로 보낸다. -1 옵션을 전달하면 부트 성공 후 부트 서버가 종료된다.

Zirconboot를 통해 부팅을 시도한다면 Zirconboot는 지르콘 시스템이 지르콘 자체의 부트로더 역할을 하도록 해야 한다. Zirconboot는 위에서 설명한 Gigaboot와 동일한 부팅 프로토콜을 사용한다. zirconboot를 사용하려면 netsvc.netboot=true 커널 명령어를 통해 인수를 지르콘에 전달해야 한다. Zirconboot가 시작되면 연결된 호스트에서 실행중인 부트 서버에서 지르콘 시스템으로 패치하고 부트합니다.

 네트워크 로그 보는 방법은?
지르콘의 기본 빌드에는 링크 로컬 IPv6 UDP를 통해 시스템 로그를 멀티캐스트하는 네트워크 로그 서비스가 포함되어 있다. 이는 빠르게 프로토콜의 상태를 알 수 있다. 현재 -N 플래그가 있는 QEMU에서 지르콘을 실행 중이거나 지원 가능한 이더넷 인터페이스(ASIX USB Dongle이나 NUC의 Intel Ehternet)가 있는 하드웨어에서 실행중인 경우 loglistener 도구는 로컬 링크를 통해 브로드캐스트된 로그를 모니터링 한다.

출처: https://fuchsia.googlesource.com/zircon/+/master/docs/getting_started.md

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭! 

안녕하세요? 허니데이즈입니다.

write soon

출처: https://fuchsia.googlesource.com/zircon/+/master/docs/benchmarks/microbenchmarks.md

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭!