title: Flash Emulation library - Trapping memory write access
body: <p>I am required to write a library (in C++) which will emulate NOR flash like behavior. 
  (Platform - Windows, Language-C++)
  (Sorry for a very long post, I am trying to explain what I have done so far :) )</p>
  
  <p><strong>Required behavior:</strong></p>
  
  <p>So, this is how its supposed to work, I am required to return range of memory, which the user will use as flash memory. He should be able to read any bytes from the returned memory buffer, which is not a problem, the main problem comes in write, because, the write behavior of flashes is different, such that you can only reset a bit, if an address has content(in binary) 10101010 and user tries to write 01011001 to that address, then that location should actually contain 10101010 &amp; 01011001 = 00001000 after write. I am not sure how to get this done! </p>
  
  <p><strong>These are the approaches I am thinking of:</strong></p>
  
  <p>I need to have the data stored as a file internally to be able to use it multiple times and analyze after multiple use, so I am plaaning to use a memory mapped file-IO to return the memory. read is not an issue, but I am not sure how to trap memory writes and apply AND mask before writing it. </p>
  
  <p>Following are some of the ways I was thinking of... </p>
  
  <p><em>Approach 1:</em></p>
  
  <p>Mark the exposed pointer as readonly, hence allowing user to do direct reads from memory, but for write, we can expose an interface which will be the only interface for writing into the memory. Since its our interface, we can handle the requirement of applying masking. </p>
  
  <p>Advantages: </p>
  
  <p>=> Keeps the implementation simple. </p>
  
  <p>Disadvantages: </p>
  
  <p>=> Reduces the usability of module by putting restriction on user regarding write. </p>
  
  <p><em>Approach 2:</em></p>
  
  <p>Write a class which will overload all the possible memory access operators. Something like this</p>
  
  <pre><code>template &lt;class T&gt; class flashMemory
  {
      T data;
  public:
      void operator = (T newData) {data &amp;= newData};
      // Overload other operators too...
  };
  </code></pre>
  
  <p>Advantage: 
  => Again keeps the implementation simple. </p>
  
  <p>Disadvantage: 
  => Even though we can handle most of the write cases, we can't handle these in situations like in the following code-snippet. </p>
  
  <pre><code>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);
  </code></pre>
  
  <p>So, this might again not be a complete solution, and can actually cause lot of issues with any new code. </p>
  
  <p><em>Approach 3:</em></p>
  
  <p>Third approach is to set page protection to READ_ONLY and trap any write attempts through a signal handler(mprotect and sigaction on Linux) but as of now I can only trap the write calls but not yet able to get any more info to complete the write request. Will look into it to see if its possible to trap the write calls and write data after applying mask. 
  If this is possible, it can be complete solution. </p>
  
  <p>Advantages:</p>
  
  <p>1) Can handle write requests transparently without any changes to the user using emulator. </p>
  
  <p>This looks perfect, but I am only able to get interrupts saying there was a access violation, but I don't know how to actually get the data being written and apply mask before writing it in interrupt handler! (But I tried this in Linux, have not done this in Windows)</p>
  
  <p><em>Approach 4:</em></p>
  
  <p>Have some emulated device with memory mapped IO and any writes to the memory range of device will come to my device driver with which I can do whatever I want. </p>
  
  <p>This is just a thought, I am not sure if this could be done at all, and even if done, might be an overkill for my requirement. </p>
  
  <p><strong>Approach 4:</strong></p>
  
  <p>To support read and write transparently like in approach-3,  we can use linux’s FUSE framework equivalent of Windows (as of now I got DOKAN <a href="http://dokan-dev.net/en/" rel="nofollow">http://dokan-dev.net/en/</a> and CBFS <a href="http://www.eldos.com/cbfs/" rel="nofollow">http://www.eldos.com/cbfs/</a>). Using this we can present our code as a filesystem to the system and all the read and write calls will be diverted to our code in the user-space where we can manipulate the data anyway we want. 
  So, our code will have 2 pieces,</p>
  
  <ol>
  <li><p>The library that exposes flash_emulator class to the application writer (the one we have now), 
  => This will open flash emulation file in the user-space filesystem that we create and does a memory-mapped file-io and return the mapped address to the user, using which the application writer can do memory operations that will be translated to the file system actions (read and write). </p></li>
  <li><p>Simple user-space file system.
  => This will implement basic required interfaces required from the user space filesystem and internally uses the systems file system to actually store the file. And read and write operations implemented will access the data stored on disc. Read will be staright-read from the file like we have now, but write operation will apply mask and write to the file system. </p></li>
  </ol>
  
  <p>Advantages: 
   => Can transparently support all the memory operations and emulate flash-like  behaviour behind the scene. </p>
  
  <p>Disadvantage: 
   => It requires external frameworks that need to be used which will be much bigger than the code that we write. 
  (I need to check if they are free frameworks or not, I am not sure yet, will check and comeback if they are not free)</p>
  
  <p>It might be an overkill to implement a user-space filesystem just to have transparent flash-like write characteristic, but if doing it without affecting application writer’s code is more important, then this looks like one of the possibility. 
  Please let me know of your view on this. Thank you.</p>
  
  <p>Thank you,</p>
  
  <p>Microkernel</p>