On Thu, 17 Jan 2008, James Carlson wrote:
> Joseph Balenzano writes:
>> According to /etc/name_to_sysnum and syscall.h sytem calls 64 - 69 are
>> reserved. Are they actually in use or just marked reserve for future
>> development?
>
> It looks to me like they were reserved _long_ ago by AT&T for
> something called "UNIX PC," but never used. They predate Solaris.
>
> I have no idea if they were ever used ... but why would this matter?
> The syscall interface is private to the ON consolidation. The numbers
> in use aren't documented, and may change at any time. In particular,
> if you compile these into an application and generate your own system
> calls, your application may stop working at any time, without notice,
> even in a patch.
>
> Unless you're integrating something into ON via OpenSolaris, you
> probably shouldn't be relying on these.
As a bit of background, the actual system call interface, in other words:
"How does an application perform a system call", is not documented. It's
explicitly _NOT_ part of the UNIX standards, and _NOT_ part of the
platform ABIs.
The documentation ends with the libc interfaces. Section (2) of the
manpages gives you the libc function to call which will then perform a
specific action for you.
Why is that so ?
The answer is manyfold. For one, because the specific "best" mechanism how
a system call is performed depends on a lot of things:
- does it take arguments ? If so how many ?
- what's the lowest-latency context-switching instruction on
the CPU type we run on ?
- do we even need to perform a full context switch ?
The actual system call mechanism - how you issue the system call - depends
on all these factors and there's no guarantee that, just because you've
used "instruction X" to issue a system call in the past, this will be
maintained forever.
That is, by the way, also the reason why we're not supporting static
linking. Statically linked binaries embed "system call" instructions, and
hence will break if updates are done to the syscalling mechanism.
(and yes, we have done this in the past. We currently maintain the old
UNIX 'lcall 0x27' on Solaris/x86 only because there's little to gain from
removing it)
Second, what if a severe flaw is found in a system call mechanism ? A
horrid security bug, for example ? Reassigning numbers in such a case
might be quite a good idea, to allow intrusion detection, flagging
deliberate callers of the old/flawed interface.
Also, the calls evolve. What is now a set of system calls might be at one
point in time be merged into a "compound" one. See, for example, the
"doors" syscall - where the same one, with a subcode, is used for e.g.
both door_call and door_return. Imagine wanting to do the same for e.g.
read/write - why not ?
Finally, not all section (2) interfaces actually will end up performing a
system call - depends on the platform/OS. Some might possibly be handled
in other ways. Or might possibly be handled in other ways in the future,
which would lead to depracation/retirement of a syscall.
What's stable is the library entry points. They're standardized, and we
commit to these interfaces (by having UNIX certification done).
A bit of technical background:
Russ Blaine's blog, http://blogs.sun.com/rab/ has an entry on how we
perform syscalls on the x86 platform - which illustrates nicely some of
the things that can happen, like the use of different CPU instructions for
the actual "system call".
FrankH.
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
