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 some heartache for customers, for developers, because you've got to do some work for Apple because we have to do all this work to get it out there. That also gives rise to great opportunities.

And 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 10 drivers-- I'd like to welcome William Gulland. 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 10 FireWire in DP4 works really well. William? Thanks.

Good afternoon. I'm going to be talking to you about, as Jay said, how to write drivers for OS X, FireWire drivers. I also want to go briefly what is in BP4, 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. Really, I wanna make sure that you have a basic idea of how you're gonna start writing FireWire drivers in Mac OS X. and 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-- you 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 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, with the 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.

Apple links.kext is the driver for the Texas Instruments PCI links 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. It's kind of obsolete, but it's 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 hope you'll be figuring it out soon, DP4 can load drivers for the right devices, get them running, so, 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 links 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. You'll see 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 kind of means you can't do DV development, for example, using an OXCI controller. So you need to get a LINX 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 Jay at Firewire at Apple.com, whether we should have a drive--a net driver or just do what we did in--you It's nine 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 the file 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 SPP2 services that's generic for all SPP2 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 OS9 has, you have separate SPP2 services for all the devices that use that standard.

We also have to add the FTP services that are used by, again, 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 Firehours, 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 as 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 file-wired 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 ABC services for, in the same way that we do for SPV2, because in the past there've only been camcorders that needed the ABC, use ABC 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. Thank you.

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, it's just a little tiny box down in the bottom corner underneath I/O Kit.

notice that the dotted line across them up separating the Mac kernel and I/O Kit from the rest of the kernel. That little right-hand side kind of, you know, up the side, implies that a an iKit 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 good old-fashioned Unix isn't really terribly interested in, and the kernel just doesn't want to-- needs to know about it. We're going to put that up into the applications.

So 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 FireWack controller of some kind, it'll either be the links PCI controller or one of many OHCI controllers. So the IOC matching system will then load either the Apple links or OHCI as appropriate.

APALINX 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 the 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 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. A unit directory that we find, the FileWireDevice object finds in the device, we create a FileWireUnit object. Again, a standard object that we create to represent the unit directory.

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 for a bit of luck, it's a device that a driver's been installed for, and at that point, will 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 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.

If we 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 unit, a FireWire unit object for each directory we find. Perhaps we find two unit directories because it's some kind of multifunctional device. We couldn't actually think of an example of one except for a Macintosh. A Macintosh, if you 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, we want to talk to, but the rest of the kernel doesn't want to talk to.

IOCAP 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 plug-in to represent that device outside the kernel. The plugin then has to ask the unit driver inside the kernel to create what we call a user client, which is a 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, it 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 plugin to update 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 service 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 Fire up and running, get your devices going, be able to talk to your devices, know which devices you have, which other devices there are.

It's bus management. It does address space management inside the Mac. That's where you have, you want to have 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 asynchronous.

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 IOI-FIWARE controller that implement the actual hardware register bashing necessary to send packets, receive transmit packets, handle interrupts, all that hardware stuff.

by a FireWire device, one per device on the bus. This is the object that handles some of the fiddly bits about FireWire that we 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 file or 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 file wire 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, well the general vendor ID, every device you make, whatever kind it is, can have the same vendor ID, or it's incredibly specific, GUID is, it's 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 Jay's presentation yesterday where someone's asking about having 10 Macintoshes network connected 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 'cause 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 IOFIUI units, feature those unit directories for your own drivers to match on.

I have a file unit that 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 5R 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 I/O Kit 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, sending packets to it, receive packets from it, so.

So in I/O Kit, 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 a while. The main I/O Kit service plane, we call it, is the part of the I/O Kit 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 hierarchy 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 used to keep track of the bus topology of the 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 functionality, the services that are provided, it only has the IO5Y controller object, the the FireWire device essentially, or the Macintosh itself, and all the other devices that have been found on the bus. Okay, now I'd like to show you the registry in NOAS 10 in action. First, I'm gonna bring up... 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 you when it's not topic pop-up showing the service plane I'm going to switch the plane I'm going to display to the fire wire plane so that we can see what the bus looks like right now nothing connected to the map right now On the front side we see what's available. There's the Apple Flower IOCI 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 do 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's built with Cocoa, and it was, well, thrown together, but it was done, it's a 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 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, of the Macintosh, have here some showing 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 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 colin pension provided from that it from apple w_-eight c_i_ extension uh... more matching information. There's a lot of stuff here for seeing how your device got matched. Here's a good one to check, the class of the object. This is what we expect, IOPI, oops, HCI.

Now, when I put 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 SPP2 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. It's a-- It's a MACO binary. All executables loaded into the kernel have to be MACO. We don't support CFM inside the kernel.

Here, the driver is specifying that it needs the Firewire services to run. media's kind of backwards URL to keep names unique, com.apple.iFiWireFamily. The driver wants to use the iFiWireFamily. 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 SPP2 HD drive. It's a SPP2 hard disk drive.

IO imports specifies what kind of object the driver needs to directly talk to. It needs to talk to the denial-of-fire-wire 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 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 IO 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 it. These have a interesting feature. They actually have a second 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 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. Of course, down at the end, we have the OHCI driver again, still there. It's no longer root because this guy is root at the moment.

it back to the finder and see the drive got mounted. Pretty encouraging. And if I switch to the service plane, track down to the service plane, the FireWire stuff. And the service plane, Apple FWHCI, will always be the first thing in the FireWire plane, because it's providing 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.

IOCAP has looked at the Unispec ID, Unisoftware version, got out, looked at the extensions, and noted that 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 Fawar again. Drive is 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. You can see there's no right-hand arrow. There's no more higher-level devices in the registry anymore. If we unplug this, it'll then clean up the rest of the I/O Kit.

You can see now back just having the one file HCI 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. have loads of derived classes from this base class to do all the interesting Firewire things we can do. Two. Main subclasses of IRF-IR 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 our synchronous packets are sent over, So I have an object represent a channel that's being used for communicating. one for each asynchronous 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 reason rights 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 gonna 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 detail 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 can get data straight from where It started to where it belongs without any interaction from the CPU. Do it 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. NecroS9, you had the application heap for each application and the system heap for kind of common stuff like device drivers. And they were distinct, but not very distinct. Kernel, kernel boundary is a bit like that vision between application 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 gonna 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 wanna consider four main points about what your driver does, what the applications expect to use the driver do, kind of performance you need. Is the driver used by the kernel? For example, a hard disk? If you want a 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 mounted.

If your drive 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, you don't 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 on the Mac? Now for FireWire, I think that's basically gonna be no 'cause we control the FireWire hardware. Of course, if you were writing a the driver for a PCI card for 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 gonna 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.

There are some examples of where things belong. Our storage, disk drives, they belong in the kernel. You have to write kernel driver. scanners, printers, don't belong in the kernel. You really want to do a CF plug-in. We'll certainly provide SPP2 services out of the kernel for you to use, and I'm pretty confident we'll be providing even lower level file 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 it looks 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, very 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 'cause 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 5-wire disk driver, because we managed to do that. It's open source, get the source. The Darwin site doesn't actually have the SPP2 just drive source on it at the moment, but I think we'll kinda sort that out and be there. The FireWire family code definitely is all where I checked earlier in the week.

Keep an eye out on our web page, 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. 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, 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 to 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 gonna have to do a bit more work in OS X to get across the kernel boundary.