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

[Marcus Watts]

Jeffrey Hutzelman <jhutz@cmu.edu> had responded:
> > Kernel mode code isn't part of a general purpose programming
...
> 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 
...

I think we're arguing semantics here.  OpenAFS kernel extensions
are assembled in a directory called "libafs".  I don't think we
need to get any more specific than that regarding whether it's
a library.  The interesting question is what goes into the source
& build environments for source that's shared between kernel & other
runtime environments.

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

I was trying to be good.  I didn't say "m$" or make any
reference to arboreal edentata.

> 
> 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.

A driver?  Probably not.  A more generic DLL -- maybe?  There is a
"native" Windows NT API that is about 98% shared between kernel & user
modes.  win32 exists as a layer on top of the native api and is only
available to usermode applications.  The native api is not like stdio
or unix syscalls, and I don't know if the common api extends to a
common abi or if there are minor naming, structure differences, or even
different calling conventions.  I mentioned this not because I thought
we should be in the business of supporting dlls that run in both
environments, but because in windows "kernel" vs. "user" mode dlls
share completely the same file format and load technology, they are not
different in the sense that kernel extensions vs. usermode shared
objects or libraries are in most Unix environments.

> > 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.

What irritates me about libuafs is that it builds each .o in up to
3 different ways: uafs, juafs, and webobj - and as far as I can
tell, in most if not all cases they're built with exactly
the same compile options and should be functionally identical.
The objects are different than those in other libraries - but
I'm not sure they need to be as different as they are.

...

			-Marcus