[OpenAFS-devel] Solaris afs.rc file damage

[Jeffrey Hutzelman]

On Thursday, April 19, 2007 03:50:34 PM -0400 Dean Anderson <dean@av8.com> 
wrote:

> Really? What did we do before there were dynamic modules?  I recall
> having to relink the kernel with vendor-provided objects back in the old
> days.  I suppose dynamic loading has become like cellphones and
> blackberrys: No one remembers what we did before or how we survived
> without them.  Their absence is now cause for panic. (pun intended ;-)

Ugh; that was awful.  But no, some of us worked on that code and remember 
exactly what we did before operating systems supported run-time loading of 
kernel extensions - we did it anyway. :-)

For some reason this was left out of IBM's original OpenAFS release, but 
Transarc AFS included a tool called 'dkload' which used a truly excellent 
hack to dynamically load the AFS kernel module on platforms that did not 
support dynamic kernel modules, back in the days when that was pretty much 
every platform.

This worked by doing the load in two stages.  First, dkload would read the 
kalloc helper module directly into its own user-mode address space, fix it 
up to run at its locations, and then patch the kernel system call table so 
that AFS's entry would point at the code which was now resident in the 
dkload process.  Having done that, it would make system call to the kalloc 
module, which would use the kernel's memory allocator to allocate enough 
kernel-mode memory to hold the real AFS module.  Then the process is 
repeated, more or less, fixing up relocations in the real module and 
loading it into the allocated memory.  Of course, the system call table 
would be repaired before dkload exited.


> I think you missed the future tense in my statement above.  What happens
> when Linux, etc removes dynamic system calls?  Then you will be able to
> dynamically load drivers, but you will have to statically link system
> calls

You are apparently confused, and do not actually understand the direction 
in which things are going.  The issue is mostly not about linking; it's 
about the directions in which people are willing to support extensibility. 
Neither Linux nor Solaris really supports the concept of statically linking 
external modules into the kernel.  In Linux, it is possible for some parts 
of the kernel to either be built in or built as modules, but the same 
registration mechanisms are used in either case.  The Linux folks don't 
support dynamic registration of system call handlers, for various reasons; 
compiling AFS into the kernel wouldn't change that, and merging AFS into 
the mainstream kernel distributions is not an option for multiple reasons.


It occurs to me that early in this thread you said you had talked to 
someone in Sun and they said some group "wasn't committed" to dynamic 
system calls.  First of all, please be careful when talking to people at 
Sun to not even give the impression you might be asking for something on 
OpenAFS's behalf.  We have contacts within Sun, and AFS developers who know 
something about how their process works, and we are working on gathering 
requirements and getting what we need from Sun, via that process.  It would 
be sad if we went to them with a detailed, well-reasoned request and were 
blown off because someone heard about you looking for information and 
misinterpreted it as a request for something unreasonable.

Second, I very much suspect you misinterpreted what was said. 
Specifically, I suspect that was was actually said was not that "some 
group" was not committed to dynamically-loaded system calls, but that the 
interface for registering system calls was "not Committed".  That phrase 
has a specific meaning within Sun, and it does _not_ mean that the 
interface in question is going away soon.  What it _does_ mean is that this 
interface should be (and is) on the list of interfaces for which we'll want 
to set up a contract (another word with special meaning within Sun).

Really, while changing syscall numbers every few Solaris versions is a 
pain, I've seen worse issues, and we do _not_ need to spend time worrying 
that Sun is about to discontinue the system-call registration interface.

-- Jeff