Whenever a transition occurs, like we had one about two years ago in terms of I/O from USB to USB and FireWire, that always causes a heartache for customers, for developers, because you've got to do some work for Apple because you have to do all this work to get it out there. That also gives rise to great opportunities. We think that the people who really grab this on are the ones that are eventually successful.

So here again, Apple is presenting you with another opportunity to write drivers for Mac OS X, because all the customers that now start upgrading to Mac OS X in the next year are going to need peripherals with the appropriate drivers to make sure that it works. And I think the people, the developers that really give them these drivers will be the one eventually that come up on top. So we are presenting you with an opportunity here.

To get into details of Mac OS X and writing drivers, by the way, this session is entirely devoted to writing X drivers, I'd like to welcome William Guland. William is the tech lead for Mac OS X, and in fact he's the one who's been doing all this hard work to make sure that X FireWire in DP4 works really well. William? Good afternoon.

I'm going to be talking to you about, as Jai said, how to write drivers for OS X, FireWire drivers. I also want to go over briefly what is in DP4, what's in the CD that you have now, what will be in the OS X public beta when we release that, So therefore, I'll be talking to you a bit about the things that we haven't done yet, the things that aren't in DP4, and give you some pointers to the kind of things that might change in the future.

I really want to make sure that you have a basic idea of how you're going to start writing FireWire drivers in Mac OS X. I'm going to explain briefly how driver matching works, so we can make sure that your driver gets loaded for your device, not for someone else's device, and can start running and do the right thing.

I'm also showing you here where you'll be able to find the SDK. That isn't actually-- we don't have an SDK ready for you yet. But if you check this URL, we'll be sure to point out where you can get it. And of course, really important, the FireWire code is open source. It's part of Darwin. If you're going to write a device driver, please sign up for Darwin. Get the source. Use the source, Luke. It's a lot easier if you can see how we're doing things, see how you should do things as well.

Okay, so how do things work? The FireWire drivers in OS X, they use I/OKit. I based the code on the OS 9 architecture, basically took all the source code over to 10 and converted it to fit into I/O Kit, converted it to C++, which made a lot of things much easier for me.

In DP4, it's implemented as a set of kernel extensions that are loaded up when a driver needs the FireWire services. There's three main kernel extensions for FireWire in DP4. is the IO FireWire family .txt. This is the core of FireWire. It's the code that provides all the basic services for FireWire, hardware independent for everything. Then we have two drivers for the two different types of FireWire controller chip that we've used at Apple in our various computers.

AppleLynx.txt is the driver for the Texas Instruments PCI Lynx controller chip. That's the controller chip that's used in the blue and white G3, and also in the PCI Apple card that we also, I think, still sell. Kind of obsolete, but still available, I think. Finally, Apple FW-OHCI is the driver for the OHCI FireWire standard. All our current machines that have FireWire built in, they're all using versions of this open standard. So this driver is for all the current machines.

Okay, so what's in DP4? Driver matching and loading is all done now for FireWire devices. So if you have a driver for your device, and you've written it correctly, which you probably don't know how to do yet, but I hope you'll be figuring it out soon, DP4 can load drivers for the right devices, get them running.

The core services for FireWire are pretty nearly complete. You can do most of the things you need to do with FireWire, of sending packets, receiving packets, allocating address spaces, looking at what devices are on the bus, finding out how fast things are, what the bus topology is, all that kind of useful stuff that you need to do.

The Apple Lynx driver is complete. It handles everything that I believe it needs to handle. It's probably got some bugs, but we'll sort those out. The OXCI controller is not so far along. We'll start on it a bit later. It's newer machines. The asynchronous packet handling is all complete, but the isochronous packet handling isn't done yet, which means you can't do DV development, for example, using an OXCI controller. So you need to get a Lynx card, perhaps, for doing that.

We also threw in a prototype FireWire disk driver that we wrote to make sure that the core services have all been the right thing, and so we had all the interaction with I/O Kit and the file system all sorted out and done correctly. We're not quite sure whether we should be shipping a generic disk driver in the future.

