[WIP] extract settings to the layered modules

[flier]

As you known, the procfs has hundreds of setting files, we hard to list all of them in the root namespace.

I propose to use a layered modules base on the procfs folder, for example

use procfs::sys::vm::admin_reserve_kbytes;

assert_ne!(admin_reserve_kbytes().unwrap(), 0);

[tvannahl]

That a great point, this would make it easy to apply the knowledge/documentation about proc(5) directly to a function.

How would you export the process api like /proc/<pid>/tasks?

[flier]

for /proc/sys/vm/, I think we need a macro or proc macro to define value base on filename. I guess those could be reused to export /proc/<pid>/tasks

[eminence]

Can you say some more about the macro/procmacro idea? I didn't quite understand your suggestion

[eminence]

There's a lot of great working happening in this PR -- new module layout, a new macro system, support for writing values, etc. But I think this is a lot of changes for 1 single PR.

Could we first merge the new module layout, and then work on and review the other changes?

[flier]

@eminence as you known, we need a macro system to define values.

The macro system should supports

• defne value by name and type, such as drop_caches: DropCache
• define access mode, such as readonly, writeonly and readwrite etc.
• support document with comment attribute
• don't need too many redundant information, such as full path

I have submitted a prototype base on the macro with dark magic, which export value as a named function that return a Value to get or set the /proc file, which use it's own syntax because some limitation. It should works but may become more complicated when we try to add more features, such as default value, value cache etc, and hard to maintain.

procfs_value! {
    /// Causes the kernel to drop clean caches, dentries, and inodes from memory,
    /// causing that memory to become free.
    ///
    /// This can be useful for memory management testing and performing reproducible filesystem benchmarks.
    /// Because writing to this file causes the benefits of caching to be lost,
    /// it can degrade overall system performance.
    ///
    /// # Example
    ///
    /// ```
    /// use procfs::sys::vm::{drop_caches, DropCache};
    ///
    /// if let Ok(drop_caches) = drop_caches() {
    ///     if drop_caches.writeable() {
    ///         drop_caches.set(DropCache::Default).unwrap();
    ///     }
    /// }
    /// ```
    @writeonly
    drop_caches: DropCache;
}

On the other hand, we also can define it with the proc macro, it's more nature to most Rust users.

#[derive(ProcFS)]
pub struct VM {
    /// Causes the kernel to drop clean caches, dentries, and inodes from memory,
    /// causing that memory to become free.
    ///
    /// This can be useful for memory management testing and performing reproducible filesystem benchmarks.
    /// Because writing to this file causes the benefits of caching to be lost,
    /// it can degrade overall system performance.
    ///
    /// # Example
    ///
    /// ```
    /// use procfs;
    /// use procfs::sys::vm::DropCache;
    ///
    /// procfs::sys.vm.drop_caches.set(DropCache::Default).unwrap();
    /// ```
   #[writeonly]
    drop_caches: DropCache,
}

What's you opinion?

[eminence]

I'm going to close this PR, as it's been sitting idle for quite a number of years. However, if you (or anyone else) wants to revitalize this topic, please feel free to open a new issue to talk about it. Thanks!