refactor: namespace

[AsakuraMizu]

Description

This PR replaces the axns module with https://github.com/starry-OS/axns crate to enhance its functionality and resolve the memory leaking issue.

The second commit merged CURRENT_DIR_PATH in axfs into CURRENT_DIR to allow easier management.

Issues

1. FlattenObjects does not impl Clone and we can not write a copy_inner like before. Maybe we'd better improve flatten_objects.
2. Do we have to use ctor_bare anymore?
3. axfs refactor is on its way at https://github.com/Starry-OS/axfs-ng so I don't change it too much.

[Azure-stars]

Why combine CURRENT_DIR_PATH and CURRENT_DIR into one variable?

[AsakuraMizu]

They should always be modified at the same time, and not doing so would be a semantic error. Using a single variable facilitates management and avoids errors when writing code.

[Azure-stars]

Can we publish the axns to crates.io? Maybe this crate doesn't need to modified frequently?

[AsakuraMizu]

Well it's fine, but since it is an ArceOS related module, I was worried about the owner and permissions so I didn’t do it.

[AsakuraMizu]

I would also like to discuss the design of axns here. For the current design, if you need to access resources in the current namespace, you must first call current on the resource to acquire the current namespace. Is this good? Here are issues:

1. Overhead of re-acquiring the namespace every time accessing a resource.
2. Unnecessary extra acquisition: If you hold a reference to a resource, when the namespace reference/lock acquired has not been released, it is not necessary to obtain the current namespace again if you want to access other resources. Even worse, when the implementer uses Mutex instead of RwLock to wrap the namespace, a deadlock will occur. (Well it's not actually a issue for us; but a issue for the design of axns)

I am currently inclined to a way that requiring users to register the currently active namespace in a similar way to how Rust async runtime libraries manage active runtime (see Tokio/compio). If there is no active namespace, accessing resources will panic. For example, in our starry-next implementation, we may have to add a line to the beginning of handle_syscall:

let _guard = axns::set_current_ns(xxx);

And the current namespace get cleared when the guard dropped. But this also have issues:

1. Not all syscalls requires a active namespace. We cannot ignore the overhead of activating the namespace for all syscalls. Even some requires no active namespace notably unshare since it requires exclusive access to the namespace.
2. But if we don't, we have to be very careful when to activate it. Many access to resources may be implicit. Forgetting to activate a namespace leads to a panic: but fortunately, this situation is easy to spot and debug.

This is a balance between cost and convenience.

[Azure-stars]

I would also like to discuss the design of axns here. For the current design, if you need to access resources in the current namespace, you must first call current on the resource to acquire the current namespace. Is this good? Here are issues:

1. Overhead of re-acquiring the namespace every time accessing a resource.
2. Unnecessary extra acquisition: If you hold a reference to a resource, when the namespace reference/lock acquired has not been released, it is not necessary to obtain the current namespace again if you want to access other resources. Even worse, when the implementer uses Mutex instead of RwLock to wrap the namespace, a deadlock will occur. (Well it's not actually a issue for us; but a issue for the design of axns)

I am currently inclined to a way that requiring users to register the currently active namespace in a similar way to how Rust async runtime libraries manage active runtime (see Tokio/compio). If there is no active namespace, accessing resources will panic. For example, in our starry-next implementation, we may have to add a line to the beginning of handle_syscall:

let _guard = axns::set_current_ns(xxx);

And the current namespace get cleared when the guard dropped. But this also have issues:

1. Not all syscalls requires a active namespace. We cannot ignore the overhead of activating the namespace for all syscalls. Even some requires no active namespace notably unshare since it requires exclusive access to the namespace.
2. But if we don't, we have to be very careful when to activate it. Many access to resources may be implicit. Forgetting to activate a namespace leads to a panic: but fortunately, this situation is easy to spot and debug.

This is a balance between cost and convenience.

Since the addressing of namespace is for tasks, namespace switching can be done with task switching. But this introduces a new problem. Namespace is managed by task ext. Can we add a switch function for task extension content in axtask/switch_to to complete namespace switching in this function?

[Azure-stars]

I would also like to discuss the design of axns here. For the current design, if you need to access resources in the current namespace, you must first call current on the resource to acquire the current namespace. Is this good? Here are issues:

1. Overhead of re-acquiring the namespace every time accessing a resource.
2. Unnecessary extra acquisition: If you hold a reference to a resource, when the namespace reference/lock acquired has not been released, it is not necessary to obtain the current namespace again if you want to access other resources. Even worse, when the implementer uses Mutex instead of RwLock to wrap the namespace, a deadlock will occur. (Well it's not actually a issue for us; but a issue for the design of axns)

I am currently inclined to a way that requiring users to register the currently active namespace in a similar way to how Rust async runtime libraries manage active runtime (see Tokio/compio). If there is no active namespace, accessing resources will panic. For example, in our starry-next implementation, we may have to add a line to the beginning of handle_syscall:

let _guard = axns::set_current_ns(xxx);

And the current namespace get cleared when the guard dropped. But this also have issues:

1. Not all syscalls requires a active namespace. We cannot ignore the overhead of activating the namespace for all syscalls. Even some requires no active namespace notably unshare since it requires exclusive access to the namespace.
2. But if we don't, we have to be very careful when to activate it. Many access to resources may be implicit. Forgetting to activate a namespace leads to a panic: but fortunately, this situation is easy to spot and debug.

This is a balance between cost and convenience.

Since the addressing of namespace is for tasks, namespace switching can be done with task switching. But this introduces a new problem. Namespace is managed by task ext. Can we add a switch function for task extension content in axtask/switch_to to complete namespace switching in this function?

We temporarily call the switching function for Task Extension as Ext_Switch. The functions that can be completed in this function include but are not limited to:

• Record task running time
• Switch the currently running namespace
• Implement mm and active_mm mechanisms similar to Linux
• Etc.

Therefore, the implementation of this mechanism will have certain significance.

[Azure-stars]

1. Overhead of re-acquiring the namespace every time accessing a resource.
2. Unnecessary extra acquisition: If you hold a reference to a resource, when the namespace reference/lock acquired has not been released, it is not necessary to obtain the current namespace again if you want to access other resources. Even worse, when the implementer uses Mutex instead of RwLock to wrap the namespace, a deadlock will occur. (Well it's not actually a issue for us; but a issue for the design of axns)

In what cases is it necessary to use Mutex or RwLock to wrap the namespace? Should the granularity of mutual exclusion access be limited to resources rather than namespaces?

[Azure-stars]

This is a balance between cost and convenience.

Compared to considering the performance of namespace access, I think we should pay more attention to the scenarios where the namespace mechanism is used. Currently, there are not many resources using namespaces. Is it necessary to expand the usage scenarios of namespaces and make more content become resources of namespaces?

Because an important goal of namespace is to use the same set of management logic (code) to control resources from different sources, so as to achieve sharing between Unikernel and Monolithic kernel. However, current development does not seem to pay special attention to this. One evidence is that we do not define resources in a way that is convenient for namespace management.

[AsakuraMizu]

In what cases is it necessary to use Mutex or RwLock to wrap the namespace? Should the granularity of mutual exclusion access be limited to resources rather than namespaces?

This is mainly considered to implement unshare syscall.

[AsakuraMizu]

Since the addressing of namespace is for tasks, namespace switching can be done with task switching. But this introduces a new problem. Namespace is managed by task ext. Can we add a switch function for task extension content in axtask/switch_to to complete namespace switching in this function?

We temporarily call the switching function for Task Extension as Ext_Switch. The functions that can be completed in this function include but are not limited to:

* Record task running time

* Switch the currently running namespace

* Implement `mm` and `active_mm` mechanisms similar to Linux

* Etc.

Therefore, the implementation of this mechanism will have certain significance.

Currently, there are not many resources using namespaces. Is it necessary to expand the usage scenarios of namespaces and make more content become resources of namespaces?

Because an important goal of namespace is to use the same set of management logic (code) to control resources from different sources, so as to achieve sharing between Unikernel and Monolithic kernel.

OK, you may have inspired my craziest idea. We can even use this system to manage the address space! This is effectively the same as how we define a shareable resource now: globally unique for a unikernel, task-specific for a monolithic kernel, and shareable between tasks. And with the switching mechanism, we can move the code for page table switching out from axhal.

The only problem with this design is that it goes out of scope 😂

[AsakuraMizu]

Closing this for now.