We put in for DP4 because, well, we didn't have any other drivers, so it was a good one to have. So if you have opinions about that, perhaps you can give feedback to jai@[email protected] whether we should have a drive-- a driver or just do what we did in OS 9 of leaving the driver for each disk manufacturer to do themselves based on code we provided them.

The last thing in DP4 is, well, not in DP4. We don't have any documentation yet written for FireWire in DP4 for 10. We don't even have very good header documentation yet. So that's kind of something that, bear in mind, again, Sign up for Darwin, get the source, and you can figure out what we're doing.

For the public beta, of course, we'll be adding most of the things that you'd expect for a complete implementation. We'll be splitting apart the disk driver we wrote into the SBP-2 services that's generic for all SBP devices and a separate hard disk driver, or we'll leave it out completely depending on how we decide to do that. Again, that's something that OS 9 has, you have separate SBP-2 services for all the devices that use that standard.

We also have to add the FCP services that are used by DV camcorders and MLan, that kind of stuff. will be, of course, providing a DV driver, just as we do in Mac OS 9. and also protocol driver support. When I first started working on FireWire, I wasn't quite sure what protocol drivers were.

So I didn't implement them at first. But they're pretty neat. The thing you have to remember about FireWire is that FireWire is a bus. It's peer-to-peer. You can connect several Macintoshes together, and they can talk to each other. Protocol driver is a way of setting things up so each Mac knows what services other Macs are providing because they've had a driver loaded to match and talk to.

I'm also going to be improving the, I should really say, config ROM services. I left them as CSR because that's what they're called in the current source code. Services to read the configuration ROM from a device, services to add stuff to the Macintosh config ROM for other devices to read so that they know what services the Mac can do for them. We'll also be adding booting from FireWire disk drives. That's one of the things that isn't in 10. We have a disk driver, but we can't boot from it. And we'll do an SDK. We'll document it. Honest.

Looking a bit beyond the public beta, timeline getting a bit vaguer now, we want to provide AVC services in the same way that we do for SBP-2, because in the past, there have only been camcorders that needed the AVC protocol. In the future, Camcorders again still, but also MLan audio devices and AV hard disks. Now all those three different kind of devices, they all are based on the AVC standards, so we want to provide services to do that that you can then build on with other devices.

We're going to provide MLan support, of course. If you saw Will's demo yesterday, that looks pretty exciting. That huge bandwidth available for audio, hundreds of channels, the pro guys, and it's just great for them, and it's also going to be nice for home theater stuff. Just less cables. It's great.

Power Management also is not in DB4 and probably won't be in the public beta either. Really, that's most important for PowerBooks, but we like to control power on all our machines. So, where does FireWire drivers fit into the whole big picture of Mac OS X? Well, there's just a little tiny box down in the bottom corner underneath I/O Kit.

You notice that there's a dotted line that goes across and then up? Separating the Mac kernel and I/O Kit from the rest of the kernel. That little right-hand side, kind of, up the side, implies that an iRakit driver can actually get, provide services straight to applications without having to go through BSD or networking or the file system, if that makes sense for your kind of device, which is often the case for FireWire devices, because a lot of the really fun stuff, camcorders again, cameras, MLan and so on, are the kind of things that and the good old-fashioned Unix isn't really terribly interested in, and the kernel just doesn't want to need to know about it. We're going to put that up into the applications.

So what I want to go through here is show you how iLokit goes through the process of Getting a driver running when your device is connected to the Mac. Initially, when the machine starts up, I/O Kit will look through all the hardware that's on the Mac motherboard, and it'll find a FireWire controller of some kind.

It'll either be The Apple Lynx, I mean sorry, the Lynx PCI controller or the, one of many OHCI controllers. So the IOC matching system will then load either Apple Lynx or OHCI as appropriate. Apple Links and OHCI are subclasses of IO FireWire Controller, which, remember, is the core of the FireWire services system. That itself is subclassed from IO FireWire Bus, which is a very abstract view of FireWire.

