[OpenAFS] jafs et al

[Marcus Watts]

Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> To: Marcus Watts <mdw@umich.edu>, openafs-info@openafs.org
> cc: Jeffrey Hutzelman <jhutz@cmu.edu>
> Subject: Re: [OpenAFS] jafs et al 
> 
> On Tuesday, March 13, 2007 08:07:42 PM -0500 Marcus Watts <mdw@umich.edu> 
> wrote:
> 
> > 	user vs kernel mode vs. "user kernel" mode
> 
> Actually, we don't really have this dimension.  No libraries are built for 
> kernel-mode code; any code the kernel module requires from the rest of the 
> tree is built separately and linked directly into the kernel module.  The 
> situation is similar for libuafs, though the other dimensions certainly 
> exist for that library as a whole.
> 
> Personally, I'd like to see a consistent set of libraries available in all 
> six forms (lwp/pthread x shared/pic/nonpic).  However, note that for many 
> of our libraries, building pthread versions is more complex than just 
> changing a few compiler switches -- there is still a lot of code in AFS 
> which assumes that context switches can only happen at very specific points.
> 
> -- Jeff
> 

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.  Both Solaris & Linux appear to be
wrestling with the implications of identifying which kernel mode
environment features to support, in decidedly different ways.
While in Unix kernel modules usually their own idiosyncratic toolset,
in MicroSoft, they're "just dll's".  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.

I suppose though, it would be more fair to consider kernel mode as another
sort of threading option rather than its own separate thing.  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.

Yup, non-preemptive code won't work well with pthreads.  Or for that
matter with fine-grained kernel locks on modern SMP.  More nits
along this line include the server side of ubik (globals), and
libvolser (trusted code runs on "the client".)  Oh, and kdump...

				-Marcus