I have come to the point where I have all the basic syscalls working, except for exec() and waitpid().
My main issue with exec is error handling: as it destructs most of the caller's resources, it can not recover from an error condition after the basic checks(ELF validation, permissions, argument/environment validation).
Free memory checks will be hard to implement as it will have to factor in the memory currently used by the caller and the fact that file reads might (will) put the caller in a in-syscall wait state during which another process might allocate memory needed by the process...
Does anyone know of a solution for this problem?
exec() syscall error handling
-
- Member
- Posts: 116
- Joined: Thu May 06, 2010 4:34 am
- Libera.chat IRC: peterbjornx
- Location: Leiden, The Netherlands
- Contact:
-
- Member
- Posts: 116
- Joined: Thu May 06, 2010 4:34 am
- Libera.chat IRC: peterbjornx
- Location: Leiden, The Netherlands
- Contact:
Re: exec() syscall error handling
Solution provided by thePowersGang on #osdev (freenode.net):
18:47 < thePowersGang> peterbjornx: The solution (to returning errors from exec) is not to use it
18:47 < peterbjornx> ...?
18:47 < thePowersGang> peterbjornx: In seriousness, the solution just to kill the new thread if loading fails
18:48 < thePowersGang> the parent should be watching for the child to die, and should catch that error
18:48 < peterbjornx> so just pretend nothing went wrong and sigsegv the process?
18:48 < thePowersGang> not sigsegv, make it return something special
18:49 < thePowersGang> e.g. return a status of 255 (the largest valid) or even set the upper bits to indicate why it failed to load
18:49 < peterbjornx> i was expecting to have to return all kind of fancy errno's from exec as i am using linux man-pages as a reference
18:49 < thePowersGang> nope, once exec starts, you can generally expect not to return