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