Code modularity

Nicolas Williams Nicolas.Williams at
Tue Nov 10 12:05:33 EST 2009

On Tue, Nov 10, 2009 at 11:53:18AM -0500, Greg Hudson wrote:
> On Wed, 2009-10-28 at 11:33 -0400, Zhanna Tsitkova wrote:
> > This is the initial write-up for the Code Modularity proj.
> This didn't get any comments, which may mean that people didn't
> understand it.  I'll try to rephrase the proposal in a different style.

I hadn't seen it.  The proposal is perfectly comprehensible.

One concern: code changes, so will there be a commitment to
re-modularizing as changes are made?  Will re-modularization be a
checklist item for commiting code?  See below.

> The payoff of this plan, as I understand it, is that every subset of API
> groups will correspond to a subset of the source files within the
> library.  For example, doing GSSAPI NFS in the kernel typically requires
> the APIs to import a security context and wrap/unwrap messages with it,
> but not the APIs to establish a context.  Currently, slicing up the
> GSSAPI and krb5 modules to support that subset requires some pretty
> major #ifdef surgery, but after this code modularity work, the surgery
> would be limited to the build system--in theory, anyway.

To be fair, folks did this at Sun _long_ ago, and it wasn't that big a
deal, by the looks of it, because there was a fair bit of modularity in
MIT krb5 to begin with.  Also, I don't think #ifdefs will go away
entirely because some of them are needed in function bodies and don't
cover the entire function bodies.

If the kernel/user-land GSS split is your goal, then you might just have
an easier time making changes to match the ones in Solaris.

> One possible concern is that functions might need to move around
> frequently because of external factors.  For example, if we add a new
> API which uses some existing internal helper functions, a set of helpers
> which previously lived together might need to be split apart (because
> some of them are used by the new API and others aren't).  Such frequent
> code movement could make it more difficult to look at the history of a
> function's implementation.

Indeed.  Which then argues for a strict
one-non-static-function-per-file, or even one-function-per-file.

IMO occasional re-modularization is a good thing, but constantly doing
it is a pain, both because of history issues, and because it creates
more merge pain for vendors that have not yet gotten to the point where
they can do code drops.


More information about the krbdev mailing list