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 <[EMAIL PROTECTED]>
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
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
