WWDC2003 Session 107

Transcript

Kind: captions Language: en good morning and welcome to the kernel programming interfaces for extension sessions I'm Craig Keithley I'm the i/o technology evangelist and Apple's Worldwide Developer Relations group as the i/o technology evangelist I work with a lot of qex developers and over the past couple of years we've faced some challenges with regard to making sure that we have a set of consistent api's that will remain useful for through the life of a product so we've we've now looked at providing what's known as KPIs are criminal programming interfaces to talk about that címon patience director of engineering good morning so let's uh briefly describe what well it's going to be covered today first of all we'll go through a definition of rationale of kernel interfaces and where we're going to be taking them over the course of the the next year or so we'll be looking at how we're going to be managing the the version progressions as we evolve them we'll have a look at the effects on IO kit will cover general kernel interfaces and the file system interfaces then we'll have a look at some networking interfaces for kernel extensions and then we'll sum up and then Q&A so kpis so what are they well obviously kernel programming interfaces there's obviously a relationship between those and an API is just in the same way that that in in libraries there's a whole lot of functions but you don't actually get to program to them all we're using that kind of analogy here for cutter for the kernel they're sets of well defined interfaces are bounded as I mentioned they cover both functions that the kernel provides but also the rules by which you can access data the sets are versioned as we move through time we will be evolving these interfaces some will be changing some will be being added and the reasons that they're versioned is because they really reflect the implementation rather than the interface as the system moves on and we want to have a well-defined life cycle so that you know what's coming and what what to expect we're currently targeting specific classes of kernel extensions we will be adding new classes as as there is demand and as we can identify what the correct interfaces for those will be so let's have a look at one of the motivating factors that we have for putting in kernel interfaces which is our what we could describe is the KX dependency problem so here's a picture of the OS 10 kernel and there's a picture of your text and as you load it let's say it's a networking text then there's a set of interfaces which we can clearly see your dependent on because those are the unresolved symbols in your kext the big problem for us is that we have no idea especially if you're going through through data what these additional implicit dependencies are and so we we cannot define what the compatibility points are that you're at your cases depending on so why do we need these kernel interfaces well as I just mentioned Cakes have no explicit dependencies not a total set of explicit dependencies we cannot work out exactly what it is that we can't change and os10 needs to evolve there's a whole set of reasons why we need to change the kernel we have new features that were coming in to provide a better user experience we have performance improvements that we need to do there are bug fixes obviously we try to limit limit the number of bugs that we have in the system but they do occur from time to time and we need to be able to fix those in ways that don't break binary compatibility 4kx clearly there's new hardware such as the hardware that was announced today this week I mean that takes a certain amount of change in the kernel and has ramifications on on kicks if there are no boundaries and SMP support the the funnels are well known within the system and we need to do something about them to get rid to get better SMP performance and so without these interfaces this really makes change within the kernel very difficult to achieve so these interfaces define what I like to call our innovation sandbox so why would developers one kernel interfaces well first of all it means that we can have a set of interfaces that are best suited for your needs we can design them such that they perform the functions that you're trying to achieve in the most efficient manner we can improve the stability the environment and we can provide binary compatibility from release to release for these interfaces and they were significantly reduce the chance of us changing things that unbeknownst to us is breaking your case because we can now test those interfaces and ensure that they are semantically and syntactically equivalent from release to release so we have a number of states just to let you know exactly where the status of this interface is we have defined for states that the stable interface these are basically the things that you've seen in the kernel and you know the general stuff all the Lib C functions for example stuff like that they're not growing away and they're guaranteed to be in the next major release and so you can rely on those in your products compatibility interfaces are basically the same as stable interfaces in terms of their longevity the difference is the fact that we're trying to mark them especially because they are therefore porting from one system to another and there may not necessarily be the most efficient interface to use so we don't want to mix them in with the stable interfaces we want to indicate which ones are the the ones that you should really be going towards when we decide that an interface has to to change or go away for various implementation reasons then we'll market as being deprecated this means that the interface is going to be removed or is planned to be removed in the following major release and finally we have another set which is called evolving these interfaces are under development and normally under development with you this is in order to be able to support new kinds of checks that we don't really know what the right interface is and we would like to work with you in order to be able to develop that the the best set of interfaces both for your purposes and for ours so what are we going to be doing this well the draft specification for these interfaces is available now we'll be giving you information about how to get hold of them later on this is really just the end of the interface specifications the implementation for those will be coming in the Panta timeframe and during Panther the as the system evolves in the Panther there are updates will be also evolving these interfaces and the implementations of them so that you can track them to see how we're adding to them and evolving them so that they become something that we can actually make stable and say that we can live behind the first set of stable interfaces will be different declared with enough time before Panther so that you can actually port to them and make sure that you're in a stable place by the time the next release comes out the post Panther major release comes out where we will start to enforce these interfaces and with that I'd like to hand over to Dean Reese who's the engineering manager of the i/o key team who will talk about how we're going to managing manage the version versions of these interfaces [Applause] thanks Simon good morning all right I'm going to be talking a bit about the text system and how we're going to manage the KPIs that Simon just talked about so let's get right into it for pan through the DX tools have not really changed as you recall for Jaguar we totally revved the entire set of kernel extension management development tools pretty much got on where we wanted them to be so for Panther we didn't really change them we have however added some new capabilities to support the kernel programming interfaces basically we've created a new type of text it's not something that you're going to be needing to use directly we're gonna provide them you'll link against them it'll be pretty much transparent and I'm going to talk about that in the next few slides but the fundamental change that you'll notice and again it shouldn't really cause any code changes for you is that right now your text link directly against the kernel and in Panther and Beyond they will link indirectly against the kernel and I've got some diagrams to show how that works so in Jaguar if you list a dependency for your text on any of these CF bundle identifiers here listed in blue then you're saying that you need the kernel and because of the way that we did the linking for kernel extensions if you said you needed something from BSD then you actually got the entire set of kernel symbols so you could have a dependency over on i/o kit that you didn't actually declare and it would actually work the linking would would succeed because you are getting the whole kernel and all the symbols in it obviously as we're trying to move towards an enforced interface design we can't have this we have to have a little bit more partitioning between the different programming interfaces so for all versions prior to 7.0 this is true if you link against one of these you get all of them for free this is what it looks like sort of in a pictorial form basically all of the sub identifiers for the kernel represented the whole kernel and no matter which one you linked on you got the whole kernel so in Panther we're gonna provide binary compatibility through a set of interface qex the new type of text I talked about and basically all they contain is a set of symbols there they're basically re exporting the symbols from the kernel but they only export the set of symbols that you should be using for whatever version you want it so basically what we're doing is taking all of the symbols it shipped in all the versions of Jaguar for all of the calm down a poker kn'l bundle identifiers and we're putting them together in one big interface text and if you list a dependency on one of those a version prior to 7.0 then you're going to get that interface kext and you'll get all the symbols that you got before modulo a few that we had to take out to support the new g5 hardware so basically you're gonna get exactly what you got before should just come up and work yeah let's move on and look at a picture of how this looks so in this case your text and orange there is linking against the BSD interface text which supports compatibility everything from version 1.1 up through version 6.0 actually i think we've made that up through 6.9 just to give us some leeway there and that in turn links against the actual kernel actual running kernel and that sort of provides the filter to give you the correct set of symbols for the version that you've asked for so we're also going to provide a new set of kernel interface texts for Panther these are going to be version number seven version number seven so they're going to contain all the symbols that we believe we should support carrying forward we're going to remove a large number of symbols that are sort of internal support functions that really shouldn't have ever been exported in the first place and we're also going to add the new functionality that we've introduced in Panther there so basically if you've got a kernel extension that you've been shipping it'll continue to run in Lincoln Panther because it'll link against the older version 1 through version 6 compatibility interface text and if you've got a brand new kernel extension that needs to take advantage of new functionality then you use the new set ok and this picture looks exactly like the picture before the only thing that's changed is version numbers you'll see everything across the board is 7.0 now we still provide a capability in Panther that we provided in Jaguar and that is you can still link directly against the colonel it's necessary in fact as an implementation detail our interface qex link directly against the colonel and they actually play by the same rules that your qex do so if you select calm down Apple dot curl as the dependency you will still get all of the symbols exported by the colonel now we don't guarantee any release to release compatibility with the global set of symbol kernels because we can't as Simon said unless we have some enforcement and partitioning here we can't guarantee you compatibility because we can't know what exactly you've used out of that large massive interfaces so what we do every time we ship a new kernel it gets a new version number as it should and if you list a dependency on the kernel you must list a dependency on an exact version of the kernel the implication being that the next time we ship a software update with a new kernel in it your kernel extension will not load on that version of the OS or the next major version as well so this is really not a good way to ship product it's useful in say with open source projects where your shipping source code and the client can recompile for whatever version of the OS they want to use or maybe in educational institutions where you're working on a particular OS for a class but I thought I would point it out is it is still a possibility it just isn't something you would really want to do as part of a product and that's what that looks like basically you're bypassing all of the compatibility interfaces and you're linking straight against the kernel and again here you'll notice the dependency version listed in the text is identical to the version of the kernel listed otherwise the linkage would fail so what does this mean going beyond Panther well basically you'll continue to use the same rules you use today we're introducing a new namespace I shouldn't actually not a new name space and you naming convention within the existing CF bundle identify our namespace that we already use and that is calm down a Pilate I you'll see this in the Panther seed CD that we've given out this week and you'll see it more going forward so combat Apple about Colonel will still be around and will represent the compatibility interfaces calm down Apple lock API will be used going forward to present the new supportable interfaces and the two will coexist on the system as much as possible will also use this mechanism to make experimental interfaces available to you as we over the life of Panther deliver newer updates to our KPI package will deliver that and that will introduce new interface qex to your system possibly a new kernel as well for the implementation behind them but that'll partition them off from the compatibility interfaces because again the version numbers sound kind of separate them into past in future obviously and again as Simon said as the kernel of all's we're going to need to deprecated api's particularly initially as we start to thin that set down to the ones that we really can support and kpi's allows us to do this because we can have a version set that we maintain as long as possible and then when in whenever point in time it becomes impossible for us to continue to support that we can remove them and it won't affect anybody who's dependent on a different interface or a different version of that interface it will only affect the people needing the old version of that particular interface so it really provides us a sliding window or the what I like to view it as sort of a conveyor belt that's some length long and we introduce an interface and we can support it pretty much as long as we want to but eventually we may have to move off of it as we evolve the kernel all right so I'm also going to talk a little bit this morning put on my i/o kit manager hat and talk about how this Panther release introduces new things for i/o kit so the good news is the i/o kit in Panther is binary compatible with what we shipped in Jaguar so the v6 versions of the interfaces that we ship will continue to load your i/o kit qex from Jaguar on Panther and they should work obviously there's always a potential for bugs this is what you need to do is take the seed that we've given you and try it out with your products make sure that they work let us know if they don't but the expectation is that properly written kernel extensions for i/o kit should continue to load and run on Panther we've also introduced a few new interfaces for Panther those are only available in the v7 interface again a KX and Needham v6 shouldn't need those interfaces and we've also deprecated a few interfaces they I think they've actually been marked in the header files for a couple of years now is going to be deprecated well now we have a mechanism to actually deprecated them so we're making use of that all right so the v7 interface that we provide in Panther for i/o kit it has a number of changes to io memory descriptor as you can imagine being able to address greater than four gigabytes of memory has some implications for the way drivers deal with physical memory so if you've used the abstractions for i/o memory descriptor correctly you should not have any problem with your driver continuing to work on those machines and addressing a large memory if you've gone directly to the P map functions or other workarounds so that you've avoided memory descriptor then you probably won't work on those machines so you need to use memory descriptor we've added some convenience functions listed down here io map to read 8 16 32 64 basically these allow you to do direct i/o to your hardware without generating how many create new memory descriptors just for your registers and we've also removed a few from from Panther v7 from i/o kit these are two classes I think there's another one on the list this is not a final list obviously as Panther is not final but IO command Q and IO sinker or two classes that were introduced very early on an IO kit and were realized is not supportable a long term and I think they've been marked as deprecated for quite a while hopefully this shouldn't affect any of you but again they will be present in the kernel but they'll only be available for linking if you have a v6 dependency it'll just be mAb sent from the v7 dependency so with that I would like to introduce mark Berlinski the manager of the kernel team at Apple I brought my script with me so as a kernel manager it's my job to improve the Mac OS 10 kernel and maintain the stability scalability and performance without breaking binary compatibility today we expose all of the kernel interfaces and so every every bug fix we make every feature we add we risk the opportunity or we have the opportunity to break binary compatibility so we needed a way to evolve the macula same kernel without breakage so we need to move forward today we use two funnels to address the scalability of the Mac OS 10 kernel but final contention has led to a performance impact of MP systems to address this we're moving beyond the funnels we're going to be making the BSD kernel thread safe and implementing a fine grain locking we will also be making extensive changes to the kernel data structures which includes adding reference and usage counts so kernel data structures are going opaque and they'll be accessible only through data accessors functional routines and convenience api's we will also be exposing locking protocols the data structures where it leads to efficiency but otherwise we will be hiding for locking details behind the interface all new interfaces will be MP safe this includes date accessors functional routines as well as convenience api's okay today the file system block numbers are 32 bits as we move forward they're going to be going to 64 bit this is important for large file system volumes also it will have an impact on all interfaces that use block numbers file system denote operations are currently not symmetric with respect to V node locking and reference counting this makes the job of providing efficient whole efficient stackable file systems very difficult for example operations such as v up close and via getattr are entered without locks being held any node locks moving forward all V no locking will be symmetric there are also many common functions in the BFS layer that should that the vs layer should have that are currently replicated by all the file systems to address this we are moving these some of this functionality into the generic into a generic VFS layer for example functionality like NFS export device alias checks will be moving into this area this layer keep in mind that the goal of these interfaces is to allow the Mac os10 kernel to evolve without breakage when we just give a background when we started this we took a look at our own kernel interfaces we looked at our shipping file system drivers and networking extensions we determine that drivers and i/o kit based extensions were in good shape so we've decided to first address VSD file systems and network extensions and we'll address other extensions later we considered only providing interfaces that reliable scalable and could be implemented without affecting compatibility of the extensions this is our first round of iterating on these interfaces we were expecting them to evolve and we look forward to your feedback okay this diagram gives you a perspective as where to where file system extensions reside in the kernel as you can see file system operations are dispatched through the VFS layer as a set of VF s and V node operations let's look at what other interfaces they may use okay so like I said they are implemented as VF s and V no tops they also use common c functions and kernel support functions which every kernel extension can use they also utilize functions that the bsd kernel extensions would use such as credentials for authentication and process api's they also utilize file systems specific interfaces for file data caching such as buffer cache and UVC let's take a look at C functions here okay so the kernel provides a subset of standard C functions such as string and memory manipulation as a kernel extension developer you should be aware that these functions are not as fully featured as their user Lite user layer Lipsy counterparts also there's nothing there's really no change that's any of any significance here kernel extensions will continue to have access to all the standard C functions that exist today additionally there are kernel support interfaces that provide access to resource management and thread control as well as memory management routines such as malloc and free synchronization routines like sleep and wake up routines to provide locking using simple locks and mutexes which can be used by kernel extensions to protect their data there are also routines to do thread call out routines for data copy like copy and copy out which will be changing to support 64-bit addresses so far the interfaces i've discussed are relatively gone on change with the exception of 64-bit address support however as you'll see from this point on you'll see a significant change in the interfaces many kernel extension use routines use routines that are considered bsd kernel interfaces we are providing interfaces for authentication and process limits and process IDs for example for a given process ID you can signal the process where you can get a handle to the process but you should now be aware that this handle is opaque and does not point to the process struck directly it kind and it comes with a reference countenance that will have to be dropped later also we are moving towards thread based credentials these credential the credentials had a process enters the syscall with you know through the thread interest Cisco actually will be stored in a thread local data area so it can be accessed quickly without contention we will also be providing interfaces to obtain a reference v node or socket through a file descriptor we will consider adding other interfaces to things like file ops and ttyS sometime in the future if you need access to something that does not coverage send us your feedback however some interfaces which owes not to provide interfaces at risk stability and that are not sustainable for example direct access to the system call table it is not going to be provided in these cases you will have to work with us and possibly final turn ative mechanisms or so the nose or work with us to prefer so we can provide you with a sustainable and stable mechanism file caching these interfaces are mostly used by file system kernel extensions to do caching of meta and file data both struck buff and ubc info are going opaque all let's say effect all data structures are going ok for buffer cache we have left the semantics and usage the same but we have implemented a new interface is to use 64-bit block numbers for example get block is now called buff underbar get block and it takes a 64-bit lock number we have also left the semantics of UVC the same except further macros the UCC macros such as UVC is invalid are now actually functions otherwise we have maintained the same API but remember these structures and how opaque so another example would be B right instead of taking a struck buff it now takes a buff T throughout all our efforts we try to remain or maintain the familiarity of the subsystem we didn't want you to have to learn all new interfaces but we had to make changes to support the opaqueness of the data structures and for locking the reference counting if there's an interface again that we missed send us your feedback okay DFS ops DFS operations are are already a set of well-defined routines to manipulate individual volumes through mouth structure however the mouth structure is now opaque and it's called Mountie mount under party this is the datatype every VFS operation will receive we are now providing new accessors accessor functions to the mount structure for example instead of testing mount rd only in the mouth flags you would now use VF s is art rd only to check the file system is mounted read-only all mount flags that are visible directly to user level will be exposed additional functions will cover access to other kernel malphite's oh I need to go back we have also added interfaces like BFS iterate to provide access to be nodes on a given mount these are done in an MP safe way we have renamed modified status structure it is now called VFS staff s we have changed the block number fields to 64-bit so we can support large file system volumes we have expanded the path length path names

