Difference between revisions of "Porting the kernel"
(added to kernel and development cats.) |
m (added code tag pairs) |
||
| Line 1: | Line 1: | ||
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. | 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. | + | * UBC: need to account any platform specific VMAs created by hand in arch specific code. i.e. if there are calls of <code>insert_vma_struct()</code> this should be accounted with <code>ub_memory_charge()</code>. 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. | + | * If there are user triggerable <code>printk()</code>'s (related to the user, not the system as a whole) better replace them with <code>ve_printk()</code>. 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 | + | * Call to functions <code>find_task_by_pid()</code>, <code>for_each_process()</code> and <code>do_each_thread()</code>/<code>while_each_thread()</code> should be replaced with it's counterparts - <code>find_task_by_pid_XXX()</code>, <code>for_each_process_XXX()</code> and <code>do_each_thread_XXX()</code>/<code>while_each_thread_XXX()</code>, where <code>XXX</code> is either <code>all</code> or <code>ve</code>. Here <code>all</code> means that all system processes in the system will be scanned, while <code>ve</code> means that only the [[VE]] accessible from this task (current context - <code>get_exec_env()</code>) 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. | + | * <code>task->pid</code> should be changed with <code>virt_pid(task)</code> 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 interrupt handlers one need to set global host ([[VE0]]) context. i.e. <code>set_exec_env()</code>, <code>set_exec_ub()</code>. i.e. interrupt handlers are running in VE0 context. |
| − | * In kernel_thread() one needs to prohibit kernel threads in VE. | + | * In <code>kernel_thread()</code> one needs to prohibit kernel threads in VE. Mostly security related... |
| − | * show_registers() better to extend to show current VE. | + | * <code>show_registers()</code> better to extend to show current VE. |
| − | * utsname should be virtualized. | + | * <code>utsname</code> should be virtualized. This mostly means that <code>system_utsnames</code> should be replaced with <code>ve_utsname</code>. See any arch code for this. |
| − | * | + | * Some exports will be required. e.g. <code>show_mem()</code> and probably <code>cpu_khz</code>. Easy. |
| − | * | + | * Everything else are bugfixes. |
All these are straightforward and really simple, so it should take a few hours to do. | All these are straightforward and really simple, so it should take a few hours to do. | ||
Revision as of 11:19, 29 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 withub_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 withve_printk(). Otherwise user can flood (DoS). minor actually.
- Call to functions
find_task_by_pid(),for_each_process()anddo_each_thread()/while_each_thread()should be replaced with it's counterparts -find_task_by_pid_XXX(),for_each_process_XXX()anddo_each_thread_XXX()/while_each_thread_XXX(), whereXXXis eitherallorve. Hereallmeans that all system processes in the system will be scanned, whilevemeans that only the VE accessible 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->pidshould be changed withvirt_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.
utsnameshould be virtualized. This mostly means thatsystem_utsnamesshould be replaced withve_utsname. See any arch code for this.
- Some exports will be required. e.g.
show_mem()and probablycpu_khz. Easy.
- Everything else are bugfixes.
All these are straightforward and really simple, so it should take a few hours to do.
