Jak zapisać wartość bezpośrednio do pamięci nieulotnej (na dysk)?

Witam,

Opiszę mój nietypowy problem a właściwie to koncepcję. Otóż gdy piszę program na mikrokontroler i z jakichś względów chcę zachować wartość zmiennej nawet po resecie urządzenia to zapisuję ją do pamięci EEPROM, w którą to każdy uC jest wyposażony. Natomiast teraz chcę coś podobnego zrobić w programie na PC. Używam do tego obecnie jakiegoś pliku tekstowego, który sobie otwieram i tam zapisuję potrzebne wartości. Ciekawi mnie jednak czy mogę zrobić coś podobnego jak w uC, czyli zapisać wartość bezpośrednio do pamięci nieulotnej (na dysk) pod wskazany adres?

Ktoś robił coś takiego? Działam na Ubuntu 16.04, program napisany w C++.

tak czy inaczej się da, ale posiadasz system operacyjny, i on izoluje od sprzętu. To jest główna różnica do mikrokontrolera nie posiadającego systemu.
Są różnego rodzaju formy pośrednie, pliki/partycje surowe (raw file). Silniki baz danych niekiedy tego używaj/używały.

Czyli odpowiedź jest "z wieloma zastrzeżeniami tak", ale prawdziwa jest też odpowiedź "nie", tzn nie będzie to identycznie (nie spodziewam się grzebania w rejestrach sprzętu)

Tak się spodziewałem, że odpowiedź będzie brzmiała: i tak i nie

Zdaję sobie sprawę, że nie mam bezpośredniego dostępu do sprzętu, ale myślałem że jest jakaś metoda zapisu danych bezpośrednio do pamięci pod konkretny adres. Czyli rozumiem, że jest to gra niewarta świeczki i lepiej pozostać przy zapisie do pliku.

Zdecydowanie lepiej. Jeśli wymyślisz sobie jakąkolwiek lokalizację na dysku, to nigdy nie będziesz w stanie zagwarantować dwóch rzeczy (już zakładam, że kwestie uprawnień do zapisu/odczytu nie są problemem):

- nie będziesz w stanie zagwarantować, że nie nadpisujesz żadnych istotnych danych w danym momencie (chociaż możesz odpowiednimi narzędziami próbować sprawdzić zajętość odpowiedniego fragmentu dysku)
- ale przede wszystkim -nie będziesz w stanie zagwarantować, że żaden inny zapis nie wyląduje w tamtym miejscu. Dla systemu plików będzie to przecież wolne miejsce, więc sterownik obsługujący system plików nie będzie widział żadnych przeciwwskazań, aby tam niczego nie zapisywać.

Oczywiście, możesz skrócić partycję i sobie na końcu dysku, gdzie już nie będzie sięgać partycja takie akcje robić... Tylko po co utrudniać sobie łatwe rzeczy?

No taki już jestem, że lubię podrążyć Myślałem, że jest prosty sposób na to co chcę zrobić, ale widzę że jednak nie. No to pozostaje zapis do pliku.

Do rozważań bym dodał. Nie tylko nie mamy zagwarantowanego punktu w przestrzeni dyskowej (pewnie by można zarezerwować), ale nie bardzo możemy zawłaszczyć sterownik. W czasie, gdy my zapisujemy tej jeden magiczny bajt, kontroler realizuje jeszcze inne operacje.
Pewnie dlatego dostęp 'raw' jednak jakoś zachodzi przez system operacyjny, który spełnia zredukowaną rolę, ale jest. Moja wiedza o 'raw' jest na poziomie kibica.

Takim ciekawym, a bardziej powszchnym przykładem jest pamięć dzielona (RAM). Również nie zachodzi zupełne ignorowanie S.O.

Da się zrobić na dwa sposoby:
a) Wydzielenie pewnego obszaru dysku poza partycję (jako nieużywany obszar). Obszar ten ma zawsze stały adres początku u końca. Wówczas możesz pisać do tej przestrzeni co tylko chcesz i kiedy chcesz (może zależeć od OS).
- wady: większy nakład pracy niż przy rozwiązaniu na plikach
- zalety: niewrażliwość na problemy spójności systemu plików

b) zapis danych do pliku w istniejącym systemie plików
- wady: w przypadku utraty spójności/uszkodzenia fs możliwa utrata danych
- zalety: prostota implementacji, przenoszalność rozwiązania

Ważne kwestie:
- flushowanie buforów dysku. Koniecznie po zapisie pliku należy wykonać flush na pliku aby mieć pewność, że dane znajdujące się w buforach systemu/dysku zostały przeniesione fizycznie na nośnik.

- mechanizm Copy-On-Write. Edytując ten sam plik ryzykujesz uszkodzeniem danych podczas chwilowego zaniku prądu etc. Przed modyfikacją istniejącego pliku należy najpierw wykonać jego kopię, następnie nałożyć na nią zmiany, wykonać flush, move kopii na docelowy plik.

- odporność na dostęp z wielu wątków: mutexy, exclusive locki dla wątków, file locki dla procesów. Takie podejście zapewni, że niemożliwy będzie jednoczesny odczyt i zapis pliku co zabezpieczy przed chwilową utratą spójności danych.

Polecam rozwiązanie b), w szczególności:
- założenie partycji specjalnie dla plików parametrów
- montowanie partycji domyślnie jako RO
- re-montowanie partycji na RW na czas zmiany w pliku. Po dokonaniu zmiany wracamy do RO.
- kwestie synchornizacji dostępu do pliku, flushowania etc można wyeliminować korzystając np z sqlite. Z poziomu cmdline łatwo wywołać proste SQL w obrębie transakcji.