WWDC2001 Session 206

Transcript

Kind: captions Language: en good afternoon and welcome to the fire wire in-depth session yesterday in the fire wire overview session we reviewed the Macintosh firewire hardware as well as demonstrated the fire wire software stack on Mac OS 10 today we'd like to go into some into more details regarding fire wire driver development for Mac OS 10 so we can see a lot of exciting firewire devices for the Macintosh platform with that said I'd like to turn it over to Erik Anderson engineering manager for the firewire software development team thank you Greg you know this is a USB device I just meant I'm not familiar with it okay yesterday we talked to length about just all things firewire that we have it on all of our products all that the great devices that you guys have made 1394 be where we're going and we told you that Mac OS 10 has lots of good firewire services so today we're gonna talk in depth about all of those firewire services on Mac OS 10 in particular the message I want to give all of you is that we are providing the tools you need to develop drivers applications plug-ins for firewire for Mac OS 10 and we'll spend a lot of time going through how that works in particular we'll have some in-depth discussion of how driver loading works and how driver matching is done of course it's very important to have your driver match your device otherwise what's the point will tell you where to find the SDK it's right there on the slide it'll be on the slide at the end also you don't have to scramble to write that down and we'll talk about source there's the URL for darwin much of the firewire family is in open source we've already started to receive feedback from some of our developers bug fixes comments that's terrific that's exactly how it's supposed to work now please keep that up okay the firewire API in Mac OS 10 is very similar to what's in Mac OS 9 because you need to do the same things it's been changed mechanically to fit with an i/o kit C++ but all the concepts are basically the same we have asynchronous isochronous services for sending and receiving packets it's based on forming a command and then sending it it's just done in an i/o kit way yes ah cron is transport in particular use is the same DCL mechanism that we used in Mac OS 9 if you have existing DC LS it should be very easy to adapt them to work with Mac OS 10 we have the same SBP to service layer in fact it was ported over directly this makes it easier to write drivers for devices like disks cameras printers scanners that use the SPP 2 protocol has all the same features unlimited logical units unlimited orbs and it's not tied to storage it's an all-purpose SBP 2 interface finally we have something new in Mac OS 10 because it didn't really apply in Mac OS 9 and that's a user client more properly known as a device interface this allows you to talk to your firewire devices from the application space which is much easier than writing code to go inside the kernel I'll talk about that later specifically we have user clients for both SB p2 and for just plain generic firewire and you can use those interchangeably you can use them both at once we have an SDK available with extensive sample code shows how to write in user space there's an SP p2 cocoa application there's command line applications a bunch of good stuff in there and significantly not only is this SDK now available but it's available for free public download to anybody you don't need to have access to Apple's developer relations program like was necessary with Mac OS 9 for many years so we're doing everything we can to get this out and make it available to you now let's talk in more detail about what's in there and how it works io firewire family is the core firewire services in Mac OS 10 its job is basically the same as what firewire support did in Mac OS 9 it's a central point of communication for all things firewire if you have multiple devices multiple drivers multiple applications they all want to communicate on a single firewire bus the firewire families job is to let them all do that at the same time without interfering with each other so it's a multiplexing point in Mac OS 10 the firewire family is implemented as a dynamically loadable kernel extension also known as a kext it will be loaded whenever there's a firewire bus that needs this software service there's three main parts to the core io firewire family dot text is the firewire services and there are two hardware drivers for the two kinds of firewire interface that we have shipped in our products apple links text is a driver for the older PCI links interface that was used in the blue and white g3 Apple FW ohci dot text is the driver for the industry standard 1394 open host controller interface that we ship in all of our products today in Mac OS 9 these two drivers were bundled together into the file firewire enabler in Mac OS tend to fit within the way that i/o kit loads drivers they're present as independent texts within the extensions folder we have some additional firewire services they come along as part of the standard installation io firewire DV is the standard device driver for DV cameras very similar to what we had in Mac OS 9 it's also a text I'll talk more about this later it may not really belong in the kernel but that's where it is now io firewire SBP to dot text is the service layer that provides the SPP to API in Mac OS 9 this was simply built in to firewire support in Mac OS tend to be consistent with the way that I okay it works it's provided as a separate text but it will load whenever an SP p2 devices around and provide you with the API to allow you to talk to that device finally as I mentioned we have user clients or device interfaces for both ordinary firewire and for SP p2 in particular to make all of these services available out in user land to minimize your need to write code in the kernel this picture shows where firewire fits in the grander scheme of Mac OS 10 down at the bottom you can see that drivers for firewire exist at the very bottom of the kernel within the i/o kit framework that's where IO firewire family is located and also the ohci or Lynx drivers depending on what hardware you have in your system the figure shows that above them is the BSD layer where you find things like the file system some kinds of firewire drivers will go up to that layer for example a mass storage driver goes to the file system because it provides a block storage device on which the file system actually implements directories and structures to store your files but other kinds of driver may bypass the bsd system as shown by this path over here to the right for example the DV driver goes straight to QuickTime which is an application level service so BSD really isn't involved in the DV driver also up on top I've shown carbon and cocoa because these are places that using the user clients you can access firewire services so you don't need to go down in the very bottom of the kernel you can write up in application space now I'm going to show in much more detail what elements are in the stack of fire wire services and how they get built up when a device is plugged in so that you'll find out where your driver exists within all of these layers of software everything begins with an IO PCI device the PCI family will have discovered a firewire interface of some kind probably on a PCI card built-in or on a card bus card and we'll create an IO PCI device object corresponding to it in IO kit the information in that object matches to Apple in this case we'll use the example of open HCI it matches to Apple firewire ohci which is a subclass of i/o firewire link iya firewire link has all of the functions that would be needed for any firewire interface Apple firewire ohci has specific Hardware control for the open HCI it's DMA engines for example are quite different from PCI links those two are loaded as one as a unit that will provide the device driver layer service for actually controlling the firewire hardware in response to having those loaded the next layer up is instantiated IO firewire controller which is a subclass of IO firewire bus this is where the family exists all of the family services are provided in this layer and it's invoked when there's actual Hardware for it to provide services for pushing IO firewire controller now down to the bottom of the picture will keep building up from where we were the family will scan the bus looking for devices that we might load drivers for for every device on the bus that at least has a configuration ROM containing at least a bus info block which is where the gooood or serial number is located we will create an IO FireWire device this corresponds to a device with a note ID that's out there on the bus it's actually responding to our request to read the configure on IO FireWire device itself is a subclass of IO firewire nub which is just a more general object for talking to firewire devices the IO FireWire device layer will scan the config ROM looking for unit directories in a FireWire device a unit directory publishes information about what that device does a disk drive has an SB p2 unit directory that says it speaks the SBP to protocol within there are further details about the fact that it's a disk drive or a DVD Ram or some other kind of device a DV camcorder has a unit directory that says it speaks the AVC command set and then there's further information within about exactly what kind of device it is the i/o FireWire device layers job is to scan the config ROM finding hopefully at least one maybe more unit directories and it will create this i/o firewire unit object which itself is also a subclass of i/o firewire nub iya firewire unit actually gives us the first hint about what this device really does so IO firewire unit further scans the config ROM and puts information in the i/o registry that's used to match a driver to this device pushing i/o firewire unit down to the bottom let me show the example of how things load for a disk drive from the unit directory we learn that the device is SB p2 it has a spec ID and software version that indicate the SBP 2 protocol consequently the i/o firewire SBP to target layer gets loaded this is the general service layer for an SB p2 device it will further scan the configuration ROM to discover SBP 2 logical units within that device for each logical unit that it finds it will create io firewire SP p21 LUN being short for logical unit finally the Lund will match against a particular driver for the actual device that you've plugged in in the case of a hard drive Apple provides a standard built in driver if you use Mac OS 9 and you remember the API call FW get local FW reference ID from FW reference ID you'll love this Apple firewire mass-storage drivers which is a subclass of i/o firewire serial bus protocol transport together these are apples standard driver for mass storage devices it covers hard drives magneto-optical cd-rom various other standard kinds of devices this puzzle piece architecture you probably recognize this from the USB and the storage presentations the puzzle piece edge that's sticking out the right hand side of Apple firewire Mass Storage drivers indicates that this is a layer that you might want to subclass if you have your own device that has vendor unique functionality that makes it better than somebody else's you don't have to write an entire new driver for your device you can start with apple firewire match Mass Storage drivers or perhaps just IO firewire serial bus protocol transport and subclass the unique functionality of your device at this level suppose your device isn't in the kernel suppose you want to communicate to it from user space if you went to the i/o kit summary you've probably heard that we recommend avoiding writing drivers in the kernel if you possibly can it's much easier to debug things in user space than in the kernel so we provide a user client which is a piece of software that can bridge the user kernel gap going back down to i/o FireWire device and die or firewire unit if you want to talk to a device from user space then IO firewire user client will be loaded within the kernel as the driver for a device this is basically just a bunch of glue that knows how to talk up into application space pushing user client down to the bottom now we reach the user kernel boundary above here we have IO firewire lib this is another piece provided by Apple it's the counterpart to i/o firewire user client IO firewire lib can be used by a CF plug-in that you provide the CF plug-in is written in user space and runs in an application context and can talk to i/o firewire lib to communicate with a FireWire device typically it would be loaded by an application as an example if you have a firewire scanner your application might be something like Photoshop your CF plug-in might be a plug-in for the particular kind of scanner that was found so this gives you a flexible architecture for dealing with multiple kinds of device perhaps multiple applications without rewriting a lot of code over and over again it's not shown here on the slide but if you had some really unique FireWire device that was only ever going to talk to a single application like maybe some kind of firewire salad shooter or something you could connect this up directly to i/o firewire live you don't have to use the plug-in architecture but most people want to write something that's flexible that can talk to multiple applications or multiple devices use the plug-in architecture for that and again this is the area where you could write software you could write the application you could write the plugins the rest below is provided by Apple now let's talk about more details about the individual objects that you saw as we built up the stack io firewire controller is the heart of the firewire family this is where all the logic exists to manage a firewire interface as I mentioned before a single firewire interface may support multiple devices multiple applications multiple protocols all going through the same hardware interface io firewire controller provides the services to actually talk to that hardware to multiplex the different requests it also provides the bus management services so some of the things that are common that have to be shared by all drivers address space management some kinds of firewire drivers will allocate firewire address space that's a range of memory in the Macintosh that can be addressed over firewire drivers for DV and SBP don't need to do this by themselves typically but if you design your own protocol or if you're doing a shared memory kind of application you might allocate some firewire address space so that other devices on the bus can read and write memory in the Macintosh that address space is a shared resource so it's handed out by i/o firewire controller packet transmission and reception all flows through here when a packet comes into the Macintosh at this layer we can look at it figure out who it's for hand it to one of the appropriate drivers that's loaded on the system likewise when software wants to transmit packets this is delay or whether get queued up and transmitted one by one on the firewire bus if you want to write a protocol driver io firewire controller will be the provider for your driver a protocol driver is software that loads once for each firewire bus as opposed to an ordinary firewire driver which loads once for each instance of your device on the bus a protocol driver might be used if you're speaking a protocol like tcp/ip or perhaps M LAN where you really just want one driver on the Mac not several talking to each firewire bus and as I mentioned earlier Apple links and Apple fwo HCI are subclasses of i/o firewire controller that know how to talk to the specific DMA controllers in the products that we've shipped I mentioned i/o FireWire device that this is created for any device on the bus where we are able to read at least the bus information block from the config ROM there will be one of these per device IO FireWire device keeps track of the node ID in a device which may change from time to time due to dynamic reconfiguration of the bus IO FireWire device also discovers the vendor ID which is in the root directory and publishes this in the IO registry so that you can use it for driver matching but the main job for IO FireWire device is to scan the configuration ROM on the device that it is attached to looking for unit directories and when it finds them published those unit directories in the IO registry so that driver loading can continue IO firewire unit this is what's created by IO FireWire device for each unit directory discovered in the config ROM there's one i/o firewire unit the unit will find and publish the unit speck ID unit software version and again the vendor ID in the i/o registry so that this information can be used for continued driver matching an ordinary FireWire device driver in the kernel will have IO firewire unit as its provider both IO firewire driver and IO firewire unit I'm sorry IO FireWire device and IO firewire unit derived from IO firewire nub if you want to find out how these work you should definitely look in the nub which is where a lot of the activity takes place now what kinds of things do we put in the i/o registry there are two service planes that firewire uses there's the primary i/o kit service plane that's what you get by default when you run io registry Explorer you can find the i/o firewire controller in there hanging off of the corresponding PCI node you can find i/o firewire device if you have any devices on your bus and if you do you can probably also find i/o firewire unit there's also an i/o firewire plane created by firewire in the registry this is where we store some firewire specific information about bus topology and you can find firewire controller and FireWire device objects in there okay now I'd like to give a demonstration of some of the things that we've included in our software development kit so if I can have demo one up on the screen thank you I can't see you all really well but I'd like to see a show of hands how many people have downloaded installed and used one of our firewire SDKs for Mac OS 10 can you raise your hands so most of you haven't but thank you for everyone who did what I'd like to show you now is some of what we have in the SDK we have spent a lot of time trying to provide a foolproof straight forward SDK with sample code with examples precompiled binaries step-by-step instructions that you just can't fail let me show you how easy this is to use I have a CD here with the firewire SDK on it you would probably download this from our website I'm simply going to drag it into my home directory here it is i/o firewire SDK seven dot sit this is the latest one simply double-click on the archive file and it will expand and now we have a standard Mac os10 installer for those of you who started with firewire SDK number one you may recall some very tedious steps for how to install software if you went through those you probably learned some useful things about how UNIX works and how we store texts but we've made it quite a bit easier now you can simply use the Installer pick a drive on which you'd like to install choose a directory within that drive such as Apple is the local user here we'll put it in the Documents folder select install and in just a few seconds the SDK will be installed and you'll be ready to go there was a lot easier than going through that script we used to have so the SDK is now in My Documents folder as firewire SDK here are some of the things in here readme text and readme dot RTF these are exactly the same file open this one if you're running in classic or Mac OS 9 open this one if you're running in Mac OS 10 this has step-by-step instructions for how to walk you through installing building running everything in the SDK you can't fail if you just follow them line by line it's very straightforward we've tried it over and over again let me show you some of the highlights of what's in here let's start in the tools folder IO registry explorer this is a standard Mac OS 10 developer tool it's provided in the standard developer install we've made a very minor change that makes it a little more convenient to use on fire wire I'll run this and show you what's changed and also show you how to navigate around and find fire wire objects actually before I do that I'm gonna turn on this fire wire camera so that we have somebody to talk to within the registry Explorer you will have to dig a little ways to find FireWire registry Explorer is very similar to display name registry from Mac OS 9 except it's organized more like Mac OS tens finder view that has these rows of columns power Mac 3/4 is the actual hardware we're running on if we look inside the platform expert we find various kinds of device this PCI bus I just happened to know has firewire on it you might try the other two first if you can't find it here's firewire over here firewire at E and the system since it's rg4 has an open HDI in it starting here you may have spotted what we changed in this particular version of registry Explorer these numbers that are shown in decimal are also shown in hex it's very little thing but here's where it really starts to matter if you go into our io firewire controller and look at your node ID six five four seven three I don't know if that's right but FFC one is clearly node one on the firewire bus so having hex in here it should be helpful to you so these are the things that you saw in the stack that built up Apple fw ohci which is a io firewire controller it has discovered this camera on the bus that created an i/o FireWire device within the device you can see things like the vendor name the model because they provided a string in there for us the note ID this device has a unit directory so i/o firewire unit was created the user client also gets tacked on at this point here in the unit you can see the unit spec ID a 0 2 D which specifies the 1394 trade association and the unit software version 10,000 one hex this specifies the AVC command set which is reasonable because this is a DV camcorder and in fact we loaded the i/o f w DV driver against this device so you can see that IO registry provides information similar to display name registry and it has the details that you'll need to figure out what we thought of your device what we thought it's unit contained its vendor was so that you can find the information to enter in project builder for matching your device so your driver can load correctly against your device one of the other tools provided in the SDK is hack TV this is just a standard QuickTime sample code it's a little application that will receive video from the camera is actually two files provided hack TV structure dot sketch is a really simple picture if you attended our kitchen in Tokyo I think we'll even do this on the fly and so we put this in the SDK it just shows the layers of things inside hack TV how all the parts are working together hack TV itself will open up a connection to the camera and display video from it so here you can see the DVS coming in just like the iMovie demo that we showed yesterday except this is running in just a simple standard QuickTime sample code Carbon vid out app is a similar application that can take a DV file and export it back to a camera and you can watch it play yet full 30 frames per second on the screen on the camera UUID generator is a small tool that you may need to use you can read about the details when you get to that backing up to the top of the sdk this directory source contains full source code to the io firewire family and io firewire SBP - including all of the user clients so you can find out exactly what we did a few of you have even found bugs and reported those we're fixing all that all the other goodies are here in examples there's a number of programs sample code to show you how to use firewire and Mac os10 let's start with SBP - sample project let me show you just how easy it is to compile build and run our sample code for SBP - this is a cocoa application I'll open it up in project builder and build it this application talks to an arbitrary SBP - device to build the application all you do is click on the hammer in project builder wait a moment while it compiles everything you can see there's a fair amount of stuff in here this application will talk to this firewire disk drive and will serve as a sample or how to gain access to your device how to form an orb and send it to your device how to get data back and it shows how to do it all in project builder with cocoa as well it'll take just a moment to build sorry the question was do you have code warrior sample code and we don't have any at this time we'd certainly like to add that however if one of you has already figured that out we'd be happy to throw it in the SDK if you just send it to us otherwise we'll take care of that ignore that build warning and it's done we've built the SPP to sample and you can find it here in this directory that was created called build here's an application text and plug-in I'm gonna skip a few steps I've already installed these in the system folders so that they'll load now nothing's here because I didn't actually plug in the drive so the app has found an sp2 device in fact it found the IO firewire SBP to one object that I told you about earlier corresponding to the single logical unit that's present in a disk drive we will select that and we get a window that allows us to log into the device which I will do and the device spins up in response to that and now that it's spinning we can press this button to read a block from the device this simply reads block zero and dumps it out completely raw in this window khoka makes this really easy to do nothing in here was specific to disk drive except actually the read block zero command so you can use this application and code as a starting point for talking to just about any kind of SB p2 device there's other things in the SDK I'm gonna go into the pre-built binaries folder but all of this is provided a source code as well FW util is a very simple command line program that can read quad let's out of your high wire device just to show you how to start talking to a device io firewire lib demo is similar except it shows the entire config realm of your device firewire packet queue test can send packets between two Macintosh systems notifier provides you with some sample code for how to get notification when things happen on the bus like a device appearing read test and write tests are isochronous sample code that use the DV driver to capture and export DV it does it right from the command line as opposed to hack TV which does it in a nice GUI application so let's take a look at some of these oops trust you can all see this so using the terminal I'm going to run some of the programs that are provided in the pre-built binaries folder we'll start with FW util this is a really simple program the device it's talking to I believe is this hard drive might be the camera you can use commands similar to what was in Firebug I'm going to read a quad lit out of the configuration ROM this particular quad lit is the first 32 bits of the serial number of the device here's the next 32 bits this looks like it's the disk drive because I know this is the camera 85 is canons vendor ID so we've read the serial number out of this device using this command line tool not terribly useful but all the source code is provided so that you can adapt to this into something that your customers would actually use IO firewire lib demo I mentioned earlier beats the entire configure I'm all at once and dumps it out in hex it's extremely easy to use there you can see in fact it's dumped them out for both devices on the firewire bus the camera and the disk drive one of them seems to have a lot of empty space but all of the data is here so as you can see we have a lot of stuff in the SDK it's all completely ready to use it's been pre compiled so you can just run it building it in project builder is just a single click some of the command-line tools are built by compiling them in terminal but there are step by step there being one step instructions in the SDK for how to do that okay that's all the highlights for things in the SDK hopefully what you'll take away from this is that it's all ready to use we believe you can ship you can develop drivers applications user space code and ship it to customers for firewire with what we've got here of course we're working on bringing you more but we've got quite a bit to offer in this SDK okay let's go back to the slides I think I went too far nope so I'd like to continue talking about some of the objects that are in Mac OS tens firewire services that you will be using when you write code for these devices I OFW command is the sort of all-purpose object for sending commands to a FireWire device it's similar to the firewire command object in Mac OS 9 except there's again mechanical changes to fit within C++ and fit with an i/o kit the i/o fw command object provides all of the services you need for making synchronous or asynchronous commands for handling callbacks when things are finished it's all handled in a common way through this class there are a number of derived classes for sending particular kinds of commands to a device in particular I OFW async command handles all of your read write and lock operations io fw bus command handles commands that apply to the firewire bus such as allocating local address space or other bus resources the class IO fwi sock channel that corresponds to a channel command object in mac os9 an isochronous channel object exists corresponding to one active isochronous channel on the firewire bus the purpose for the existence of the channel is to keep track of the actual resources the bandwidth and the channel number across bus resets it also serves as a common reference point for everyone who's doing something sending or receiving on that isochronous channel so associated with it RI OFW I saw port class objects a port corresponds to an actual point of talking or listening on a channel if a channel is going to do anything interesting it probably has at least one listening port and exactly one talking port you can subclass I OFW I sock port to provide the mechanisms that are specific to your device before starting and stopping communication on a channel when a channel is started each of its ports will be called so that it can do port specific things to start operating on the channel the transmitter could start a DCL program to send data the receiver might program registers in a device that cause it to pick up the data and do something useful with it similarly i OFW local I sock port is a port on a channel that is corresponding to Hardware on the Macintosh generally if you have a channel you will have one local I sock port on it unless you're acting as a manager for two other devices who think they're talking to each other on the bus a local port corresponds or has a DCL program attached to it this is the same service that we had in Mac OS 9 DCL stands for data stream control language and it's an abstract programming language where you build a structure in memory describing on a packet by packet basis how you're going to send or receive isochronous data we take that DCL program and compile it into a DMA program that runs on the kind of hardware that we have in the Mac whether it's open HCI or PCI links so your driver needs no knowledge of the hardware specifics the DCL programs in Mac os10 used the same op codes and same structure as mac os9 it should be very easy to adapt an existing DCL to work in mac OS 10 okay more about user clients formerly formally this is called the device interface but everyone calls it a user client so I will to a user client as I said before is a layer of software that allows you to talk to firewire devices from application space there's many good reasons for doing this in order to hook up to your device you may need to put a stub text in the kernel this could be as simple as an empty text with a little bit of XML to match your device in order to give you control over your device for example if you wanted to talk to a device that also matched against apple's standard disk driver you might create a stub text that gets a higher probe score or a tighter match that would enable you to win over our disk driver and then talk to your device from user space we provide complete access to the firewire services in the kernel through the user client so if your device doesn't have to be in the kernel because of OS specific reasons put it in user space some drivers simply have to go in the kernel if you have a mass storage device that's going to mount a filesystem that has to be in the kernel but if you have some kind of printer scanner digital video device all of those can go up in user space isochronous services will be available very soon in the user client they're not yet in the SDK but that's our number one thing that we're working on right now probably in the next week or two we will post another SDK with isochronous services for the user client the i/o firewire SBP - family I talked about before it's the service layer it's ported almost directly from mac os9 so it's very similar in how it works although it's been cleaned up to fit properly an i/o kit so there's no strange legacy mac os9 issues this layer is used by the apple firewire disk driver last year we had a monolithic demonstration disk driver to show that it could be done but all of the mass storage layer SPP - had been rolled up into one big mess and made a driver it worked but it was not sustainable so we've broken that up into discrete layers this is what's in Mac OS 10 today and it's what's used by our standard driver I mentioned before i/o firewire serial bus protocol transport text and apple firewire mass storage drivers text that's the Apple software that provides a standard driver you can subclass that or replace it if you need to provide a driver for your own device one particular function of i/o firewire SBP

