[ On Wednesday, August 28, 2002 at 17:13:43 (-0400), Jim Wise wrote: ]
> Subject: Re: PAM
>
> This is right on, though I'd like to make one more point in favor of
> loadable modules:  by supporting loadable modules, we make it possible
> for nsswitch or authentication to be based on software which we don't
> distribute with the base system.

I think that's B.S. & F.U.D. or whatever.

You have that "feature" today, even in a static-only system.

The primary product that is NetBSD is a collection of source code.
Anyone with generic systems programming skill can add anything to it at
any time (and link it any way they please, for that matter).  Good
systems programmers can make modules that almost anyone could use to do
such integration at any time.

> Suppose I want to add the capability to authenticate users against a
> PostgreSQL database (a perfectly reasonable thing to want to do).

I've seen that done in a system with at least some static binaries too.
It would probably have been easier to program if done in the nsswitch
framework, but either way it works today and it was added to
static-linked programs with almost no additional effort required (beyond
initial development and testing of the hooks in libc).  "make build" (or
in this specific case it was "make world") and stand well back.  Trivial
even.

>  This
> would involve a loadable authentication module which would be linked
> against libpq.  If we want to support this in Greg's
> everything-is-static world, we would need to bundle libpq with the base
> system, or reimplement it completely -- and track changes in
> PostgreSQL's protocol over time, and make sure our implementation stays
> compatible with theirs.

Huh?  Just use the supplied pgsql libraries for goodness sake!  They
track their own protocol changes.  Rebuild, test, reinstall, as
necessary.  It's even more trivial if NetBSD contains optional #ifdef'ed
code to call the publicly documented pgsql API!  You don't bundle an
option like that in its entirety!

> Now, if you think that was unpleasant to do with a statically-linked
> world, here comes the fun part:  what if, instead of PostgreSQL, I want
> to use Sybase?  Guess what -- now we _can't_ ship the libraries needed
> to link such a module with the system, and so, without the ability to
> add third-party auth modules dynamically, we're out of luck.

That's not true.  For any decent database back-end there's going to be a
library (either object code, or even in some cases source) that any
systems programmer can trivially link statically into any program,
including all the programs in the entire OS.  You don't even have to be
a particularly skilled systems programmer to make it work.  NetBSD is
open source.  Literally any sufficiently skilled programmer, can add to
or modify any part of it.  NetBSD need not ship with any libraries in
any form for any add-on stuff.

There may still be some platform dependencies encountered in using
binary-only libraries intended for a foreign platform due to object
format differences and possibly also due to unresolved references that
may not be available or which may have different ABIs, though in some
way these issues may be less of a problem than even the issues faced by
running a foreign binary program (unless that binary is static-only and
is for one of the already well supported binary emulations).

Perhaps only a completely separate (static-linked if non-native) binary
supplied by the database vendor, with some well documented IPC spec for
communicating with applications, would completely avoid all issues of
distributing object code and would then only require a S.M.O.P. to
integrate using the documented IPC.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>