c ++ - Flash Emulation bibliotek - Trapping memory skrive adgang

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg er forpligtet til at skrive et bibliotek (i C ++), som vil efterligne NOR flash lignende adfærd.
(Platform - Windows, Language-C ++)
(Undskyld for et meget langt indlæg, jeg forsøger at forklare, hvad jeg har gjort indtil videre :))


Påkrævet adfærd:


Så det er sådan, det skulle fungere, jeg er forpligtet til at returnere hukommelsesområde, som brugeren vil bruge som flashhukommelse. Han skulle være i stand til at læse eventuelle bytes fra den returnerede hukommelsesbuffer, hvilket ikke er et problem, hovedproblemet kommer i skrivning, fordi skriveadfærden af ​​blink er forskellig, således at du kun kan nulstille en smule, hvis en adresse har indhold (i binær) 10101010 og bruger forsøger at skrive 01011001 til denne adresse, så skal placeringen faktisk indeholde 10101010 & 01011001=00001000 efter skrivning. Jeg er ikke sikker på, hvordan man får det gjort!


Disse er de tilgange, jeg tænker på:


Jeg skal have dataene gemt som en fil internt for at kunne bruge det flere gange og analysere efter flere brug, så jeg er plaaning at bruge en hukommelseskortet fil-IO for at returnere hukommelsen. læsning er ikke et problem, men jeg er ikke sikker på, hvordan man fælder hukommelsen skriver og anvender og maskerer, før man skriver det.


Følgende er nogle af de måder, jeg tænkte på ...


tilgang 1:


Markér den eksponerede peger som readonly, så brugeren kan direkte læse fra hukommelsen, men for skrive kan vi udsætte en grænseflade, som vil være den eneste grænseflade til skrivning i hukommelsen. Siden det er vores grænseflade, kan vi klare kravet om at anvende maskering.


Fordele:


=> Holder implementeringen enkel.


Ulemper:


=> Reducerer anvendeligheden af ​​modulet ved at sætte begrænsninger på brugeren vedrørende skrivning.


Fremgangsmåde 2:


Skriv en klasse, som overbelaster alle mulige hukommelsesadgangsoperatører. Noget sådan her


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


Fordel:
=> Igen holder implementeringen enkel.


Ulempe:
=> Selvom vi kan håndtere de fleste af skrivesagerne, kan vi ikke håndtere disse i situationer som i følgende kodestykke.


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);


Så det kan igen ikke være en komplet løsning, og det kan faktisk forårsage mange problemer med enhver ny kode.


tilgang 3:


Tredje tilgang er at indstille sidebeskyttelse til READ\_ONLY og fange eventuelle skriveforsøg gennem en signalhåndterer (mprotect og sigaction på Linux), men fra nu af kan jeg kun fange skriveopkaldene men endnu ikke kunne få mere information til at fuldføre skriveforespørgslen . Vil undersøge det for at se om det er muligt at fange skriveopkaldene og skrive data efter påføring af maske.
Hvis dette er muligt, kan det være en komplet løsning.


Fordele:


1) Kan håndtere skriveforespørgsler gennemsigtigt uden ændringer til brugeren ved hjælp af emulator.


Dette ser ud til at være perfekt, men jeg kan kun få afbrydelser, der siger, at der var en adgangslovgivning, men jeg ved ikke, hvordan man faktisk får dataene til at blive skrevet og anvender maske, før du skriver det i afbryderhandler! (Men jeg prøvede dette i Linux , har ikke gjort det i Windows)


Tilnærmelse 4:


Har nogle emuleret enhed med hukommelseskortet IO, og eventuelle skrivninger til enhedens hukommelsesområde kommer til min enhedsdriver, som jeg kan gøre, hvad jeg vil.


Dette er bare en tanke, jeg er ikke sikker på, om det kunne gøres overhovedet, og selv om det er gjort, kan det være en overkill for mit krav.


Tilnærmelse 4:


For at understøtte læsning og skrive gennemsigtigt som i tilgang-3, kan vi bruge Linux's FUSE-ramme, der svarer til Windows (fra nu af fik jeg DOKAN http://dokan-dev.net/en/og CBFS http://www.eldos. dk/cbfs/). Ved hjælp af dette kan vi præsentere vores kode som et filsystem til systemet, og alle læsnings- og skriveopkaldene vil blive omledt til vores kode i brugerrummet, hvor vi kan manipulere data uanset hvor vi ønsker.
Så vores kode vil have 2 stykker, [3] [4]



  1. Biblioteket, der udsætter flash\_emulator-klassen til programforfatteren (den vi har nu)
    => Dette åbner flashemuleringsfil i det brugerrumsfilsystem, som vi opretter og gør en memory-mapped file-io og returnerer den kortlagte adresse til brugeren, hvorved programforfatteren kan gøre hukommelsesoperationer, der oversættes til filsystemhandlinger (læs og skriv).

  2. Enkelt brugerrumsfilsystem.
    => Dette vil implementere grundlæggende nødvendige grænseflader, der kræves fra brugerrumsfilsystemet og internt bruger systemfilsystemet til faktisk at gemme filen. Og læse og skrive operationer implementeret vil få adgang til de data, der er gemt på disken. Læses vil være staright-læs fra filen som vi har nu, men skrive operation vil anvende maske og skrive til filsystemet.



Fordele:
 => Kan understøtte alle hukommelsesoperationer gennemsigtigt og efterligne flashlignende adfærd bag scenen.


Ulempe:
 => Det kræver eksterne rammer, der skal bruges, som vil være meget større end den kode, vi skriver.
(Jeg skal kontrollere, om de er gratis rammer eller ej, jeg er ikke sikker endnu, vil tjekke og komme tilbage, hvis de ikke er gratis)


Det kan være en overkill at implementere et filsystem til bruger-rum, bare for at have gennemsigtig flash-lignende skrivekarakteristik, men hvis det gøres uden at påvirke ansøgningen, er forfatterens kode vigtigere, så ser det ud som en af ​​muligheden.
Lad mig vide om dit syn på dette. Tak skal du have.


Tak skal du have,


mikrokernen

Bedste reference