• is it knows how to read the config ROM

of an SP p2 device and find SBP - specific information to use for driver matching SBP two devices publish a command set a command set spec ID logical units various other information that is specific to SBB - you wouldn't find it in a camcorder so io firewire SP p2 is the layer that digs that out publishes it in the i/o registry and then allows i/o kit to perform more precise device matching using that information we have a user client before SBP - this gives you all of the SPP - services that are available in the kernel and it makes them available in user space if you want to write a driver for a FireWire printer firewire scanner firewire still camera you'll probably be using the SVP - user client in application space you can use this by itself or you can use it in combination with the ordinary firewire user client if you have some device that has additional functions outside of SBP - you can talk to them with normal firewire commands using the normal firewire user client so you can use one or the other or both depending on the needs of your device IO firewire DV this is the standard DVD device driver that we provide it provides services very similar to what was in Mac OS 9 it is a device driver for DV cameras it can transmit and receive frame accurate 30 frames per second DV it supports normal DV and the new SDL mode that is present in that Canon camera I showed you earlier presently IO firewire DV lives in the kernel it lives there because we don't have the isochronous API out and user space yet so putting it in the kernel worked we would like to move that out to user space and we're going to try to do that we certainly recommend if you're developing an isochronous driver try to do it in user space if you want to use io firewire DV you can access it through quick time using the sequence grabber just like you would in Mac OS 9 and there's a lot of sample code in the SDK as I showed you earlier that can get you started on how to do that ok so what do we have that's new we've actually gotten quite a lot done since last year when we told you about firewire and Mac OS 10 for the first time this year in the shipping version of Mac OS 10 we have full support for open HCI last year we were really working best on the blue and white g3 with the old PCI links now we fully support all the hardware the SPP to service layer and the standard apple disk driver are completely new since last year they're very full-featured the user client for firewire and the SPP to user client are also all new we now have a standard DVD driver and quicktime component as you may have seen yesterday in the intro to firewire iMovie is running just fine on Mac OS 10 we couldn't show any kind of DV at all last year firewire booting there's not a whole lot to say here you can boot from firewire devices in Mac OS 10 just go into the Preferences pick a FireWire device and boot from it SDKs we have published a bunch of firewire SDKs from Mac OS 10 already in a major change from what we were doing on Mac OS 9 we've made these free and completely available anyone can download them just go to our website here's what we're going to be working on for the future as I mentioned the isochronous services in the user client aren't quite done yet there was no corresponding service in mac os9 this is something new we're making good progress on it we expect to have an SDK out within a week or two that you can try in particular we intend to provide a sample code for ad cam camera device driver dkm is a format for raw video on firewire it's not compressed like the commercial consumer DV cameras it's just raw VGA or similar kinds of format sent over firewire it uses much more bandwidth and it's the number one application other than DV for isochronous on firewire so we plan to provide sample code for a driver for that kind of camera we have more sample code in general more documentation we've added header doc more tools we also have a bunch of bug fixes coming in the next SDK here's some general areas that we're gonna work on over the next year in 1390 4.3 also known as the peer to peer data transport this is a protocol layer that sits on top of SB p2 this was invented by the printer community it's suitable for printers and may be useful for other kinds of devices as well it provides multiple streams or pipes of communication over a single SBB - connection if you have a device I don't believe there's any shipping today but if you have a device that uses this protocol you could write software for it with the SBP - user client but part of what you invent there would be common to any PPD T device so we will provide a standard layer to make that even easier to do I Triple E 1212 R is a revision to the specification that says how config roms are laid out in particular it contains a new service called instance directories this is a slightly different way to describe the functions in your device as opposed to the unit directory that we use today many of the consumer electronics vendors felt it would be better to describe a device based on its function rather than based on its protocol so an instance directory tells you what kind of functions a device has we plan to add support for that since devices are starting to appear that have this kind of data in their config ROM this would give you an alternate way of loading device drivers for device the purpose of instance directories is to be a better way to discover functions so it's natural to make it available for driver matching and loading finally as I talked about yesterday at the intro section we're going to be spending a lot of time working on 1394 B or more precisely our Hardware folks are going to be spending a lot of time working on 1394 be almost nothing changed in software so we'll make a few little touch-ups and then ship that out to you in conclusion for Mac OS 10 we have extensive fire wire services we believe it's really the equal of what we had in Mac OS 9 everything is there for you to start writing drivers today please pick up the SDK here's the URL again that provides information for both the SDK and our mailing list this is a public mailing list anybody can subscribe the exact details are at this URL all we ask is that if you do have confidential information maybe we've sent you a seed unit or you're working on some new product that nobody knows about please don't talk about it on the mailing list you can ask general questions sometimes people do ask secret questions and I remove the secret information and post the response on the mailing list the response so far has been quite good many of you have been answering each other's questions on the mailing list which is great we do what we can to answer questions as well so if you're not participating please sign up and please participate in that mailing list finally as I said much of our source code is open source it's in Darwin it's also all provided in our SDK if you do find a bug or you find something that could be done better a feature you'd like to add let us know about it use the standard Darwin mechanism to submit your change we've already picked up and incorporated some changes that you sent in related sessions here at dub dub DC yesterday there was a very good presentation on storage drivers in IO kit this is information that you'd need if you're writing or sub classing drivers for storage devices on firewire if you missed the presentation yesterday I believe there will be a DVD series available from dub dub DC so you can catch it there tomorrow at the same time two o'clock we will have our feedback form combined firewire and USB that's in room J one down at the complete opposite end of the Convention Center from where we were yesterday that is like open mic night you can just come and say whatever you want tell us what you like what you don't like ask questions it's completely open we just want your feedback for whether or not we're meeting your needs in Mac OS 10 finally tomorrow night starting at 7:00 back at Apple in the piano bar I think it says 6:00 there we will have a firewire and USB plug fest so there's a big apple party at the Apple Campus tomorrow come on by the piano bar it's in building 4 right out front by the parking lot that's where we'll be bringing your firewire device or your USB device you can hang out with firewire engineers if you do have bugs we will have all the engineers there with the source code we'll try to look at things as well as we can between taking big jokes and beer you