Jeffrey Hutzelman <[EMAIL PROTECTED]> writes: > To: Marcus Watts <[EMAIL PROTECTED]>, openafs-info@openafs.org > cc: Jeffrey Hutzelman <[EMAIL PROTECTED]> > Subject: Re: [OpenAFS] jafs et al > > On Tuesday, March 13, 2007 08:07:42 PM -0500 Marcus Watts <[EMAIL PROTECTED]> > 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 _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info