So, first thing that happens, you plug your device in. That will cause a bus reset. We'll go and scan the bus, find that there's a device now. And, We, the iCube, then creates a standard object for communicating with FireWire devices, which we call our FireWire device. Pretty logical. It, in turn, will then look at the device, read its config ROM, and see what unit directories are in the ROM. The unit directories are where FireWire devices will be storing information on what kind of device it is, who makes it, all the information that you need.

Now things get a bit more interesting. The IOK matching system now looks at-- The entries in the unit directory figure out what kind of unit it is. And with a bit of luck, it's a device that a driver's been installed for, and at that point, We'll load up your driver, attach it to the FireWire unit, and then your driver can start running, talk to the device, and start its thing.

For example, if it was a hard disk, your driver would then have to tell the I/O Kit file system services that it's a hard disk, it's got partitions and so on, and the file system will then take up to it and start and the reading and writing sectors. I'm not going to go into much detail about how a file system side of I/O Kit works. There's a session tomorrow that will really go into that in great detail.

To plug another device in, of course, we create another FireWire device object to represent that one. Now, again, we look at unit directories and create a FireWire unit object for each directory we find. Perhaps we find two unit directories because it's some kind of multi-functional device. We couldn't actually think of an example of one except for a Macintosh.

A Macintosh, which had several protocol drivers loaded, perhaps an MLan driver, maybe an IP driver, then it would have a unit directory for each of those protocol drivers, and other Macs on the bus, beating that Mac's ROM, would create a unit object for each of those units so that the right device driver can be matched up with each unit. I put one in gray, or dim, because we're going to concentrate on one side.

The appropriate unit driver is found, loaded, starts running. I suppose this is a device that doesn't communicate with the rest of the kernel. Perhaps it's a camcorder, it's a scanner, it's a printer. Something that applications, right at the top, really want to talk to, but the rest of the kernel doesn't want to talk to.

IOCit provides services for applications outside the kernel to get notified of kinds of devices that they're interested in appearing inside the kernel. And when they see that, They can then go and find a Core Foundation plugin to represent that device outside the kernel. The plugin then has to asked the unit driver inside the kernel to create what we call a user client, which is an in-kernel object that provides services to get across the kernel boundary between the plugin outside the kernel and the unit driver inside the kernel.

So I've just highlighted the pieces that you would need to write for two kinds of devices. On the right, something like a hard disk. It's pretty straightforward. You write a device driver inside the kernel, gets loaded. It talks to the file system. And essentially, you have one object to worry about.

If you're doing a device that-- for a device that you'd like to provide direct access, to applications outside the kernel. As things stand in DP4, you need to do a little bit more work. You need to write your-- in kernel device driver, you also need to write a piece of extra code to the user client to cross the kernel boundary.

And you almost certainly want to write a core foundation plug-in outside the kernel for any application that wants to talk to your device to go through. Probably shouldn't directly, you could directly from the application go to the user client inside the kernel, but it's architecturally almost certainly going to be better for you and for everybody to have a plug-in to your device rather than building things into applications.

One thing that we hope to do for the public beta that I didn't mention was make This left-hand side three-stage thing a little easier by providing our own unit driver and user client inside the kernel that you can plug in to say, I want the standard one. I don't do anything. I don't need any special high-performance communication. I can stick with the servers we provide, which should be pretty fast anyway. I think I'll certainly be fine for scanners, printers, probably MLan devices as well, maybe.

Okay, so as I mentioned earlier, the FireWire controller is the heart of the FireWire family. It does most of the hardware-independent work that needs to be done to get FireWire up and running, get your devices going, be able to talk to your devices, know which devices you have, which other devices there are.

bus management. It does address space management inside the Mac. That's where you have-- you want to-- have FireWire addresses inside the Mac that your device can talk to to send status, that kind of thing. Of course, FireWire Controller provides methods for transmitting and receiving packets, both asynchronous and isochronous.

