Re: Re-routing System Calls
Re: Re-routing System Calls
- Subject: Re: Re-routing System Calls
- From: Quinn <email@hidden>
- Date: Mon, 12 Jul 2004 14:17:38 +0100
At 23:03 -0400 24/6/04, Marek Kozubal wrote:
I would believe apple would suggest a layered file system before
they suggested doing anything with the syscall table. Thats even
more likely to break than the layered file systems at the moment.
The Apple folks nearly had a heart attack when someone was doing
this with exit().
Indeed. Patching the system call table is not something that Apple
supports. Apple is in the process of moving non-I/O Kit kernel
developers to new, sustainable programming interfaces, known as KPIs.
The current plan is that Apple will provide KPIs for all supported
areas of kernel development. For example, there will be KPIs for
leaf file systems development and another for NKE development.
The reason for this effort is that Apple needs to innovate within the
kernel, introducing 64-bit user address spaces, finer grained
locking, ACLs, and all of the other goodies that are part of Tiger
<
http://www.apple.com/macosx/tiger/unix.html>. Without a
well-defined set of KPIs it is impossible for us to make significant
changes in the kernel without breaking non-I/O Kit KEXTs. OTOH, a
KPI isolates KEXT developers from the internals of the kernel,
allowing Apple to make significant changes to the kernel while
maintaining KEXT binary compatibility.
It is unlikely that Apple will ever produce a KPI for patching the
system call table. There are at least two technical reasons for this:
o KPIs must be sustainable (that is, the presence of a KPI must not
adversely affect the evolution of the kernel) and we're don't want to
constrain the evolution of the system call table at this time.
o A system call table KPI would allow unregulated patching of
arbitrary system functionality, which is not a direction that we want
to take Mac OS X. The ghost of traditional Mac OS looms large!
It's likely that you'll still be able to hack your way into the
system call dispatch table on a future Mac OS X kernel. However,
it's also likely that doing this will "rev lock" you to the kernel.
That is, you'll need to update your product for every release (major
or minor) of the kernel. We've designed this back door for use
during development, or where your target market is tiny (for example,
a university research group developing a new network protocol).
Apple hopes that developers of shrink wrap software will move to the
KPIs as soon as possible.
Those of you who went to WWDC received a seed build of the next major
Mac OS X release, Tiger. That seed includes information about the
KPIs that Apple is currently planning. You can also download
supplemental information from the <
http://connect.apple.com>. Look
for the disk image associated with Session 103 "Kernel Programming
Interfaces".
I don't know when this information will be made available to the
general developer population.
One final note: the KPI effort will not affect developers of pure I/O
Kit KEXTs, that is, KEXTs that just use I/O Kit (and libkern). I/O
Kit is already a sustainable programming interface and we don't
intend to mess with it.
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.