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: Terry Lambert <email@hidden>
- Date: Wed, 30 Apr 2008 20:11:51 -0700
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 not about blasphemy or renumbering of the vectors (though, if we
chose to, we could randomize the vectors to harden code at some point
in the future, and that would break you too).
It's about the system call interface and the libc interface being
completely different.
As three examples:
(1) the system call "kill" takes three parameters, while the library
version of kill takes only the two parameters documented in the man
page. The system call's third parameter is whether or not kill should
act in a POSIX conformant manner or not when sending signals to a
process group of which you are a member (POSIX says you get signalled
to; historical behaviour says the sender is not signalled).
(2) the system call "posix_spawn" takes a single parameter, which is
an argument descriptor structure; the posix_spawn in the library
thakes 6 parameters. The purpose of passing a descriptor block is to
allow a single "copyin" operation, rather than a bunch of copyin
operations for each of the possible parameter blocks for each of the
arguments, plus any of the _np arguments.
(3) the error codes returned by the socket oriented functions is
EOPNOTSUPP (operation ; however, prior to POSIX conformance, this
error code was identical to the error code ENOTSUP (operation
attempted is not supported on the object referenced). Binary backward
compatibility is maintained by interposing a libc stub to translate
the EOPNOTSUPP to ENOTSUP, realiasing it for programs that expect it
to be aliased, and which are not compiled in the POSIX compilation
environment.
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.
-- Terry
_______________________________________________
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