[rrd-developers] [PATCH + RFC] Cleanup the symbols exported by librrd.

[Tobias Oetiker]

Hi Sebasian,


> I would really like to see this patch in the upcoming 1.3 release, so
> further feedback would be very appreciated. So far, I did not do a lot
> of testing but I'm going to recompile all reverse dependencies of
> rrdtool (i.e. packages which build-depend on rrdtool) which can
> currently be found in Debian unstable and report back after that.
> However, I'm not going to be able to do much functional testing, so
> that's up to you - the users of those packages! ;-)

cool stuff, adding the patch now ... another rc release will be out
in a few minutes ...  I don't think there is much chance for
breakage, especially since the changes are pretty innocent ...

>  * Currently, librrd and librrd_th export the same set of symbols (e.g.
>    both libraries export the thread-unsafe rrd_fetch() as well as the
>    thread-safe rrd_fetch_r()). Is this intended? If not, I guess this
>    should be changed before 1.3 as well as that would else require
>    another SONAME bump.

well I guess we will have to do that at some point ... at the
moment I don't yet see what a good solution is ...

>  * I did not include rrd_open(), rrd_close(), rrd_write() and similar
>    functions in the public interface so far as they look like pretty
>    low-level functions which usually are not needed outside of rrdtool.
>    OTOH, it does not look like including those functions as well would
>    hurt anybody. Any comments on that?

well I would keep them private, since the innards of an rrd file
are pretty delicate so it is best others don't mess around ...

>    (NB: I've removed LockRRD() from rrd.h as imho that function only
>    makes sense if rrd_open(), etc. are available as well.)
>
>  * I don't really see what librrdupd is used for. As it gets linked into
>    librrd statically, the resulting object file should not be any
>    different if linked against librrdupd or each single object file.
>    What was the motivation behind introducing that library?

the idea is to have a limited library to link against when
producing rrdupdate as this should be static and fast to start for
applications where they run the update binary for every update and
would rather not like ld all the unnecessary libraries ...

> This patch is meant to be a first step in cleaning up up the librrd
> interface. The next step would be to declare private functions as static
> to enforce that they are not meant to be exported on a level defined in
> the C standard. I'm pretty sure there are a couple of private functions
> which can hardly be declared static - in that case one might think about
> adding those functions to the public interface or implement other means
> to not export the respective symbols.

since I am committed todo the 1.3.0 release the 11th, I think we
we can have a go at the whole static switchover in the 1.4 development
trunk.

thanks again for the great work!
tobi

>
> TIA for feedback and comments!
>
> Cheers,
> Sebastian
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten
http://it.oetiker.ch tobi at oetiker.ch ++41 62 213 9902