(ITS#6166) Overlay/backend restructuring

[h.b.furuseth@usit.uio.no]

Full_Name: Hallvard B Furuseth
Version: RE25/RE30
OS: 
URL: 
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard


Some wishes/loose thoughts about overlay/backend code:

* Remove backends internally, making them like overlays? (RE30)
* Reduce copying of overlay data -op->o_bd->bd_info (RE25?)
* Lose slap_overinst, move its members into BackendInfo.

<hbf> Could we reduce complexity if there internally were no
      (programmable) backends, only overlays?  Backends would be thinly
      disguised overlays.  Maybe over a single fixed "core overlay"
      which intercepts all calls, or the opposite - a fixed empty
      backend.
<hbf> .what do overlays cost compared to backends?  Must reduce copying,
      but that seems already to be the plan.  And slapd must repair some
      data structures which overlays are not required to clean up - must
      that stay?  Am I talking sense at all?
<hyc> eh, not sure what you're really talking about. turn all backends
      into overlays, to keep the API completely uniform?
<hbf> yes.  and return values the same way - SLAP_CB_CONTINUE when they
      don't know what to do, for example.
<hbf> there seems to be code snippets around doing similar things for
      backends and overlays, and they mostly share the same data
      structure.  so i wondered if the backend stuff could simply go
      away.
<hyc> so we'd still need special cases in the frontend to handle
      SLAP_CB_CONTINUE falling out at the end
<hyc> ideally, sure.
<hyc> that seems like more of a 3.0 move than a 2.5
<hbf> yes, i suppose so

<hbf> and it depends on overlays being as fast as backends
<hyc> fast at what?
<hyc> there's no measurable overhead for overlays on top of backends
<hbf> handling a request.  slapd does all this copying of overlay
      structures that I haven't even tried to figure out, I assume that
      costs time compared to a backend.
<hyc> well, a lot of that copying can go away if we just rationalize the
      on_info stuff
<hyc> I already mentioned that on -devel a while back
<hyc> op->o_bd->bd_info
<hyc> if we referenced those pointers from op instead of op->o_bd we'd
      need no copying at all
<hyc> but i think that would require changes to a lot of existing
      backend code.
<hyc> the copying approach was taken to allow overlays to be slotted in
      without modifying any backend code
<hbf> oh well, we've more pressing problems in that case
<hyc> actually come to think of it most backends don't care as it is. at
      this point it's the overlays and bconfig that would need to be
      changed
<hyc> I guess we should have made that change sooner rather than later,
      as now the number of overlays is quite large :P
<hyc> hindsight, oh well.
<hyc> I wouldn't be opposed to attempting that change for 2.5. sooner is
      obviously better now.

<hbf> related loose thought: overlays could lose all those
      (slap_overinst *)op->o_bd->bd_info casts if the slap_overinst
      members were inserted in BackendInfo and slap_overinst became an
      obsolete wrapper about just BackendInfo.  Costs ~24 bytes/backend.
<hyc> ok
<hyc> that sounds smart