RFC: passdb redesign

[John E. Malmberg]

"Gerald Carter" <gcarter at valinux.company> wrote:

> Tim Potter wrote:
> >
> > > I'm trying to get away from the current use of function
> > > pointers.  They get rath ercomplicated to follow in the code.
> > > I have a few ideas that I just haven't finished fleshing out
> > > yet.  Will try to summarize thoswe next week.
> >
> > Aren't function pointers the only way to access the functions in
> > a loadable module loaded with dlopen()?
>
> Nope.  Not by my tests.  The entire namespace from the
> shared library is available.  Just call the function
> directly.  At least on Linux is seems to work like this.
> Haven't tried other platforms yet.

With dynamically loaded libraries on OpenVMS, I have to use a dlsym() call
to move a symbol's address into a variable before I can call it or access
it.

This may be related to that all global symbols must be resolved inside of a
shared image on OpenVMS at the time it is linked.

The implementation of SAMBA 2.0.6 for OpenVMS that I did was able to put the
passdb library into a shared image, as I was to almost all of the libraries
that are used in more than one module.

The only library I was not able to move in to a shared image was "locking".

> > It is a bit of a hassle trying to put breakpoints
> > and/or trace through code by hand though.

I guess the variable is what you would call a function pointer.  Setting
breakpoints before the module is loaded is not possible, but stepping into
the code is not usually a problem.


I do not know how feasable it is for UNIX, but on OpenVMS, I can decide what
specific shared image I want to use at program invocation time.  As long as
the transfer vectors and public symbols are in the same locations.

This is a feature of how "statically" linked shared images work.  An OpenVMS
logical name points to the path of the shared image to be loaded.  An
OpenVMS logical name is sort of like an environment variable that acts like
a symbolic link.

-John
wb8tyw at qsl.network