1

我需要编写一个库（在 C++ 中），它将模拟类似 NOR 闪存的行为。（平台-Windows，语言-C++）（对不起，很长的帖子，我试图解释我到目前为止所做的事情:)）

要求的行为：

所以，这就是它应该如何工作的，我需要返回内存范围，用户将使用它作为闪存。他应该能够从返回的内存缓冲区中读取任何字节，这不是问题，主要问题在于写入，因为闪存的写入行为不同，因此您只能重置一点，如果地址有内容（二进制） 10101010 并且用户尝试将 01011001 写入该地址，然后该位置在写入后实际上应该包含 10101010 和 01011001 = 00001000。我不知道如何完成这项工作！

这些是我正在考虑的方法：

我需要将数据存储为内部文件，以便能够多次使用它并在多次使用后进行分析，所以我打算使用内存映射文件-IO 来返回内存。读取不是问题，但我不确定如何在写入之前捕获内存写入并应用 AND 掩码。

以下是我想到的一些方法...

方法一：

将暴露的指针标记为只读，因此允许用户直接从内存中读取，但对于写入，我们可以暴露一个接口，该接口将是写入内存的唯一接口。由于它是我们的接口，我们可以处理应用遮罩的要求。

优点：

=> 保持实现简单。

缺点：

=> 通过限制用户写入来降低模块的可用性。

方法二：

编写一个将重载所有可能的内存访问运算符的类。像这样的东西

template <class T> class flashMemory
{
    T data;
public:
    void operator = (T newData) {data &= newData};
    // Overload other operators too...
};

优点：=> 再次保持实现简单。

缺点：=> 尽管我们可以处理大多数写情况，但在以下代码片段中我们无法处理这些情况。

flashMemory *flashPtr = flashObj.getPointer();
flashPtr[10] = 'X';                        //Using overloaded operator, This is fine
memcpy(flashPtr, someBuff, someSize);    //This is NOT fine
...
char *myPtr = (void*)flashPtr;    //Everything below using typecasted ptr is NOT fine. 
myPtr[100] = 'X';
memcpy(myPtr, 0, someSize);
memcpy(myPtr, destPtr, dataSize);

因此，这可能又不是一个完整的解决方案，并且实际上可能会导致任何新代码出现很多问题。

方法3：

第三种方法是将页面保护设置为 READ_ONLY 并通过信号处理程序（Linux 上的 mprotect 和 sigaction）捕获任何写入尝试，但到目前为止，我只能捕获写入调用，但还不能获取更多信息来完成写入请求. 将对其进行调查，看看是否有可能在应用掩码后捕获写入调用和写入数据。如果这是可能的，它可以是完整的解决方案。

优点：

1) 可以透明地处理写入请求，而无需使用模拟器对用户进行任何更改。

这看起来很完美，但我只能得到说存在访问冲突的中断，但我不知道如何在中断处理程序中写入数据之前实际获取正在写入的数据并应用掩码！（但我在 Linux 中尝试过，在 Windows 中没有这样做）

方法4：

有一些具有内存映射 IO 的模拟设备，任何对设备内存范围的写入都将进入我的设备驱动程序，我可以用它做任何我想做的事情。

这只是一个想法，我不确定这是否可以做到，即使做到了，也可能对我的要求有点过头了。

方法4：

为了支持像方法 3 中那样透明地读写，我们可以使用 linux 的 FUSE 框架等效于 Windows（截至目前，我得到了 DOKAN http://dokan-dev.net/en/和 CBFS http://www.eldos。 com/cbfs/）。使用它，我们可以将我们的代码作为文件系统呈现给系统，所有读写调用都将转移到用户空间中的代码，我们可以在其中随意操作数据。所以，我们的代码将有两部分，

  1. 将 flash_emulator 类公开给应用程序编写器（我们现在拥有的）的库，=> 这将在我们创建的用户空间文件系统中打开 flash 仿真文件，并执行内存映射文件 io 并将映射地址返回到用户，应用程序编写者可以使用它来执行将转换为文件系统操作（读取和写入）的内存操作。

  2. 简单的用户空间文件系统。=> 这将实现用户空间文件系统所需的基本必需接口，并在内部使用系统文件系统来实际存储文件。实现的读写操作将访问存储在磁盘上的数据。读取将像我们现在一样从文件中直接读取，但写入操作将应用掩码并写入文件系统。

优点： => 可以透明地支持所有内存操作并在后台模拟类似闪存的行为。

缺点：=> 它需要需要使用的外部框架，这将比我们编写的代码大得多。（我需要检查它们是否是免费的框架，我还不确定，如果它们不是免费的，将检查并返回）

实现用户空间文件系统只是为了具有透明的类似闪存的写入特性可能是一种矫枉过正，但如果在不影响应用程序编写器代码的情况下这样做更重要，那么这看起来是一种可能性。请让我知道您对此的看法。谢谢你。

谢谢，

微内核

4

0 回答 0