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