Re: dynamically linked root and nscd

From: Bosko Milekic (bmilekic_at_technokratis.com)
Date: 06/28/03

  • Next message: Scott Long: "Re: API change for bus_dma" 
    Date: Sat, 28 Jun 2003 11:49:59 +0000
To: Oleg Sharoiko <os@rsu.ru>

    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/
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Scott Long: "Re: API change for bus_dma"

    Relevant Pages