Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Dec 1995 09:59:02 -0800 (PST)
From:      Bill Paul <wpaul>
To:        CVS-committers, cvs-include
Subject:   cvs commit: src/include/rpcsvc yp.x
Message-ID:  <199512081759.JAA24590@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
wpaul       95/12/08 09:58:56

  Modified:    include/rpcsvc  yp.x
  Log:
  "What? He's modifying the NIS protocol definition!?"
  
  No, not really. There are just a couple of long-standing bogosities here
  that I feel compelled to fix. :)
  
  There are two small changes here:
  
  1) yp.x actually contains _three_ protocol definitions: YPPROG (standard
     NIS client/server procedures), YPPUSH_XFRRESPPROG (callback handler
     for the YPPROC_XFR service, aka ypxfr/yppush) and YPBINDPROG (for ypbind,
     ypset & friends). The problem is that when you run yp.x through rpcgen(1),
     it generates client and server stubs with hooks for all three services.
     This makes it impossible to actually use the rpcgen-erated code in a
     program that only deals with _one_ of these services (ypserv, ypbind,
     etc...) without manually removing the unneeded stubs (either by hand
     editing or by committing unspeakable horrors with sed). This defeats
     the whole purpose of using rpcgen and is generally annoying.
  
     What I've done is to insert a few #ifndefs and #endifs to allow a
     programmer to selectively blot out those functions that aren't needed
     for a particular program. For instance, if you do 'rpcgen -DYPSERV_ONLY',
     you'll get only the necessary client/server stubs to implement the
     standard yp client and server functions. If you do 'rpcgen -DYPBIND_ONLY',
     you get only what you need for ypbind. If you don't #define anything,
     you get the whole mess, just like before, so existing programs won't
     notice the difference. (Note that the -D flag is not supported by our
     existing crufty version of rpcgen, but I intend to update it soon.)
  
  2) The definition for the ypresp_key_val structure is actually incorrect
     with respect to reality: the key and val members are specified in the
     wrong order. It should be val/key rather than key/val. For whatever
     the reason, Sun's actual NIS implementation contradicts the protocol
     definition in this case. Again, accounting for this bogosity here is
     cleaner and easier than mangling the output from rpcgen.
  
  Revision  Changes    Path
  1.2       +12 -7     src/include/rpcsvc/yp.x



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512081759.JAA24590>