[Date Prev][Date Next]
(ITS#6166) Overlay/backend restructuring
Full_Name: Hallvard B Furuseth
Submission from: (NULL) (220.127.116.11)
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
<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
<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
<hyc> I already mentioned that on -devel a while back
<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
<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
<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> that sounds smart