kaist-cp/hafnium-verification

Refactoring: big picture.

efenniht opened this issue · 1 comments

본격적으로 Refactoring을 하기에 앞서서 어떻게 하면 좋을 지 나름의 생각을 정리해 보았습니다:

목표

여기서 목표는, 평가 수단이자 refactoring 방향의 이정표입니다.

unsafe block의 수와 양 줄이기

궁극적으로 모든 unsafe 코드를 고칠 수는 없지만, 줄이는 것은 검증에 도움이 됩니다. 어떤 코드가 unsafe Rust인지는 Rust book에 나와 있습니다: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

  • Dereferencing a raw pointer
  • Calling an unsafe function or method
  • Access or modify a mutable static variable
  • Implement an unsafe trait

좀 더 공격적으로 unsafe한 코드를 fine graining 해 봅시다!

Encapsulation

현재 코드를 많은 부분 OOP스럽게 만들 수 있습니다:

  • 정말로 필요한 경우를 제외하고 field를 private으로 만들기
  • 전역 함수 대신 method를 사용하기
  • new() 로 초기화하기
  • RAII

Use rich type system

  • 결과를 Option 또는 Result로 나타내기: #34
  • 똑똑하게 enum 사용하기
  • ...

방법

쉬움

  • 상수를 enum 으로 바꾸기 (ex. SPCI_SUCCESS): #13
  • HfVCpuRunReturn enum으로 바꾸기: #13
  • 인터럽트 아이디 intid 에 대한 type alias 만들기: #13
  • {mm, mpool, page}.rs 에 있는 주소를 *addr_t 로 바꾸기: #13

중간

  • 전역 함수들을 메서드로 만들고 FFI는 껍데기로 만들기
  • api.rs 에 있는 goto 문, 그리고 if blah { return -1; } 과 같은 코드를 RAII와 ? 로 깔끔하게 만들기
  • RawSpinLock 대신 SpinLock 쓰기, 단순히 전체를 lock하는 것으로 시작: #20
  • api_vcpu_prepare_run 에 대하여, 대기 중인 PR 반영하기 (#10 과 관련): #22
  • api.rs 에 있는 코드를 다른 cpu.rsvm.rs로 분산시키기 (접근하는 데이터에 따라서)
  • (위와 관련하여) 불필요한 pub 제거하기: #12
  • dlog.clock 함수가 Rust의 WRITER lock을 잡도록 하기: #

어려움

  • 누가 owner이고 누가 borrower인지 파악해서 raw pointer 멸종시키기!
  • 각각의 lock이 어떤 데이터를 배타적으로 만드는 지 확인하고 그에 알맞게 SpinLock<XXXState> 로 만들기
  • 레퍼런스를 field로 가지는 경우 적당히 Arc 같은 걸 집어넣기
  • Intrusive list 개선하기 (?)

각각의 항목에 대해서 세부 issue를 만들 예정입니다. 또 다른 제안 사항이 있으시면 말씀해 주세요~

api.rs 에 있는 goto 문, 그리고 if blah { return -1; } 과 같은 코드를 RAII와 ? 로 깔끔하게 만들기 - 이걸 먼저 하지 않으면 다른 api.rs 리팩토링을 할 때 실수할 가능성이 높아집니다!