If you're writing a protocol driver where you're making the Mac perform a service for people, other devices on the bus, then your protocol driver will match the FireWire controller, because that's what provides the services it needs to change the, update the Macintosh ROM and allocate address space. As I mentioned earlier, Apple Links and IAFW-OHCI, they're the hardware drivers that access the Macintosh hardware. They're subclasses of IAFW-FireWire controller that implement the actual hardware, register bashing necessary to send packets, receive transmit packets, handle interrupts, all that hardware stuff.

I have a FireWire device, one per device on the bus. This is the object that handles some of the fiddly bits about FireWire that you really don't want to have to bother with. It tracks the node ID of your device with the bus reset, and node IDs of devices can change.

But you still have the same FireWire device to talk to. It'll just internally know that its node ID has changed when it sends and receives packets over the bus. For matching a FireWire device, if your device driver wants to do that, we only provide two very basic pieces of information. The vendor ID of the device, and the GUID, the globally unique ID of the device.

Neither of those really are terribly useful for matching their either, rather general, vendor ID. I mean, every device you make, whatever kind it is, can have the same vendor ID. Or it's incredibly specific. GUID is going to be a driver for that one device in the entire universe, which probably isn't terribly useful.

There could be uses. There was a question in Eric and Jai's presentation yesterday where someone was asking about having 10 Mac installers networked, next together with FireWire, and he had a FireWire hard disk that he wanted to only mount on one Mac. Now, one way of doing that, at least in OS X, might be to use the GUID of the disk drive and have a driver that only matches that one disk drive, and have that driver only on one of the Macintoshes. The others won't match the drive because it's got the wrong GUID.

The Mac that you want to use the drive will match it because it has the right GUID. But that's pretty esoteric, really. The main job of a FireWire device object is to look at the device's ROM, Pick out all unit directories and create and publish IO FireWire units. Feature those unit directories for your own drivers to match on.

FireWire, I/O FireWire unit, said one unit directory and a device ROM. Typically, there will only be one unit directory and a device ROM, but the spec allows for more, and we allow for more. For FireWire Unit, we provide much more useful matching. A driver can match on the unit spec ID, unit software version, and also the render ID and GUID, which we've brought up from the FireWire device. is the provider for most FireWire drivers for devices, since it has the information on what kind of protocol, the unit spec ID and software version that the device can handle.

FireWire device and FireWire unit really are only different in how they are, where they fit in the IOC hierarchy and in the matching information. They both derive from I/O FireWire Nub, which provides methods for all the things you want to do with the device, of sending packets to it, receive packets from it.

So in Iocat, we have what's essentially like the name registry in Mac OS 9, but a lot more sophisticated. and I had fun taking advantage of that for FireWire. The main IOCit service plane, we call it, is the part of the IOCit registry which is used for matching. So all the objects that I create that can be involved in matching are in that part of the HiKit registry. for the matching functions of I/O Kit to work on. So those are I/O FireWire controller for protocol drivers, I/O FireWire device, perhaps for a specific device drivers, I/O FireWire unit for most device drivers.

I also implemented a second plane in the registry, which I use to keep track of the bus topology of FireWire Bus. In other words, which device is connected to which other device physically by the cable. Which is useful for figuring out what speed you can send to if there's a slow device between two fast devices. Then the FireWire plane might be a way to check if that's happening and maybe alert the user if you want to.

Since this is only intended to represent the topology of the network and not the

FireWire device essentially, or the Mac OS itself, and all the other devices that have been found on the bus. Okay, now I'd like to show you the registry in OS X in action. First, I'm going to bring A very useful application that we have in DP4 called the IR Registry Explorer. It's a very simple application that shows you what's in the registry.

When it starts up, it starts up showing the service plane. I'm going to switch the plane-- I'm going to display to the FireWire plane. So that we can see what the bus looks like right now. Now, there's nothing connected to the Mac right now. On the front side, we see what's available. There's the Apple FireWire OCI object, the Mac's own internal hardware.

