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 | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.