12 Oct
2018
12 Oct
'18
3:28 p.m.
Hi Rafael,
On Fri, Oct 12, 2018 at 10:00:14AM -0300, Rafael Diniz wrote:
Hi all,
yes, that is what I'm saying and why we have been brainstorming about
this approach at all. That's what I've been talking about in the first
paragraph you quoted, and what we've been pondering to do.
The second paragraph is about embedded or external databases which we
don't want to use, and whihc are not useful within the current osmocom
architecture.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
I've done some research on the web at that
time (maybe 2 years ago) but
unfortunately couldn't find any library/tool/infrastructure for having
persistent data in SysV SHM, and also no other FOSS programs that did
so. Maybe I didn't look closely enough? To me, it seems like the most
obvious solution to persist state across crashes/restarts of C programs
on unix-type systems.
We explicitly don't want to use some kind of database system, as the VLR
data needs to be accessed all over the code
directly/synchronously/non-blockingly. We cannot wait for it to be
retrieved from somewhere. That's what is done with HLR data.
May be I'm missing something, but SysV SHM provides system calls you
certainly can create a shared memory segment that is persistent.