[OpenAFS-devel] Re: [OpenAFS] jafs et al

[Jeffrey Hutzelman]

Moving this to -devel, where it belongs, from -info, where it doesn't.


On Tuesday, March 13, 2007 09:03:42 PM -0500 Marcus Watts <mdw@umich.edu> 
wrote:


> Kernel mode code isn't part of a general purpose programming
> environment, but rather is part of "just another application".  But,
> this distinction could get less meaningful with time - with kerberos 5
> kernel support we're moving into a world where library style api
> support makes more & more sense.

It's plausible that the distinction will blur, but I don't expect it soon, 
and really, we're not in that business.  As it stands now, a kernel is 
generally a single address space and kernel modules have a single symbol 
namespace to play with; there is no concept of different modules being 
linked against different libraries.  Since _our_ kernel-mode code uses 
almost none of our user-mode libraries, and none of those libraries contain 
things that are exported to other kernel code, I think it's best, for now, 
to treat libafs as the special beast that it is, and not worry about 
figuring out how to build "kernel-mode" libraries that will never be used.

>  Both Solaris & Linux appear to be
> wrestling with the implications of identifying which kernel mode
> environment features to support, in decidedly different ways.

Actually, not all that different.  Linux's model is that the kernel is a 
single system with no outside interfaces other than system calls, and that 
it is fine to change any interface at any time as long as you update the 
rest of the tree.  As long as the Linux people have this mindset, there 
will never be anything resembling libraries that are shared by out-of-tree 
modules, and even the library-like things within the kernel will remain 
mostly unavailable to us.

Solaris's model is a little different, in that the kernel actually consists 
of multiple components with well-defined interfaces between them, those 
interfaces have well-defined stability states, and changing them requires 
an ARC case and real review, possibly requiring input and/or buy-in from 
the users of the interface.  However, all of that process is _internal_, 
from the outside there are few committed interfaces between loadable 
modules and the kernel, and basically none between the kernel and userland 
(Solaris has good backward compatibility, but only for programs that are 
dynamically linked -- it is the libc API that is remarkably stable, while 
the user/kernel interface can change significantly between versions).



> While in Unix kernel modules usually their own idiosyncratic toolset,
> in MicroSoft, they're "just dll's".

nit: "Microsoft" is spelled with a lowercase "s"
nit2: "Microsoft" is a company; "Windows" is a product

But more to the point, that is something of a misconception.  Windows 
drivers are dynamically-loaded objects, just as on most UNIXes.  They 
happen to have basically the same file format as user-mode dynamic 
libraries, again, just as on most UNIXes.  However, they are _also_ like 
most UNIXes in that these modules in an environment that is totally unlike 
userland, including the lack of standard library facilities.  You cannot 
just link a driver against a random user-mode DLL, any more than you can on 
UNIX.


> Even though kernel mode "should"
> be part of a different programming environment, I've found it useful
> to link test applications against selected bits of code built for
> "the kernel" to verify proper operation.

Sure, but we're talking about libraries that we make available outside AFS, 
not how about how our unit tests work (or would, if we had them).

> I suppose though, it would be more fair to consider kernel mode as another
> sort of threading option rather than its own separate thing.

I think not.  Kernel-mode is not a "threading option"; it's a completely 
different programming environment, which is why we treat it that way.

> That leaves
> libuafs as a much more anomalous case.  Code-wise that's a fair call.
> But libuafs still has special include file and library organization,
> so I'm not sure we want to argue this isn't a special case.

Of course it's a special case.  In one sense, it's the same special case as 
the kernel - it doesn't use our normal user-mode libraries, and there's 
little point in designing them as if it did.  However, in another sense, 
it's just _like_ our other user-mode libraries, in that people may want to 
use it in scenarios that require shared, archive-pic, or non-pic libraries, 
and they may want to use it in LWP or pthread applications.  In practice, 
it's probably reasonable to pick exactly one combination (presumably 
shared/pthread) for libuafs.

> libvolser (trusted code runs on "the client".)

That's a completely different issue, though still one worth solving.

-- Jeff