|
|||||||
|
|
|
|||||
|
|
|||||||
HOTSWAPPING
This,as may be imagined,is a very tricky feature to implement.We not just have to deal with the fact that the new kernel may be of a different size than the old one,and all the memory rearranging issues that come with that,but also the fact that the new kernel may,for example,implement a new filesystem,rendering all media that is currently attached unusable!! At the moment,one primary assumption I make is that the kernel is always being UPgraded,that's one thing that'll hold true for the near future.
Here's basically how it works:
Even though some device drivers ship with the kernel,it's assumed when hotswapping that all device drivers currently in the system,whether they came with the kernel or are user-level,are unusable.If the new kernel doesn't bring with it all the drivers needed for the system that's running right now,those devices WILL NOT WORK,the drivers will have to be loaded separately.(Read on....)
The interface to the kernel is the SYSCALL,as implemented in most other OSes.However as I really like the idea of the OS being *extensible*,it's easy enough to implement USER-REPLACEABLE syscalls,ie. the OS keeps a table of which calls have been replaced by the proc. and what their addresses are (which will be inside the proc. that replaced them),and jump there instead,when time comes.From here it's easy to proceed to an architecture where the entire kernel itself is replaceable.Issues to deal with,number one: the system effectively locks while the swap is taking place,any device transactions taking place,non-completion of which would cause a crash MUST BE ALLOWED TO COMPLETE before the swap starts,this is a thorny issue with many devices out there.Now since,as I've already stated,the future of Domainatrix lies NOT in abstraction,but in multiplexing only,this shouldn't be too difficult,ie. instead of the call being writefile("path"); it'll only be sendbytetodrive("byte");.That means that all syscalls will take place WITH INTERRUPTS BLOCKED,it will be a *requirement* of a syscall that there simply couldn't have been any actions taking place around it that could have occurred with the interrupts on.This automatically takes care of the I/O problem,since all we have to do while making the swap is make sure a syscall isn't already taking place,in fact since hotswap() itself is a syscall,it pretty much takes care of itself.
This leaves us with the problem of how to actually implement further abstractions after that without losing performance.The fundamental idea is that an app should be able to CHOOSE these,and possibly add in some of its own if it wants to.The idea I favour is that some abstractions come with the OS by default,eg. a filesystem,and an app replaces them as it wants to,as outlined above.The architecture for doing this would I guess be very similar to my device driver "layer" model,this would leave us with 2 clearly different LEVELS of syscalls.The model I've got outlined so far is to simply have 2 different numbers for each of them (going by DOS,INT 21h and 22h :) ),the app would simply know when it's calling 22h that any of the calls may be replaceable.
The ONE exception to the above would be TCP/IP,there should be no extra JMPs where this is concerned,nor is it necessary,especially given the purpose of the OS (is anyone still using XNS or something?),as such it would be included in 21h.