Re: XNU sys_fork syscall (0x02). Linux vs XNU
Re: XNU sys_fork syscall (0x02). Linux vs XNU
- Subject: Re: XNU sys_fork syscall (0x02). Linux vs XNU
- From: "Robert Spykerman" <email@hidden>
- Date: Thu, 1 May 2008 18:27:13 +1000
On Thu, May 1, 2008 at 1:11 PM, Terry Lambert <
email@hidden> wrote:
On Apr 30, 2008, at 4:38 PM, Robert Spykerman wrote:
Actually had a discussion along this line, about whether to call c libs or not... Ultimately we decided to stick with syscalls because of various reasons ( specificaly it could break quite a bit of code already in existence, requiring more rewriting. Apart from that, it's just... somewhat unappealing to call a c lib just to call the kernel to get the same functionality, but I can understand it may be blasphemous to some to do it any other way, heh ).
The port is going well, and there are just one or two finishing touches before intensive testing.
But honestly, it's no biggie if I know where to find what I need to change with any major OS change. And it looks like this libSystem is what I need to go dig up. I hope the source is available, will go look now.
As an aside, I don't know how often syscalls have changed. The vector numbers for BSD and OS X appear very similar. Surely there must be a lot of BSD code ported over to OSX XNU which makes syscalls... with more to come.
I understand Apple may change these vectors at any given time, but it also may be in their interest to keep it as close to BSD as possible maybe. And that's a big maybe I guess.
It's about the system call interface and the libc interface being completely different.
... <snip>
That's about 11 system calls that aren't going to act the way you want them to act when you call them directly. There are literally dozens of others.
Similarly, the use of INT routines is a legacy support item; the current implementation is use of syscall or sysenter, depending on whether you use 32 or 64 bit hardware, and the support for use of INT is only there for certain parameter sets that would result in the destruction of volatile registers otherwise, based on the ABI.
In general, you will find that actual system calls have a contract between the kernel and libc/libSystem, and that a program expecting the environment described in the man pages has its contract with libc/libSystem, instead of the system call boundary.
So calling these things yourself is a pretty bad idea, and calling them in a way that's tantamount to statically linking your binary is a very bad idea, even if what you are trying to write is a Forth interpreter
Ok, I hear you. I will have to seriously look into llinking to libc then... I have to admit, I am not too gone on this but as you have described, it is the proper way and when in Rome...
Thanks very much for all this - it really helps a noob like me. Really appreciated. All of you. Cheers.
PS I take it you're probably gonna really say no no no no too to what we were kind of planning to do the mach-o header? :) - ie hack it so that the entire forth dictionary gets written back to disk within the same executable, when the user so chooses to do so? :)
-- Terry
Robert Spykerman
--
chown -R us ./base
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden