Reorganize the codebase for clarification and scabability

[tatetian]

Motivation

The organization of the codebase (under src/) is not clear. The situation will become even worse as more crates are added. We propose to reorganize the codebase so that the code structure reflects privilege separation more clearly. Specifically, we want to

• Make it obvious which crates are privileged and which are not.
• Keep this obviousness even if the current crates are divided into more smaller crates for modularity and many new crates are added.

In addition to distinguishing between privileged and unprivileged code, the reorganization can also help with:

• Distinguishing between KxOS-specific crates and general-purpose crates. For example, the type-flags crates do not depend on KxOS or include any KxOS-specific code. So the crates' name should not begin with kxos_.
• Distinguishing between library crates and components crates. Libraries provide utilities, while components control resources. Some examples of library crates include type-flags, kxos-rights, and kxos-std, while components crates include kxos-syscall (extract all system call dispatching logic from kxos-std to this new crate), kxos-pci (which controls the PCI subsystem), and kxos-virtio (which manages the virtio drivers).

Proposed changes

The new code structure would look like the following.

kxos/
    src/
        kxos-boot/
        framework/
            kxos-frame/
            pod/
            pod-derive/
        services/
            libs/
                kxos-std
                kxos-rights
                kxos-rights-proc
                kxos-util
                type-flags
                type-flags-util
            comps/
                kxos-syscall
                kxos-pci
                kxos-virtio
        apps/
        tests/
    README.md 

Some notes.

• PODs should be put in a separate crate named pod because this is independent of kxos-frame. And pod-derive crate only depends on pod crate.
• user/ is renamed to apps, the latter of which seems to be more clear.
• I have some initial thoughts on implementing component-level access control mechanism in addition to our current object-level access control mechanism based on zero-cost capabilities. This idea is originally proposed in CapComp. I need to adapt the original design for KxOS. By putting all components under comps, it becomes clear which crates are subject to access control and which are not.
• Need to update src/README.md.
• One should use his or her best judgement when extracting "component code" from kxos-std to kxos-syscall, while leaving "library code" in kxos-std.

[StevenJiang1110]

Fixed