On Thursday, April 19, 2007 03:50:34 PM -0400 Dean Anderson <[EMAIL PROTECTED]> 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