• max path link for to address

localization issues we have created a new IO attribute structure called DFS IO adder again that this is the structure that contains I Oh attributes associate with a map point but we have added some new new information about the device capabilities such as you know how many bytes the device can actually read and write at one time there are also new interfaces to get and set these structures within the mouth structure also we've added some new VFS operations to support dynamic growth of a file system they are VFS extend and VFS truncate we have added BFS uninit to complement BFS in it and moved it move them both to file system registration instead of VFS off we have untangled EFS mount operations and defined new VFS ops for update and reload this was done to keep the logic and code clean and uncomplicated DFS operations are defined by a structure with various function pointers we are changing this to be similar to the way that vino tops are done we will make the FF ops extensible so that we don't have to worry about breakage when we add new BFS ops ok vino tops vino operations are set of well-defined routines to manipulate individual files so if you note structure again as on all the data structures V node structure is now opaque and is called V no T this will be the data type all be node operations will receive and we are also providing new accessor functions for this structure we are making v note operations symmetric with respect to v node locking and this does have an impact on with respect to how he manager Vinodh locks we wanted to empower the file systems to enforce the locking locking their way so now file systems don't have to use the same locking same locking rules that VFS used to be enforcing so if a file system wants to provide multi reader similar writer locks they will be able to do so without having every file system support the locking semantics we have also modified the sequence of events to create AV node instead of calling get V get new V node and then associated the relevant data and so on to the V node structure you can now call Vinodh create which passes in all the relevant information in one call such as I know pointer mount T and so on at which point after the call the V node is fully constructive and it's complete has complete information in this way we we avoid having to use too many accessories to set all this up and that the side effect is have the ability to manage your own inode pool without tying it to the Vino pool let's see we are adding new functionality to suspend and resume a V node and a mounted filesystem this can be used acquiesce entire file system so we can make on disk manipulation changes finally there's a new theater structure has been updated to support 64-bit blocks called V no a be a dirty and just want to close was saying that again we are iterating on these interfaces and your feedback is going to be very important to us otherwise you know we can consider the interfaces not complete if you don't give us your feedback and you get to help determine our future and your own future yes that's to where these interfaces go and that's it I like to introduce josh grace please who will be doing networking [Applause] hey I'm gonna be telling you about the network colonel programming interfaces that we've been working on we have six interfaces we've been planning the EM buff socket socket filter IP filter interface filter and interface and here's a diagram of the networking stack so at the top we have the sockets and between the sockets and the protocols we have socket filters and attach to IP we have IP filters and down at the bottom we have interfaces with interface filters attached to those all of the items in purple will be the kernel extensions can supply to the stack so as a engineer that's been working on the stack for quite a while I spend a lot of time tracking down bugs and I quite often run into a bug that has a simple fix but the simple fix would end up breaking a kernel extension so we end up with some pretty innovative fixes in the kernel which we're getting a little we'd like to do better so one of our goals is to make all the data structures opaque so we can extend them when we need to we're going to change a lot of the filters to be based on operations instead of implementation as much of the implementation as we can hide from you the better off we are because that lets us change it will modify a lot of the fun the new API is return errors more often than the old ones did so for example instead of when you call MC I'll get instead of checking a flag to determine whether or not the call succeeded the call will just return an error if it didn't work we're also looking at additional interface sets we're looking at adding support for new interface families as well as new protocols first KPI is the MF KPI all the packets in the networking stack are stored in M buffs the am buff structure used to be visible to kernel extensions but we're making a change then both will be opaque and it will be referenced with an M buff underscore T you'll be provided accessor functions for allocating and manipulating M buffs as well as inspecting them and getting to the data that they contain the naming of the new functions will be consistent with the old functions so it should be pretty simple to port most of your code for example MTD becomes M buff underscore M to D and M underscore free M becomes M buff underscore free m most of the functions will return air is now M CL get is a great example of that it should make the code a little bit less error-prone again we have the network diagram the diagram the stack and at the top we have the sockets and we will be providing a socket interface or socket KPI to kernel extensions so they can make use of sockets within the kernel common use of this would be a network file system the socket KPI will be provided so they can perform all of their network operations using this the KPI is based on the user space ap is to create a socket the kernel extension uses Sauk underscore socket to bind to a specific address and port it uses Sauk underscore bind the socket and proto SW structures when they'll be opaque you'll have no direct access to these structures and the protocol control block will also be hidden so you'll need to use things such as get sock name get pier name and get sock opt to get access to the information that's stored in the protocol control blocks between the sockets and the protocols we have socket filters socket filters have been completely rewritten there now based on the operations instead of the implementation it lets you filter data and commands at the socket layer you'll be able to receive notification of changes of state changes to the socket for example you get a state change notification when the state when the socket goes from the connecting state to the connected state you'll no longer be able to intercept or prevent these changes we also allow you to specify inbound and outbound data filters the inbound data filter will pass data to you no matter how it comes in in the past you used to have to filter SB append SP appended or SB append control and a wide variety of similar things and there were some other problems with that if you're filtering inbound data and TCP input called SB append to put the data in the socket buffer when if your kernel extension held on to the data so that it could later re-inject it and it returned you just returned SB append didn't actually have any semantics to let the caller know whether or not there was data appended to the socket buffer so tcp would go ahead and wake up the client who was waiting on the socket the client would read get zero bytes read and it would think it was an end of file and aronia silly erroneously close the socket which would lead to lots of strange problems so we have inbound and outbound data filters that should just work and make things a lot simpler we also have inbound and outbound connection filters so your inbound connection filters past the address that the connection is coming in from and you'll have an opportunity to refuse that in the case of TCP will actually send a reset if you refuse the connection so you could potentially build a firewall using these filters at the socket layer instead of doing it at the packet layer we can also filter outbound connections so you can enforce stricter security you can also filter on binds and get in set socket options as well as listen and dioctyl moving down the stack a little bit attached to the IP protocol we have IP filters the IP filters give you a place to filter packets at the IP layer it's brand-new you can filter inbound and outbound packets and on the inbound side you get the packet after it's been reassembled and after all of the media specific headers have been stripped off you also get to filter both before and after IPSec processing has occurred so if the packets are encrypted and authenticated you'll get to see it both when it's encrypted and after it's been decrypted and you'll get to see any credentials or any authentication that's occurred on the outbound side you'll get to filter before the deception before the packets been fragmented and before before we applied the IPSec processing this will let you modify the data before it gets encrypted and authenticated and inspect it before it's encrypted and won't mean anything to you anymore the filters can be a trap attached to ipv4 as well as ipv6 and moving down the stack further attached to the interfaces we have interface filters that let you filter packets at the interface layer in the network interface filter KPI provides kernel extensions the ability to attach these interfaces attach these filters to your interfaces the interface filters are based on the DLL interface filters the difference being that the types are all opaque you'll be able to filter inbound and outbound packets on an interface as well as a 'aka yock tools to an interface and events coming from an interface and at the bottom of the networking stack we have the interfaces themselves the network interface KPI provides a number of things you can do with the interfaces the interface is used to be represented by AI fnet structures the AI F net structure will now be opaque and you will get a reference to it the reference the structure is reference counted and will provide accessors for inspecting various properties of the interface as well as sending packets and performing och tolls and other various operations it also give you functions for getting a list of interfaces and finding a specific interface you'll also have the ability to retrieve a list of addresses that are attached to the interface as well as multicast addresses and you'll be able to join and leave multicasts you also be able to add an interface but you'll only be able to add an interface that belongs to an existing an existing interface family such as Ethernet PPP and firewire and with that I'd like to bring Simon up [Applause] so obviously we can't go into huge amounts of detail in the amount of time that we've had available I hope that's giving you an indication of the direction that where we're going so to summarize the reason that we're doing this is is numerous actually where it's to allow Apple two to innovate in the kernel to take the OS 10 kernel into the future where the new hardware and the new configurations are waiting and the new functionality is waiting for us it allows us to improve the quality of the kernel as was mentioned a couple of times they've been bug fixes where we've actually found it difficult to fix without breaking compatibility in somewhere it's actually been impossible it allows developers to write checks more easily you now don't have 100,000 interfaces to choose from many of which will be the wrong ones which you may not know at the time so now the the programming interface becomes a lot more clear as through exactly how you can develop your case we can provide some future proofing for you we guarantee the compatibility of an interface from release to release we actually have a much greater chance of ensuring that that's correct as we move forward because assuring you know the hundred thousand interfaces that are currently in there in the kernel including all the data usage models that there may be is almost an impossible job and with this because the state transitions of interfaces we can provide a much more predictable rate of change for developers we can guarantee that exists that interfaces will exist from one release to another we understand the contract and you understand the contract so we can give you a much more predictable environment we also believe that this will provide a better user experience for when cakes become out-of-date and things do go wrong as a the moment probably what will happen is that the cakes will be loaded and then sometime later the kernel will crash because there's some incompatibility of daily usage between the kernel and and your text so now it becomes much more apparent we actually catch it at load time that that something has changed in this case and that is no longer available to be used on this particular Rev of the system and the other big thing is that they start today well actually perhaps not quite today because we don't have the the interfaces actually available on the web yet however we will be getting them on to the developer website very soon where you can download the draft interface specifications you should look at developer.apple.com and there'll be a new section I believe Craig will correct me if I'm wrong the new section there which will announce their availability and so keep your eyes on that space what we would like you to do is to review the interfaces against your text to tell us you know where we've not gone far enough or things that we're missing or or actually whether we've done a good job and though you're quite happy with them that's also very valuable information and we'd like you to send us feedback there is the an email address that you can use that will come directly through to us in engineering and we will be monitoring that very carefully so be gentle with us we will be continuing to update the the both actually the the header files for the containing the interfaces and the specifications of the interfaces and the implementation behind it so you should track the updates for this and make sure that they are going in the right direction and ultimately when we actually have the implementations we would like to port your case to use these interfaces and then give us your feedback on your experiences ultimately what we want to do in the release after Panther is to actually have these interfaces in place so we're very concerned that we get this right and we'd like you to work with us work with Apple to make this a success for everyone I mean for a success for us so that we end up with a kernel that we can develop in and make progress in and support future configurations and hardware and future functionality and one and make it a success for you that you can implement your cakes in a much more reliable and predictable manner and a success for our user base where they now actually have much more sensible things happening when when the kernel moves on and your kext hasn't so with that like to just wrap up here are some other sessions that you're where it could be interested in some of which have already passed the eye which makes them sort of somewhat moot oh you have them on the DVD sorry so session 100 the i/o kid kernel extension programming this actually was very interesting about how you deal with multi-threaded environments and and real-time priority environments the open source of apple session the Bluetooth update all these would have passed the USB update and the firewire in depth the darwin update was yesterday and the one today in this afternoon firewire and USB that's a feedback session which i encourage you to attend so Craig Keithley is the person that you need to talk to if you're having trouble with this like you can't find the downloads and because he's the only person that will know where they are we give them to him and then he puts them somewhere and don't forget the the KPI - feedback at Apple comm mailing list so we have some URLs that you can refer to sorry this is not URL so the documentation you can refer to inside the RS 10 kernel kernel programming these are all things on the developer website sorry ADC website I locate fundamentals device drivers API reference kernel extensions API reference and these things are areas where you could expect to that we will add to an extent quite considerably as we go through this process you