refactor: split starry into multiple crates

[AsakuraMizu]

Description

This is the first part of #16, although they seem unrelated.

In order to reduce the pressure of #18 and track the file history (the file changes in #18 are too large for Git to track the file history), I created this simplified version that splits starry into three crates. And I think we should also determine the name, function and content of each module here first.

Implementation details

This PR splits starry into the following three crates:

• starry-core: monolithic kernel related stuffs, including user apps loading, process management
• starry-api: all syscalls, with address checking, optional tracing and unified return value type LinuxResult<isize>, so it's basically an advanced version of arceos_posix_api (we will later merge the similar part of arceos_posix_api into this later)
• starry(main crate): entrypoint for the kernel

TODO

• Where to put posix-like/unix-like functionality later? A separate crate or core?

[Azure-stars]

What mean posix-like/unix-like functionality exclude syscall? Any example for this?

[Azure-stars]

Why remove it?

[AsakuraMizu]

If we want to provide a public API, I think it is best not to expose different functions on different hardware architectures? After all, sys_open of arceos_posix_api is also available on all architectures.

[Azure-stars]

If the current crate is designed for syscall, I think it is possible to design functions strictly according to the man page. Otherwise, when the user enables target_arch=riscv64 and finds syscall_open and syscall_openat at the same time, he may feel confused?

[Azure-stars]

What mean posix-like/unix-like functionality exclude syscall? Any example for this?

If you mean methods like clone_task of TaskExt, for this type of method, the interface it provides is generally similar to the POSIX interface. I think it is suitable to be placed in the api crates

But I think part of the core content can also be abstracted into independent crates, such as ptr and task. ptr is relatively easy to be independent, and taskext hopes to be abstracted into a process management crate, providing some more general interfaces and converting them into POSIX-compatible interfaces at the api layer.

[Azure-stars]

An example can be seen at https://github.com/arceos-hypervisor/axvcpu

[Azure-stars]

Can we seperate this or other part as a seperate crate, refer to #22 (comment)

[AsakuraMizu]

But I think part of the core content can also be abstracted into independent crates, such as ptr and task. ptr is relatively easy to be independent, and taskext hopes to be abstracted into a process management crate, providing some more general interfaces and converting them into POSIX-compatible interfaces at the api layer.

I am now trying to abstract the logic of TaskExt. But I need to mention that the current design of the ptr module is largely due to the need to pass raw pointers when calling arceos_posix_api. When we integrate arceos_posix_api later, it will be transformed into a safer interface, such as directly obtaining &mut T/&[T], etc.

[AsakuraMizu]

What mean posix-like/unix-like functionality exclude syscall? Any example for this?

Most notably: the file descriptor table FD_TABLE. Although it's heavily related to unix-like syscalls, it is thread local and we also need to maintain it in the process management module.

[AsakuraMizu]

But I think part of the core content can also be abstracted into independent crates, such as ptr and task. ptr is relatively easy to be independent, and taskext hopes to be abstracted into a process management crate, providing some more general interfaces and converting them into POSIX-compatible interfaces at the api layer.

Do you have any ideas on naming? Should we stick with the ax* style or prefer starry-*?

[Azure-stars]

But I think part of the core content can also be abstracted into independent crates, such as ptr and task. ptr is relatively easy to be independent, and taskext hopes to be abstracted into a process management crate, providing some more general interfaces and converting them into POSIX-compatible interfaces at the api layer.

Do you have any ideas on naming? Should we stick with the ax* style or prefer starry-*?

use ax* style because we will uniform it with arceos

[Azure-stars]

But I think part of the core content can also be abstracted into independent crates, such as ptr and task. ptr is relatively easy to be independent, and taskext hopes to be abstracted into a process management crate, providing some more general interfaces and converting them into POSIX-compatible interfaces at the api layer.

Do you have any ideas on naming? Should we stick with the ax* style or prefer starry-*?

And the TaskExt should be abstracted as axprocess

[Azure-stars]

But I think part of the core content can also be abstracted into independent crates, such as ptr and task. ptr is relatively easy to be independent, and taskext hopes to be abstracted into a process management crate, providing some more general interfaces and converting them into POSIX-compatible interfaces at the api layer.

I am now trying to abstract the logic of TaskExt. But I need to mention that the current design of the ptr module is largely due to the need to pass raw pointers when calling arceos_posix_api. When we integrate arceos_posix_api later, it will be transformed into a safer interface, such as directly obtaining &mut T/&[T], etc.

Yep but we can also abstract the Taskptr with the method to pass the raw pointer to make it more general.

[Azure-stars]

What mean posix-like/unix-like functionality exclude syscall? Any example for this?

Most notably: the file descriptor table FD_TABLE. Although it's heavily related to unix-like syscalls, it is thread local and we also need to maintain it in the process management module.

It may need to store at the api? Because the api crate is designed for POSIX, and the core is for monolithic architecture (privileged level isolation, process management, address space isolation and so on).

[AsakuraMizu]

Note here: We decided to do modularization separately later and keep this PR just for the basic split of starry.