kotovalexarian-likes-gitlab/sortix--sortix
1
0
Fork 0
mirror of https://gitlab.com/sortix/sortix.git synced 2023-02-13 20:55:38 -05:00
Code Releases Activity
sortix--sortix/libmaxsi/x86/fork.s

63 lines
2 KiB
ArmAsm
Raw Normal View History

Added sforkr(2) that controls the child registers as well. sfork(2) now calls sforkr(2) with the current registers. This will prove useful in creating threads, where user-space now can fully control what state the child will start in. This is unlike the Linux clone system call that accepts a pointer to the child stack; this is more powerful and somehow simpler. Note that this will create a rather raw thread; no thread initization has been done by the standard thread API (when it is implemented), so this feature shouldn't be used by programmers unless they know what they are doing. fork(2) now calls sfork(2) directly. Also removed fork(2) and sfork(2) from the kernel as they are done using sforkr(2) now. So technically they aren't system calls right now, but that could always change.
2012-04-05 17:00:47 -04:00
/*******************************************************************************
Renamed sforkr(2) to tfork(2). It's a much better name if you think of it as task-fork or thread-fork in the sense that it either modifies this task or creates a new one. This call will be used to provide user-space threads as well as fork(2).
2012-08-05 11:35:19 -04:00
Copyright(C) Jonas 'Sortie' Termansen 2012.
Added sforkr(2) that controls the child registers as well. sfork(2) now calls sforkr(2) with the current registers. This will prove useful in creating threads, where user-space now can fully control what state the child will start in. This is unlike the Linux clone system call that accepts a pointer to the child stack; this is more powerful and somehow simpler. Note that this will create a rather raw thread; no thread initization has been done by the standard thread API (when it is implemented), so this feature shouldn't be used by programmers unless they know what they are doing. fork(2) now calls sfork(2) directly. Also removed fork(2) and sfork(2) from the kernel as they are done using sforkr(2) now. So technically they aren't system calls right now, but that could always change.
2012-04-05 17:00:47 -04:00
This file is part of LibMaxsi.
LibMaxsi is free software: you can redistribute it and/or modify it under
the terms of the GNU Lesser General Public License as published by the Free
Software Foundation, either version 3 of the License, or (at your option)
any later version.
LibMaxsi is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more
details.
You should have received a copy of the GNU Lesser General Public License
along with LibMaxsi. If not, see <http://www.gnu.org/licenses/>.
x86/fork.s
Assembly functions related to forking x86 processes.
*******************************************************************************/
.section .text
Renamed sforkr(2) to tfork(2). It's a much better name if you think of it as task-fork or thread-fork in the sense that it either modifies this task or creates a new one. This call will be used to provide user-space threads as well as fork(2).
2012-08-05 11:35:19 -04:00
.globl __call_tfork_with_regs
.type __call_tfork_with_regs, @function
__call_tfork_with_regs:
Added sforkr(2) that controls the child registers as well. sfork(2) now calls sforkr(2) with the current registers. This will prove useful in creating threads, where user-space now can fully control what state the child will start in. This is unlike the Linux clone system call that accepts a pointer to the child stack; this is more powerful and somehow simpler. Note that this will create a rather raw thread; no thread initization has been done by the standard thread API (when it is implemented), so this feature shouldn't be used by programmers unless they know what they are doing. fork(2) now calls sfork(2) directly. Also removed fork(2) and sfork(2) from the kernel as they are done using sforkr(2) now. So technically they aren't system calls right now, but that could always change.
2012-04-05 17:00:47 -04:00
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %edx # flags parameter, edx need not be preserved.
Renamed sforkr(2) to tfork(2). It's a much better name if you think of it as task-fork or thread-fork in the sense that it either modifies this task or creates a new one. This call will be used to provide user-space threads as well as fork(2).
2012-08-05 11:35:19 -04:00
# The actual system call expects a struct tforkregs_x86 containing the state
Added sforkr(2) that controls the child registers as well. sfork(2) now calls sforkr(2) with the current registers. This will prove useful in creating threads, where user-space now can fully control what state the child will start in. This is unlike the Linux clone system call that accepts a pointer to the child stack; this is more powerful and somehow simpler. Note that this will create a rather raw thread; no thread initization has been done by the standard thread API (when it is implemented), so this feature shouldn't be used by programmers unless they know what they are doing. fork(2) now calls sfork(2) directly. Also removed fork(2) and sfork(2) from the kernel as they are done using sforkr(2) now. So technically they aren't system calls right now, but that could always change.
2012-04-05 17:00:47 -04:00
# of each register in the child. Since we create an identical copy, we
# simply set each member of the structure to our own state. Note that since
# the stack goes downwards, we create it in the reverse order.
pushfl
pushl %ebp
pushl %esp
pushl %esi
pushl %edi
pushl %edx
pushl %ecx
pushl %ebx
pushl $0 # rax, result of sfork is 0 for the child.
pushl $after_fork # rip, child will start execution from here.
Renamed sforkr(2) to tfork(2). It's a much better name if you think of it as task-fork or thread-fork in the sense that it either modifies this task or creates a new one. This call will be used to provide user-space threads as well as fork(2).
2012-08-05 11:35:19 -04:00
# Call tfork with a nice pointer to our structure. Note that %edi contains
Added sforkr(2) that controls the child registers as well. sfork(2) now calls sforkr(2) with the current registers. This will prove useful in creating threads, where user-space now can fully control what state the child will start in. This is unlike the Linux clone system call that accepts a pointer to the child stack; this is more powerful and somehow simpler. Note that this will create a rather raw thread; no thread initization has been done by the standard thread API (when it is implemented), so this feature shouldn't be used by programmers unless they know what they are doing. fork(2) now calls sfork(2) directly. Also removed fork(2) and sfork(2) from the kernel as they are done using sforkr(2) now. So technically they aren't system calls right now, but that could always change.
2012-04-05 17:00:47 -04:00
# the flag parameter that this function accepted.
pushl %esp
pushl %edx
Renamed sforkr(2) to tfork(2). It's a much better name if you think of it as task-fork or thread-fork in the sense that it either modifies this task or creates a new one. This call will be used to provide user-space threads as well as fork(2).
2012-08-05 11:35:19 -04:00
call tfork
Added sforkr(2) that controls the child registers as well. sfork(2) now calls sforkr(2) with the current registers. This will prove useful in creating threads, where user-space now can fully control what state the child will start in. This is unlike the Linux clone system call that accepts a pointer to the child stack; this is more powerful and somehow simpler. Note that this will create a rather raw thread; no thread initization has been done by the standard thread API (when it is implemented), so this feature shouldn't be used by programmers unless they know what they are doing. fork(2) now calls sfork(2) directly. Also removed fork(2) and sfork(2) from the kernel as they are done using sforkr(2) now. So technically they aren't system calls right now, but that could always change.
2012-04-05 17:00:47 -04:00
after_fork:
# The value in %eax determines whether we are child or parent. There is no
# need to clean up the stack from the above pushes, leavel sets %esp to %ebp
# which does that for us.
leavel
retl
Copy permalink