And then there's four other objects in the registry whose purpose I really don't know. They're always there in each plane. The OHCI driver, you see we have a whole bunch of properties being displayed down here. I'll just move this so you can see a bit better what's going on. We have the node ID of the Macintosh.

tells us it's a number. This application is built with Cocoa, and it was done-- well, it's very simple application. One of the things that we didn't do was show numbers as hex, which probably makes some things a little clearer. We just showed normal decimal representation. I also keep in the registry for people to look at the self-ID packets that that node sent out at the last bus reset, which you can use to perhaps look at the speed of the device. have the ROM of the device. The ROM in this case, of course, is the Macintosh.

have here some showing a bit of the I/O Kit matching. Since the OHCI controller is a PCI device, its provider class, the thing that it talks to, to talk with hardware, is I/O PCI device. That's probably kind of what you'd expect. Here I see I've matched on PCI class of 0010, which I guess is the right thing for an OHCI writer. More information about what kernel extension this driver is loaded from. Loaded from the Apple FW-OHCI extension.

More matching information. There's a lot of stuff here for seeing how your device got matched. is a good one to check. The class of the object is what we expect. Now, when I plug the device in, we're going to go and look and try and find the right driver for this.

I'm just going to briefly show you This is the XML file being displayed by the XML browser for our prototype SBP-2 disk driver. As a root property, the date when we last worked on it. The module that it is, it's a-- this is the file it lives in. Mac O binary. All executables loaded into the kernel have to be Mac O. We don't support CFM inside the kernel.

Here, the driver is specifying that it needs the FireWire services to run. Me just got a backwards URL to keep names unique. com.apple.iFiWireFamily. The driver wants to use the iFiWire family. Finally, the personality of the driver. This is the real matching information used to load the correct driver. specifies what class should be created when this device is detected on the bus. IOFW SBP-2 HD drive. It's a SBP-2 hard disk drive.

IO Imports specifies what kind of object the driver needs to directly talk to. It needs to talk to the FireWire unit to communicate. You have a score for matching, so if you have several drivers that all match, use a probe score. The driver with the highest probe score will be the one that will get loaded and used. Finally, the two pieces of information that we're going to use for matching for this driver are the unit spec ID from the unit directory and the unit software version from the unit directory. OK, so close that down. Plug it in.

This dialog pops up. It's been popped up by the Registry Explorer application. You wouldn't normally see it. What Registry Explorer application is doing is it's asked I/O Kit to tell it any time anything changes in the I/O Kit registry. And when it does, it asks me if I want to see this update. Sure, I want to see what's changed.

Now, we're still looking at the FireWire registry plane. We now have I/O FireWire devices as the root of the bus. So this guy is being the root now. The little arrow on the right shows that we can Nib over and see what's connected to. These drivers have an interesting feature. They actually have a second PHY inside them for some reason.

that doesn't have a link, doesn't have a ROM I can read. So I represent that simply by a IR registry entry, and I just show what little information I have on that. which is the PHY information, node ID, and the speed of the device, and the self ID packet.

That's the finder, and you can see the drive got mounted. Pretty encouraging.

And if I switch to the service plane, track down to The Service Plane Apple FWHCI will always be the first thing in the FireWire plane because it provides services to everybody else. Connected to it in the service plane is the FireWire device representing this drive. FireWire device has created a FireWire unit for the one unit directory inside the device.

IOCit has looked at the Unispec ID, Unisoftware version, Can I look to the extensions and go to what we wanted, the HD drive driver, this driver for this guy. who's then done the work of connecting up to the file system. In this case, that means creating this little drive knob object, then a IOHC drive object, then we have a media object, this kind of goes on for a long time, partition schemes, couple of partitions, so you've got two partitions on this drive. There's a lot of objects for the file system. Again, if you need to know about stuff, there's a talk tomorrow on that. Finally, let's dismount the disk.

