Date: Sat, 28 Jun 2003 11:49:59 +0000 From: Bosko Milekic <bmilekic@technokratis.com> To: Oleg Sharoiko <os@rsu.ru> Cc: "Michael A. Bushkov" <bushman@rsu.ru> Subject: Re: dynamically linked root and nscd Message-ID: <20030628114959.GA15104@technokratis.com> In-Reply-To: <20030628092435.B547@brain.cc.rsu.ru> References: <20030627115950.GA8424@technokratis.com> <Pine.NEB.3.96L.1030627120119.73366G-100000@fledge.watson.org> <20030627121646.GA8678@technokratis.com> <20030628092435.B547@brain.cc.rsu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 28, 2003 at 10:25:03AM +0400, Oleg Sharoiko wrote: > > On Fri, 27 Jun 2003, Bosko Milekic wrote: > > BM> So, to the guys from RSU: why is a dynamically-linked-root important > BM> for the daemon dispatcher/cache engine idea? > > We (guys from RSU) have to have a clear understanding of the road FreeBSD's > NSS will be developed. Linux/Solaris seem to implement 'in process' model of > NSS. MacOS X seem to have 'IPC' model (correct me if I'm wrong). > > 'In process' model has the benefit of being (semi-)compatible with existing > NSS modules (at least it can be implemented this way). This means that > third-party open source modules can be used in FreeBSD (ex. padl's nss_ldap). > But 'in process' model doesn't support static binaries. > > 'IPC' model will work fine with static binaries, but it's very different from > 'in process' model. With 'ICP' model FreeBSD will need it's own set of NSS > modules. > > If I understood correctly there is some interest in combination of both of > these model, correct? Do we really need both of this models? With dynamicly > linked root we have a working 'in process' NSS and only 'clean caching' daemon > is required. We are ready to work hard on a project that is really needed but > we can not waste our time on code that will be discarded (as it happened with > our IPC implementation of NSS). > > Our final question is: should we develop a 'caching only' daemon or a daemon > which will also dispatch requests to NSS agents? > > I hope my English is understandable. If not - please let me know and I'll try > to re-express my thoughts. > > -- > Oleg Sharoiko. > Software and Network Engineer > Computer Center of Rostov State University. This is what I suspected your response would be and it is why I wanted to make sure that things were well understood. I can't speak for everyone, but I'm a big fan of what you call the IPC model. Here is a little bit about why. 1) It works for both statically and dynamically linked binaries. 2) You can introduce a caching layer between the libc dispatch code and the daemon dispatch code. I think that the daemon should be what dispatches the nss requests. If it's going to do caching, it needs to know about what data they return anyway and going back and forth between the libc code and the daemon over a socket is wasteful; so you may as well go "up to" the daemon _once_ when the call is made, and then "back down" to the libc code _once_, once the data is available. Anything else in-between should not warrant back-and-forth activity between the libc code and the daemon. 3) You can maintain a single connection instance to the backend as specified by an agent module, instead of having to constantly re-establish connection. 4) You can cache the data read from the config files. I know that Jacques Vidrine (who has done the work on nss in FreeBSD) may tend to disagree. In a previous reply to you he mentionned that he thought this model was overkill because: 1) It would require for all consumers in libc to marshall arguments 2) Some NSS modules already have their own daemons and that seems to be the direction they're headed in. For (1), I'm sure it's possible to pass the data down to the daemon opaquely and have the daemon pass it down to the agent module. Unless I misunderstand the problem. For (2), this is a terrible direction. It would be better if they were thought to instead deal with a well-defined interface and all connect using the facility provided by the single running cache+dispatch daemon. There seems to be a growing desire to move to a dynamically linked root, but I really think that if the only reason to do that is to accomodate the libc nsdispatch code, then it's probably the libc nsdispatch code which should change, assuming the 'IPC' model solution doesn't have any shortcomings which I've left out above? Regards, -- Bosko Milekic * bmilekic@technokratis.com * bmilekic@FreeBSD.org TECHNOkRATIS Consulting Services * http://www.technokratis.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030628114959.GA15104>