Documentation/translations/zh_CN/core-api/assoc_array.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/zh_CN/core-api/assoc_array.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/zh_CN/core-api/assoc_array.rst
Extension
.rst
Size
19546 bytes
Lines
474
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

struct assoc_array {
            ...
    };

该代码是通过启用 ``CONFIG_ASSOCIATIVE_ARRAY`` 来选择的，以::

    ./script/config -e ASSOCIATIVE_ARRAY


编辑脚本
--------

插入和删除功能会产生一个“编辑脚本”，以后可以应用这个脚本来实现更改，而不会造成 ``ENOMEM``
风险。这保留了将被安装在内部树中的预分配的元数据块，并跟踪应用脚本时将从树中删除的元数
据块。

在脚本应用后，这也被用来跟踪死块和死对象，以便以后可以释放它们。释放是在RCU宽限期过后
进行的--因此允许访问功能在RCU读锁下进行。

脚本在API之外显示为一个类型为::

    struct assoc_array_edit;

有两个处理脚本的功能:

1. 应用一个编辑脚本::

    void assoc_array_apply_edit(struct assoc_array_edit *edit);

这将执行编辑功能，插值各种写屏障，以允许在RCU读锁下的访问继续进行。然后，编辑脚本将被
传递给 ``call_rcu()`` ，以释放它和它所指向的任何死的东西。

2. Cancel an edit script::

    void assoc_array_cancel_edit(struct assoc_array_edit *edit);

这将立即释放编辑脚本和所有预分配的内存。如果这是为了插入，新的对象不会被这个函数释放，
而是必须由调用者释放。

这些函数保证不会失败。


操作表
------

各种功能采用了一个操作表::

    struct assoc_array_ops {
            ...
    };

这指出了一些方法，所有这些方法都需要提供:

1. 从调用者数据中获取索引键的一个块::

    unsigned long (*get_key_chunk)(const void *index_key, int level);

这应该返回一个由调用者提供的索引键的块，从level参数给出的 *比特* 位置开始。level参数将
是 ``ASSOC_ARRAY_KEY_CHUNK_SIZE`` 的倍数，该函数应返回 ``ASSOC_ARRAY_KEY_CHUNK_SIZE``
位。不可能出现错误。


2. 获取一个对象的索引键的一个块::

    unsigned long (*get_object_key_chunk)(const void *object, int level);

和前面的函数一样，但是从数组中的一个对象而不是从调用者提供的索引键中获取数据。


3. 看看这是否是我们要找的对象::

Annotation

Implementation Notes