Changes to the storage API

Russ Allbery rra at
Sat Feb 24 08:37:22 UTC 2001

I'm looking at cleaning up <storage.h> and moving it to <inn/storage.h>
and I think I want to clean up a bunch of different stuff while we're at
it (particularly since INN 2.4.0 already has a goodly number of sweeping
mechanical changes for more maintainable code).  One thing I'd like to do
is clean up the defined constants so that they begin with SM_ to avoid
accidental conflicts and to make the storage API live in its own namespace
better; I'll send more details on that proposal later.

The other change I want to make is a change in the actual function calls.
Right now, for any client of the storage API that wants to open it for
read/write and plans to do a bunch of retrievals, there's this long setup
code that looks something like:

    /* Initialize the storage subsystem. */
    flag = true;
    if (!SMsetup(SM_RDWR, &flag) || !SMsetup(SM_PREOPEN, &flag))
        die("SERVER cant set up storage manager");
    if (!SMinit())
        die("SERVER cant initalize storage manager: %s", SMerrorstr);

in order to set SM_RDWR and SM_PREOPEN, where flag is a bool variable.

I recognize the intention to provide a nice, general interface to SMsetup
so that arbitrary data can be passed into it... but I think that interface
design has proven in practice to be overkill, and in any case isn't a good
way of setting those particular values.  For one, there's the (possibly
important!) worry of whether you're passing in an int * or a bool *, and
for another it's a bunch of separate calls and separate error checks and
it's just a pain to write.

I'd like to change SM_RDWR and SM_PREOPEN to be 0x1 and 0x2 and then allow
SMinit to take a flags argument so that instead you'd write:


to do the same thing (and add SM_RDONLY as 0x0 for completeness).  I'd
also like to eliminate the SMsetup interface for right now.  We can always
reintroduce it if we end up with some information we want to pass to the
storage manager that requires that level of generality, but we haven't
come up with any so far and I can't think of any coming in the near


Russ Allbery (rra at             <>

More information about the inn-workers mailing list