Wenyu Su

想请教一下关于`BlockCacheManager`的实现，`VecDeque`中只以`block_id`作为标识的话，同时读写不同设备的同一个block时不会有冲突吗

@wyfcyx 明白了，感谢

请问virtio-drivers中`VirtIOBlk`的`read_block`和`write_block`实现是否也要求传入的`buf`所在的物理内存地址区域是连续的？我在物理页不连续的内核栈上调用`read_block`时会读到一些脏数据，会是这里的问题吗？

@wyfcyx 感谢回复，教程中似乎并没有对此做相关处理，是否可以在kernel中单独分配一些物理页用作`VirtIOBlk`读写操作的缓冲？在操作`BlockCache`时读写这些固定的物理页面。 或是将类似功能集成到virtio-drivers中，在`virtio_dma_alloc`时再多请求一些用于缓冲的物理页，会是好的实现吗？

@PeterWrighten 简单阅读了一下对应的章节，感觉上一章的`BlockCacheManager`就已经是Dynamic比较好的实现了，只需要更新Cache替换算法即可。而之前的comment主要是针对加载`BlockCache`时dma在物理地址上顺序读写，但虚拟地址实际对应的物理地址不连续导致的问题，已经[通过BuddySystem解决](https://github.com/rcore-os/rCore-Tutorial-v3/pull/79)。

Regarding the minlen bound, in readme it saids that it implement FF1 specified in [NIST Special Publication 800-38G](http://dx.doi.org/10.6028/NIST.SP.800-38G), but the [`MIN_NS_DOMAIN_SIZE`](https://github.com/str4d/fpe/blob/main/src/ff1.rs#L36) is actually from [NIST SP 800-38G Revision 1](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38Gr1-draft.pdf), which...

raised another PR #228 since there's no progress for a long time

According to the [SAFETY comment](https://github.com/parallaxsecond/rust-cryptoki/blob/main/cryptoki/src/mechanism/mod.rs#L1039), rust-cryptoki assumes all the supported mechanisms will not mutate the parameters, but it actually depends on the specific HSM vendor? All the pointer casts will...