兼容问题
为了保证Starry在未来的泛用性,我们在比赛开发过程中便有意识地去注意不同架构下的实现兼容,并采用条件编译等方式进行区分。如process部分的结构体的定义为:
pub struct ProcessInner {
/// 父进程的进程号
pub parent: u64,
/// 子进程
pub children: Vec<Arc<Process>>,
/// 子任务
pub tasks: Vec<AxTaskRef>,
/// 地址空间,由于存在地址空间共享,因此设计为Arc类型
pub memory_set: Arc<SpinNoIrq<MemorySet>>,
/// 用户堆基址,任何时候堆顶都不能比这个值小,理论上讲是一个常量
pub heap_bottom: usize,
/// 当前用户堆的堆顶,不能小于基址,不能大于基址加堆的最大大小
pub heap_top: usize,
/// 进程状态
pub is_zombie: bool,
/// 退出状态码
pub exit_code: i32,
// /// 文件描述符表
// pub fd_table: Vec<Option<Arc<SpinNoIrq<dyn FileIO>>>>,
// /// 文件描述符上限,由prlimit设置
// pub fd_limit: usize,
#[cfg(feature = "fs")]
pub fd_manager: FdManager,
/// 进程工作目录
pub cwd: String,
#[cfg(feature = "signal")]
/// 信号处理模块
/// 第一维代表线程号,第二维代表线程对应的信号处理模块
pub signal_module: BTreeMap<u64, SignalModule>,
/// robust list存储模块
/// 用来存储线程对共享变量的使用地址
/// 具体使用交给了用户空间
pub robust_list: BTreeMap<u64, FutexRobustList>,
}
其额外限定了fs和signal的feature,规定了信号模块和文件系统模块的条件编译,可以根据编译参数来决定内核是否支持fs和信号模块。