Again, the average application is saying, hey, things have changed. And now if I-- Nib back down to FireWire again. Drivers still connected. Things look pretty much the same so far. Since we unmounted the disk from the file system, the file system objects have all been cleaned up and gone away. There's no right-hand arrow. There's no more high-level devices in the registry anymore. We unplug this. It'll then clean up the rest of the I/O Kit.

You can see now, back just having the one FireWire device driver waiting for devices to appear. That's basically it for my demonstration of how the iCat registry works, how FireWire fits into that, how your drivers will fit in as well. Now, I've talked about the objects that are created to represent how everything's fitted together. So you've got things you can talk to, to talk to your device.

How do you actually do things? How do you send packets, receive packets, to all the things I was talking about? In a similar way to how things are done in Mac OS 9, I have an object called the I0FW command. This is an abstract object representing issuing a command to the FireWire hardware.

The base object handles all the thread blocking, scheduling, completion callback, stuff that's needed. We'll handle SMP in the future, should we do such a thing. and I have loads of derived classes from this base class to do all the interesting FireWire things we can do. Main subclasses of our FireWire command are the async command for sending asynchronous packets out over the bus, and the bus command for Doing bus management stuff like allocating local addresses, setting who the route is, those sort of functions that are bus-wide.

Another important object that I have is for doing isochronous transfers. The way isochronous packets are Transferred over FireWire is, there's a, sort of separate from devices, there's channels that Socratus packets are sent over. So I have an object to represent a channel that's been used for communicating. One for each Isokronis channel that's been allocated.

Its job is to know how much bandwidth that channel has been configured to use, make sure that after bus reset, all the right. Register, ReasonWrite's locks are done to reserve the bandwidth again after bus reset. Also to handle what happens if The channel can't be reallocated. Notify everybody who's registered an interest in that channel what state the channel is in.

For things that are using the channel, these have an abstract object called the isochronous port. Port for the transmitter on the channel, and one or more for everything that's listening to that channel. Each Sucmas channel, when you create a channel and you create ports, you give the ports to the channel, and then once the channel's all been configured with who's talking, who's listening, you can then call methods in the channel to start and stop transmitting, and it'll... Call each port that's configured to use it to tell that port to start listening, to start sending, kind of stuff like that.

If you're using isochronous transfers, you'll need to provide a subclass of this object that knows how to tell your device to start listening, stop listening, stop transmitting, stop transmitting, maybe change the data that's being sent, whatever. And of course, you also need to create, if Macintosh is going to be taking part in the Socratic Transfers, you also need to create a local Socratic support to represent the data coming in and going out of the Macintosh.

This is the object that you would give a DCL program, just the same DCL programs as you may have written already in Mac OS 9. This object looks after those for you, compiles them, feeds them into the hardware, starts and stops them, allocates hardware for them. The nice thing about VCL is that it tells us what Data is going to be transferred. We compile it.

And we know which task the-- and I will be talking about the data that the DCL program came from. So we can program up the hardware and configure the kernel, the virtual memory system, so that the data flowing in and out over the bus can go straight to your application.

It doesn't have to go into the kernel and get copied out, doing lots of interrupts and faffing about. You get data straight from where it We started to where it belongs without any interaction from the CPU, all with the FireWire controller hardware, which is very important for keeping up data rates on high-speed devices like camcorders.

I know it's 10, and we have this terrifying thing called the kernel, the kernel boundary. In ECOS 9, you had the application heap for each application and a system heap for kind of common stuff like device drivers. And they were distinct, but not very distinct. The kernel boundary is a bit like That division between application and system heap, but it's a much more rigidly enforced boundary. You really need to be aware of it, make sure you know how you're going to get data across that boundary. Ideally, you use services we provide, don't have to worry about it too much. But if you're doing interesting things, you may need to consider that.

So if you remember going right back, we were showing two different devices being plugged in. Should your device-- do you need a kernel extension to control your device? Can you just do all your work outside of the kernel? To figure out the answer to that question, you want to consider four main points about what your driver does, what the applications expect to use the driver do, the kind of performance you need.

