Code modularity

[Nicolas Williams]

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.

Nico
--