Difference between revisions of "Porting the kernel"
(created (taken from forum)) |
(added to kernel and development cats.) |
||
Line 25: | Line 25: | ||
== External links == | == External links == | ||
* [http://forum.openvz.org/index.php?t=msg&goto=3338&&srch=sparc#msg_num_5 Original forum post] | * [http://forum.openvz.org/index.php?t=msg&goto=3338&&srch=sparc#msg_num_5 Original forum post] | ||
+ | |||
+ | [[Category: Kernel]] | ||
+ | [[Category: Development]] |
Revision as of 16:10, 20 June 2006
OpenVZ kernel supports x86, x86_64, and IA64 architectures as of now. Below are the quick and dirty information about how to port the kernel to yet another architecture.
- UBC: need to account any platform specific VMAs created by hand in arch specific code. i.e. if there are calls of insert_vma_struct() this should be accounted with ub_memory_charge(). Didn't find such thing on sparc64.
- If there are user triggerable printk()'s (related to the user, not the system as a whole) better replace them with ve_printk(). Otherwise user can flood (DoS). minor actually.
- Call to functions find_task_by_pid(), for_each_process() and do_each_thread()/while_each_thread() should be replaced with it's counterparts - find_task_by_pid_XXX(), for_each_process_XXX() and do_each_thread_XXX()/while_each_thread_XXX(), where XXX is 'all' or 've'. 'all' means that all system processes in the system will be scanned, while 've' means that only VE (VPS) accessiable from this task (current context - get_exec_env()) will be visible. So you need to decide, whether the code in question is about system or user context.
- task->pid should be changed with virt_pid(task) in some places. The rule is simple: user should see only virtual pids, while kernel operate on global pids. e.g. in signals, virtual pid should be delivered to app.
- In interrupt handlers one need to set global host (VE0) context. i.e. set_exec_env(), set_exec_ub(). i.e. interrupt handlers are running in VE0 context.
- In kernel_thread() one needs to prohibit kernel threads in VE. mostly security related...
- show_registers() better to extend to show current VE.
- utsname should be virtualized. this mostly means that 'system_utsnames' should be replaced with 've_utsname'. See any arch code for this.
- some exports will be required. e.g. show_mem() and probably cpu_khz. easy.
- everything else are bugfixes.
All these are straightforward and really simple, so it should take a few hours to do.