Is the driver used by the kernel? For example, a hard disk? If you want your hard disk to get mounted by the file system, which is in the kernel, then you need to provide a kernel driver to talk to the file system. Otherwise, you just don't get it mounted.

If your driver is going to be used simultaneously by many of the applications or tasks running in the system, then it might make sense to put it in a kernel. to allow the different applications to all access at the same time. You have maybe been used by many applications at different times, like a printer. Print all at the same time, then that would be something that you would put out of the kernel, even though at different times many applications use it.

Does your hardware, your driver need access to the hardware interrupts in the Mac? For FireWire, I think that's basically going to be no, because we control the FireWire hardware. Of course, if you're writing a... The driver for a PCI card from Mac to fit into the FireWire system then. That would have to be a kernel extension, because it's used by the kernel and it's going to handle primary interrupts.

Finally, do you need to synchronize between several applications that are running at the same time? An example would be audio. If you're mixing several audio channels together from different applications, and wanting them all to come out together, you may need to do stuff in the kernel to make sure that everything is scheduled correctly.

So some examples of where things belong. Our storage, disk drives. They belong in the kernel. You have to write a kernel driver. Scanners, printers don't belong in the kernel. You really want to do a CF plug-in. We'll certainly provide SBP-2 services out of the kernel for you to use, and I'm pretty confident we'll be providing even lower level FireWire access for you outside the kernel, so you can just stay outside the kernel and not have to worry about kernel extensions. An interesting kind of device, a CDR, CD recording machines.

When it's being a CD drive, and you just put a normal CD in it, you want to be in the kernel so that you can fit in with the file system and our users can see what's in that CD writer, make sure it's the right CD. On the other hand, when you're recording a CD, You feel like you should be outside the kernel. You only have one application writing a CD at a time. You don't want the fastest in trying to mount the CD as you write it. I mean, that would be pretty terrible.

So it looks like you're probably going to end up with two drivers, a kernel driver for mounting ready-recorded CDs, and a user driver for applications like Toast to talk to for recording. Which means you have to worry a little bit about sharing, make sure that the two drivers don't conflict.

Finally, high-performance, isochronous, time-critical applications like camcorders. We have a prototype DV camcorder driver that didn't quite make it into DP4, which is currently implemented inside the kernel. And we did it in the kernel because we knew it would work in the kernel. But it would really be nice to have that not in the kernel because, again, there's only one application using a camcorder at a time. Things in the kernel are overhead for every application. And I'm pretty confident that using DCL We can get enough data rate through... We don't really need to be in the kernel. However, that's something I need to verify.

To conclude, FireWire in DP4 is a work in progress. It's not finished. But there's a lot of functionality there. You can do plenty of stuff. You can certainly write a FireWire disk driver, because we managed to do that. It's open source. Get the source. The Darwin site doesn't actually have the SBP-2 just drive source on it at the moment, but I think we'll sort that out and it'll be there. The FireWire family code definitely is all where I checked earlier in the week.

Keeping an eye out on our web page to see how we're getting on with stuff. I'm sure we'll be updating that as time goes on. Remember the architecture is like Mac OS 9 for FireWire. It's not the same. You do have to change your code, but you shouldn't need to redesign fundamentally how your driver works.

If you have a driver that's sort of following the right OS 9 FireWire rules, you should find that you just go through your code, look at the calls you're making to FireWire 9, move them over to equivalent calls in 10, and things should be all work. That's worked for me. I hope it'll work for you, too.

Of course, FireWire is based on I/OKit, and my code is in C++, which means that to call my objects, at least that part of your driver needs to be in C++ so that you can call my code. But that doesn't mean to say that you have to convert all your-- if you have a big, complicated driver, you have to convert all of it from C to C++. You only need to convert-- The pieces that interact with I/O Kit, the call I/O Kit. C and C++ actually work together quite well.

Finally, be aware of the kernel boundary. If you're playing fast and loose in the system heap and the application heap, and your driver and the applications that talk to your driver, you're going to have to do a bit more work in OS X to get across the kernel boundary.