The AFS kernel extension has most of the guts of AFS; it's
highly probable that transarc considers most of that proprietary
stuff and would not like the source to be widely available.
Afsd, on the other hand, usually has almost no brains. About all
it does is contain some simple userland startup logic. Once
it's done that (and there's usually very little it does),
it forks off, does special one-time system calls to provide
separate process contexts for the kernel extension, and then
basically ceases to exist for most practical purposes.
These process contexts are more or less the AFS equivalent to
the Unix process 0 and 2, or are sort of like 386bsd "nfsiod" or
sunos "biod". The first 2 afsd's do functions that are required
for every AFS client; the rest of them are a variable number
"background daemons" that can handle various sorts of asynchronous
tasks.
If you run afsd with the "-verbose" switch, you can watch as
it forks these daemons off. It looks like there is:
+1 "rx callback listener".
+2 "afs daemon".
+3, +4, etc. "background daemon".
The exact logic afsd does is very dependent on the underlying
cache manager (basically, it *must* be from the same version of AFS),
and OS dependent. There can be variations; under AIX, recent
versions of afsd create a second kind of "biod" daemon; while
under solaris & linux, there is a separate "rxevent" daemon.
I gather NFS translators also create an "rmtsysd" daemon.
Argueably, it would be "nice" if transarc were to publish
the source to the cache manager, & reserve rights to the server code.
However, they are a commercial concern, and unlike sun, their very
existance depends on being able to sell copies of their software
for money. Sad, but true. It's really very unlikely that they're
going to suddenly revise their marketing strategy and try to
do the same thing BSDI or Cygnus are doing with 386bsd or kerberos,
that is, make a free version available, while planning to make money
off of supporting a "commercial" version of the same. Even if
transarc were "generally" interested in such a strategy (which I
sincerely doubt), they have now invested heavily in DFS (aka AFS 4),
and are not likely to do anything that might have any risk of
upsetting their investment.
That does however raise an interesting possiblity - suppose Transarc,
or really, OSF (the people who are responsible for DCE, the product,
as a whole), were to "publish" source code to a version of the DFS
client side cache manager? They've already published the underlying DCE RPC
mechanism, so there is *some* precedent for them to do this. This
could be a very good thing for transarc, who would be freed to
concentrate on continuing to support and improve fileserver technology
as well as other markets. They will also still have a continued
opportunity to support a stable commercial client version for a few
well-chosen platforms, while less stable "free" versions would
be readily available for a wide range of platforms. It happened
with WWW, why not DFS? In the sense that they're coming up on an
interesting marketing "crunch" as they compete with Novell netware,
Sun (NFS), and Microsoft (SMB), this could be a very interesting
marketing move for them. It would be a bit of a gamble.
However, I don't work for Transarc, I am merely a happy user of their
product, as is nearly everyone reading this list. My ideas are
merely idle personal speculation, and are certainly in no way binding on
Transarc or anyone else. It is definitely Transarc's product,
and they certainly have the right to decide how to market their
product. To get the *real* word on transarc's marketing
direction, you should definitely contact them directly.
-Marcus Watts
UM ITD PD&D Umich Systems Group
