WWDC2003 Session 107

Transcript

Kind: captions
Language: en
good morning and welcome to the kernel
programming interfaces for extension
sessions I'm Craig Keithley I'm the i/o
technology evangelist and Apple's
Worldwide Developer Relations group as
the i/o technology evangelist I work
with a lot of qex developers and over
the past couple of years we've faced
some challenges with regard to making
sure that we have a set of consistent
api's that will remain useful for
through the life of a product so we've
we've now looked at providing what's
known as KPIs are criminal programming
interfaces to talk about that címon
patience director of engineering good
morning so let's uh briefly describe
what well it's going to be covered today
first of all we'll go through a
definition of rationale of kernel
interfaces and where we're going to be
taking them over the course of the the
next year or so we'll be looking at how
we're going to be managing the the
version progressions as we evolve them
we'll have a look at the effects on IO
kit will cover general kernel interfaces
and the file system interfaces then
we'll have a look at some networking
interfaces for kernel extensions and
then we'll sum up and then Q&A so kpis
so what are they well obviously kernel
programming interfaces there's obviously
a relationship between those and an API
is just in the same way that that in in
libraries there's a whole lot of
functions but you don't actually get to
program to them all we're using that
kind of analogy here for cutter for the
kernel they're sets of well defined
interfaces are bounded as I mentioned
they cover both functions that the
kernel provides but also the rules by
which you can access data the sets are
versioned
as we move through time we will be
evolving these interfaces some will be
changing some will be being added and
the reasons that they're versioned is
because they really reflect the
implementation rather than the interface
as the system moves on and we want to
have a well-defined life cycle so that
you know what's coming and what
what to expect we're currently targeting
specific classes of kernel extensions we
will be adding new classes as as there
is demand and as we can identify what
the correct interfaces for those will be
so let's have a look at one of the
motivating factors that we have for
putting in kernel interfaces which is
our what we could describe is the KX
dependency problem so here's a picture
of the OS 10 kernel and there's a
picture of your text and as you load it
let's say it's a networking text then
there's a set of interfaces which we can
clearly see your dependent on because
those are the unresolved symbols in your
kext the big problem for us is that we
have no idea especially if you're going
through through data what these
additional implicit dependencies are and
so we we cannot define what the
compatibility points are that you're at
your cases depending on so why do we
need these kernel interfaces well as I
just mentioned Cakes have no explicit
dependencies not a total set of explicit
dependencies we cannot work out exactly
what it is that we can't change and os10
needs to evolve there's a whole set of
reasons why we need to change the kernel
we have new features that were coming in
to provide a better user experience we
have performance improvements that we
need to do there are bug fixes obviously
we try to limit limit the number of bugs
that we have in the system but they do
occur from time to time and we need to
be able to fix those in ways that don't
break binary compatibility 4kx
clearly there's new hardware such as the
hardware that was announced today this
week I mean that takes a certain amount
of change in the kernel and has
ramifications on on kicks if there are
no boundaries and SMP support the the
funnels are well known within the system
and we need to do something about them
to get rid to get better SMP performance
and so without these interfaces this
really makes change within the kernel
very difficult to achieve
so these interfaces define what I like
to call our innovation sandbox
so why would developers one kernel
interfaces well first of all it means
that we can have a set of interfaces
that are best suited for your needs we
can design them such that they perform
the functions that you're trying to
achieve in the most efficient manner we
can improve the stability the
environment and we can provide binary
compatibility from release to release
for these interfaces and they were
significantly reduce the chance of us
changing things that unbeknownst to us
is breaking your case because we can now
test those interfaces and ensure that
they are semantically and syntactically
equivalent from release to release so we
have a number of states just to let you
know exactly where the status of this
interface is we have defined for states
that the stable interface these are
basically the things that you've seen in
the kernel and you know the general
stuff all the Lib C functions for
example stuff like that they're not
growing away and they're guaranteed to
be in the next major release and so you
can rely on those in your products
compatibility interfaces are basically
the same as stable interfaces in terms
of their longevity the difference is the
fact that we're trying to mark them
especially because they are therefore
porting from one system to another and
there may not necessarily be the most
efficient interface to use so we don't
want to mix them in with the stable
interfaces we want to indicate which
ones are the the ones that you should
really be going towards when we decide
that an interface has to to change or go
away for various implementation reasons
then we'll market as being deprecated
this means that the interface is going
to be removed or is planned to be
removed in the following major release
and finally we have another set which is
called evolving these interfaces are
under development and normally under
development with you this is in order to
be able to support new kinds of checks
that we don't really know what the right
interface is and we would like to work
with you in order to be able to develop
that the the best set of interfaces both
for your purposes and for ours
so what are we going to be doing this
well the draft specification for these
interfaces is available now we'll be
giving you information about how to get
hold of them later on this is really
just the end of the interface
specifications the implementation for
those will be coming in the Panta
timeframe and during Panther the as the
system evolves in the Panther there are
updates will be also evolving these
interfaces and the implementations of
them so that you can track them to see
how we're adding to them and evolving
them so that they become something that
we can actually make stable and say that
we can live behind the first set of
stable interfaces will be different
declared with enough time before Panther
so that you can actually port to them
and make sure that you're in a stable
place by the time the next release comes
out the post Panther major release comes
out where we will start to enforce these
interfaces and with that I'd like to
hand over to Dean Reese who's the
engineering manager of the i/o key team
who will talk about how we're going to
managing manage the version versions of
these interfaces
[Applause]
thanks Simon good morning all right I'm
going to be talking a bit about the text
system and how we're going to manage the
KPIs that Simon just talked about so
let's get right into it for pan through
the DX tools have not really changed as
you recall for Jaguar we totally revved
the entire set of kernel extension
management development tools pretty much
got on where we wanted them to be so for
Panther we didn't really change them we
have however added some new capabilities
to support the kernel programming
interfaces basically we've created a new
type of text it's not something that
you're going to be needing to use
directly we're gonna provide them you'll
link against them it'll be pretty much
transparent and I'm going to talk about
that in the next few slides but the
fundamental change that you'll notice
and again it shouldn't really cause any
code changes for you is that right now
your text link directly against the
kernel and in Panther and Beyond they
will link indirectly against the kernel
and I've got some diagrams to show how
that works so in Jaguar if you list a
dependency for your text on any of these
CF bundle identifiers here listed in
blue then you're saying that you need
the kernel and because of the way that
we did the linking for kernel extensions
if you said you needed something from
BSD then you actually got the entire set
of kernel symbols so you could have a
dependency over on i/o kit that you
didn't actually declare and it would
actually work the linking would would
succeed because you are getting the
whole kernel and all the symbols in it
obviously as we're trying to move
towards an enforced interface design we
can't have this we have to have a little
bit more partitioning between the
different programming interfaces so for
all versions prior to 7.0 this is true
if you link against one of these you get
all of them for free this is what it
looks like sort of in a pictorial form
basically all of the sub identifiers for
the kernel represented the whole kernel
and no matter
which one you linked on you got the
whole kernel so in Panther we're gonna
provide binary compatibility through a
set of interface qex the new type of
text I talked about and basically all
they contain is a set of symbols there
they're basically re exporting the
symbols from the kernel but they only
export the set of symbols that you
should be using for whatever version you
want it so basically what we're doing is
taking all of the symbols it shipped in
all the versions of Jaguar for all of
the calm down a poker kn'l bundle
identifiers and we're putting them
together in one big interface text and
if you list a dependency on one of those
a version prior to 7.0 then you're going
to get that interface kext and you'll
get all the symbols that you got before
modulo a few that we had to take out to
support the new g5 hardware so basically
you're gonna get exactly what you got
before should just come up and work yeah
let's move on and look at a picture of
how this looks so in this case your text
and orange there is linking against the
BSD interface text which supports
compatibility everything from version
1.1 up through version 6.0 actually i
think we've made that up through 6.9
just to give us some leeway there and
that in turn links against the actual
kernel actual running kernel and that
sort of provides the filter to give you
the correct set of symbols for the
version that you've asked for
so we're also going to provide a new set
of kernel interface texts for Panther
these are going to be version number
seven version number seven so they're
going to contain all the symbols that we
believe we should support carrying
forward we're going to remove a large
number of symbols that are sort of
internal support functions that really
shouldn't have ever been exported in the
first place and we're also going to add
the new functionality that we've
introduced in Panther there so basically
if you've got a kernel extension that
you've been shipping it'll continue to
run in Lincoln Panther because it'll
link against the older version 1 through
version 6 compatibility interface text
and if you've got a brand new kernel
extension that needs to take advantage
of new functionality then you use the
new set ok and this picture looks
exactly like the picture before the only
thing that's changed is version numbers
you'll see everything across the board
is 7.0
now we still provide a capability in
Panther that we provided in Jaguar and
that is you can still link directly
against the colonel it's necessary in
fact as an implementation detail our
interface qex link directly against the
colonel and they actually play by the
same rules that your qex do so if you
select calm down Apple dot curl as the
dependency you will still get all of the
symbols exported by the colonel now we
don't guarantee any release to release
compatibility with the global set of
symbol kernels because we can't as Simon
said unless we have some enforcement and
partitioning here we can't guarantee you
compatibility because we can't know what
exactly you've used out of that large
massive interfaces so what we do every
time we ship a new kernel it gets a new
version number as it should and if you
list a dependency on the kernel
you must list a dependency on an exact
version of the kernel the implication
being that the next time we ship a
software update with a new kernel in it
your kernel extension will not load on
that version of the OS or the next major
version as well so this is really not a
good way to ship product it's useful in
say with open source projects where your
shipping source code and the client can
recompile for whatever version of the OS
they want to use or maybe in educational
institutions where you're working on a
particular OS for a class but I thought
I would point it out is it is still a
possibility it just isn't something you
would really want to do as part of a
product and that's what that looks like
basically you're bypassing all of the
compatibility interfaces and you're
linking straight against the kernel and
again here you'll notice the dependency
version listed in the text is identical
to the version of the kernel listed
otherwise the linkage would fail
so what does this mean going beyond
Panther well basically you'll continue
to use the same rules you use today
we're introducing a new namespace
I shouldn't actually not a new name
space and you naming convention within
the existing CF bundle identify our
namespace that we already use and that
is calm down a Pilate I you'll see this
in the Panther seed CD that we've given
out this week and you'll see it more
going forward so combat Apple about
Colonel will still be around and will
represent the compatibility interfaces
calm down Apple lock API will be used
going forward to present the new
supportable interfaces and the two will
coexist on the system as much as
possible will also use this mechanism to
make experimental interfaces available
to you as we over the life of Panther
deliver newer updates to our KPI package
will deliver that and that will
introduce new interface qex to your
system possibly a new kernel as well for
the implementation behind them but
that'll partition them off from the
compatibility interfaces because again
the version numbers sound kind of
separate them into past in future
obviously and again as Simon said as the
kernel of all's we're going to need to
deprecated api's particularly initially
as we start to thin that set down to the
ones that we really can support and
kpi's allows us to do this because we
can have a version set that we maintain
as long as possible and then when in
whenever point in time it becomes
impossible for us to continue to support
that we can remove them and it won't
affect anybody who's dependent on a
different interface or a different
version of that interface it will only
affect the people needing the old
version of that particular interface so
it really provides us a sliding window
or the what I like to view it as sort of
a conveyor belt that's some length long
and we introduce an interface and we can
support it pretty much as long as we
want to but eventually we may have to
move off of it as we evolve the kernel
all right so I'm also going to talk a
little bit this morning put on my i/o
kit manager hat and talk about how this
Panther release introduces new things
for i/o kit so the good news is the i/o
kit in Panther is binary compatible with
what we shipped in Jaguar
so the v6 versions of the interfaces
that we ship will continue to load your
i/o kit qex from Jaguar on Panther and
they should work obviously there's
always a potential for bugs this is what
you need to do is take the seed that
we've given you and try it out with your
products make sure that they work let us
know if they don't but the expectation
is that properly written kernel
extensions for i/o kit should continue
to load and run on Panther we've also
introduced a few new interfaces for
Panther those are only available in the
v7 interface again a KX and Needham v6
shouldn't need those interfaces and
we've also deprecated a few interfaces
they I think they've actually been
marked in the header files for a couple
of years now is going to be deprecated
well now we have a mechanism to actually
deprecated them so we're making use of
that all right so the v7 interface that
we provide in Panther for i/o kit it has
a number of changes to io memory
descriptor as you can imagine being able
to address greater than four gigabytes
of memory has some implications for the
way drivers deal with physical memory so
if you've used the abstractions for i/o
memory descriptor correctly you should
not have any problem with your driver
continuing to work on those machines and
addressing a large memory if you've gone
directly to the P map functions or other
workarounds so that you've avoided
memory descriptor then you probably
won't work on those machines so you need
to use memory descriptor we've added
some convenience functions listed down
here
io map to read 8 16 32 64 basically
these allow you to do direct i/o to your
hardware without generating how many
create new memory descriptors just for
your registers and we've also removed a
few from from Panther v7 from i/o kit
these are two classes I think there's
another one on the list this is not a
final list obviously as Panther is not
final but IO command Q and IO sinker or
two classes that were introduced very
early on an IO kit and were realized is
not supportable a long term and I think
they've been marked as deprecated for
quite a while
hopefully this shouldn't affect any of
you but again they will be present in
the kernel but they'll only be available
for linking if you have a v6 dependency
it'll just be mAb sent from the v7
dependency so with that I would like to
introduce mark Berlinski the manager of
the kernel team at Apple I brought my
script with me so as a kernel manager
it's my job to improve the Mac OS 10
kernel and maintain the stability
scalability and performance without
breaking binary compatibility today we
expose all of the kernel interfaces and
so every every bug fix we make every
feature we add we risk the opportunity
or we have the opportunity to break
binary compatibility so we needed a way
to evolve the macula same kernel without
breakage so we need to move forward
today we use two funnels to address the
scalability of the Mac OS 10 kernel but
final contention has led to a
performance impact of MP systems to
address this we're moving beyond the
funnels we're going to be making the BSD
kernel thread safe and implementing a
fine grain locking we will also be
making extensive changes to the kernel
data structures which includes adding
reference and usage counts so kernel
data structures are going opaque and
they'll be accessible only through data
accessors functional routines and
convenience api's we will also be
exposing locking protocols the data
structures where it leads to efficiency
but otherwise we will be hiding for
locking details behind the interface
all new interfaces will be MP safe this
includes date accessors functional
routines as well as convenience api's
okay today the file system block numbers
are 32 bits as we move forward they're
going to be going to 64 bit this is
important for large file system volumes
also it will have an impact on all
interfaces that use block numbers file
system denote operations are currently
not symmetric with respect to V node
locking and reference counting this
makes the job of providing efficient
whole efficient stackable file systems
very difficult for example operations
such as v up close and via getattr are
entered without locks being held any
node locks moving forward all V no
locking will be symmetric there are also
many common functions in the BFS layer
that should that the vs layer should
have that are currently replicated by
all the file systems to address this we
are moving these some of this
functionality into the generic into a
generic VFS layer for example
functionality like NFS export device
alias checks will be moving into this
area this layer keep in mind that the
goal of these interfaces is to allow the
Mac os10 kernel to evolve without
breakage when we just give a background
when we started this we took a look at
our own kernel interfaces we looked at
our shipping file system drivers and
networking extensions we determine that
drivers and i/o kit based extensions
were in good shape so we've decided to
first address VSD file systems and
network extensions and we'll address
other extensions later we considered
only providing interfaces that reliable
scalable and could be implemented
without affecting compatibility of the
extensions
this is our first round of iterating on
these interfaces we were expecting them
to evolve and we look forward to your
feedback
okay this diagram gives you a
perspective as where to where file
system extensions reside in the kernel
as you can see file system operations
are dispatched through the VFS layer as
a set of VF s and V node operations
let's look at what other interfaces they
may use okay so like I said they are
implemented as VF s and V no tops they
also use common c functions and kernel
support functions which every kernel
extension can use they also utilize
functions that the bsd kernel extensions
would use such as credentials for
authentication and process api's they
also utilize file systems specific
interfaces for file data caching such as
buffer cache and UVC let's take a look
at C functions here
okay so the kernel provides a subset of
standard C functions such as string and
memory manipulation as a kernel
extension developer you should be aware
that these functions are not as fully
featured as their user Lite user layer
Lipsy counterparts also there's nothing
there's really no change that's any of
any significance here kernel extensions
will continue to have access to all the
standard C functions that exist today
additionally there are kernel support
interfaces that provide access to
resource management and thread control
as well as memory management routines
such as malloc and free synchronization
routines like sleep and wake up routines
to provide locking using simple locks
and mutexes which can be used by kernel
extensions to protect their data
there are also routines to do thread
call out routines for data copy like
copy and copy out which will be changing
to support 64-bit addresses so far the
interfaces i've discussed are relatively
gone on change with the exception of
64-bit address support however as you'll
see from this point on you'll see a
significant change in the interfaces
many kernel extension use routines use
routines that are considered bsd kernel
interfaces we are providing interfaces
for authentication and process limits
and process IDs for example for a given
process ID you can signal the process
where you can get a handle to the
process but you should now be aware that
this handle is opaque and does not point
to the process struck directly
it kind and it comes with a reference
countenance that will have to be dropped
later also we are moving towards thread
based credentials these credential the
credentials had a process enters the
syscall with you know through the thread
interest Cisco actually will be stored
in a thread local data area so it can be
accessed quickly without contention we
will also be providing interfaces to
obtain a reference v node or socket
through a file descriptor we will
consider adding other interfaces to
things like file ops and ttyS sometime
in the future if you need access to
something that does not coverage send us
your feedback
however some interfaces which owes not
to provide interfaces at risk stability
and that are not sustainable for example
direct access to the system call table
it is not going to be provided in these
cases you will have to work with us and
possibly final turn ative mechanisms or
so the nose or work with us to prefer so
we can provide you with a sustainable
and stable mechanism file caching
these interfaces are mostly used by file
system kernel extensions to do caching
of meta and file data both struck buff
and ubc info are going opaque all let's
say effect all data structures are going
ok for buffer cache we have left the
semantics and usage the same but we have
implemented a new interface is to use
64-bit block numbers for example get
block is now called buff underbar get
block and it takes a 64-bit lock number
we have also left the semantics of UVC
the same except further macros the UCC
macros such as UVC is invalid are now
actually functions otherwise we have
maintained the same API but remember
these structures and how opaque so
another example would be B right instead
of taking a struck buff it now takes a
buff T throughout all our efforts we try
to remain or maintain the familiarity of
the subsystem we didn't want you to have
to learn all new interfaces but we had
to make changes to support the
opaqueness of the data structures and
for locking the reference counting if
there's an interface again that we
missed send us your feedback
okay DFS ops DFS operations are are
already a set of well-defined routines
to manipulate individual volumes through
mouth structure however the mouth
structure is now opaque and it's called
Mountie mount under party this is the
datatype every VFS operation will
receive we are now providing new
accessors accessor functions to the
mount structure for example instead of
testing mount rd only in the mouth flags
you would now use VF s is art rd only to
check the file system is mounted
read-only all mount flags that are
visible directly to user level will be
exposed additional functions will cover
access to other kernel malphite's oh I
need to go back we have also added
interfaces like BFS iterate to provide
access to be nodes on a given mount
these are done in an MP safe way we have
renamed modified status structure it is
now called VFS staff s we have changed
the block number fields to 64-bit so we
can support large file system volumes we
have expanded the path length path names
- max path link for to address
localization issues we have created a
new IO attribute structure called DFS IO
adder again that this is the structure
that contains I Oh attributes associate
with a map point but we have added some
new new information about the device
capabilities such as you know how many
bytes the device can actually read and
write at one time
there are also new interfaces to get and
set these structures within the mouth
structure also we've added some new VFS
operations to support dynamic growth of
a file system they are VFS extend and
VFS truncate we have added BFS uninit to
complement BFS in it and moved it
move them both to file system
registration instead of VFS off
we have untangled EFS mount operations
and defined new VFS ops for update and
reload this was done to keep the logic
and code clean and uncomplicated DFS
operations are defined by a structure
with various function pointers we are
changing this to be similar to the way
that vino tops are done we will make the
FF ops extensible so that we don't have
to worry about breakage when we add new
BFS ops ok vino tops vino operations are
set of well-defined routines to
manipulate individual files so if you
note structure again as on all the data
structures V node structure is now
opaque and is called V no T this will be
the data type all be node operations
will receive and we are also providing
new accessor functions for this
structure we are making v note
operations symmetric with respect to v
node locking and this does have an
impact on
with respect to how he manager Vinodh
locks we wanted to empower the file
systems to enforce the locking locking
their way so now file systems don't have
to use the same locking same locking
rules that VFS used to be enforcing so
if a file system wants to provide multi
reader similar writer locks they will be
able to do so without having every file
system support the locking semantics we
have also modified the sequence of
events to create AV node instead of
calling get V get new V node and then
associated the relevant data and so on
to the V node structure you can now call
Vinodh create which passes in all the
relevant information in one call such as
I know pointer mount T and so on at
which point after the call the V node is
fully constructive and it's complete has
complete information in this way we we
avoid having to use too many accessories
to set all this up and that the side
effect is have the ability to manage
your own inode pool without tying it to
the Vino pool
let's see we are adding new
functionality to suspend and resume a V
node and a mounted filesystem this can
be used acquiesce entire file system so
we can make on disk manipulation changes
finally there's a new theater structure
has been updated to support 64-bit
blocks called V no a be a dirty and just
want to close was saying that again we
are iterating on these interfaces and
your feedback is going to be very
important to us otherwise you know we
can consider the interfaces not complete
if you don't give us your feedback and
you get to help determine our future and
your own future yes that's to where
these interfaces go and that's it I like
to introduce josh grace please who will
be doing networking
[Applause]
hey I'm gonna be telling you about the
network colonel programming interfaces
that we've been working on we have six
interfaces we've been planning the EM
buff socket socket filter IP filter
interface filter and interface and
here's a diagram of the networking stack
so at the top we have the sockets and
between the sockets and the protocols we
have socket filters and attach to IP we
have IP filters and down at the bottom
we have interfaces with interface
filters attached to those all of the
items in purple will be the kernel
extensions can supply to the stack so as
a engineer that's been working on the
stack for quite a while I spend a lot of
time tracking down bugs and I quite
often run into a bug that has a simple
fix but the simple fix would end up
breaking a kernel extension so we end up
with some pretty innovative fixes in the
kernel which we're getting a little we'd
like to do better so one of our goals is
to make all the data structures opaque
so we can extend them when we need to
we're going to change a lot of the
filters to be based on operations
instead of implementation as much of the
implementation as we can hide from you
the better off we are because that lets
us change it will modify a lot of the
fun the new API is return errors more
often than the old ones did so for
example instead of when you call MC I'll
get instead of checking a flag to
determine whether or not the call
succeeded the call will just return an
error if it didn't work we're also
looking at additional interface sets
we're looking at adding support for new
interface families as well as new
protocols
first KPI is the MF KPI all the packets
in the networking stack are stored in M
buffs the am buff structure used to be
visible to kernel extensions but we're
making a change then both will be opaque
and it will be referenced with an M buff
underscore T you'll be provided accessor
functions for allocating and
manipulating M buffs as well as
inspecting them and getting to the data
that they contain the naming of the new
functions will be consistent with the
old functions so it should be pretty
simple to port most of your code for
example MTD becomes M buff underscore M
to D and M underscore free M becomes M
buff underscore free m most of the
functions will return air is now M CL
get is a great example of that it should
make the code a little bit less
error-prone
again we have the network diagram the
diagram the stack and at the top we have
the sockets and we will be providing a
socket interface or socket KPI to kernel
extensions so they can make use of
sockets within the kernel common use of
this would be a network file system the
socket KPI will be provided so they can
perform all of their network operations
using this the KPI is based on the user
space ap is to create a socket the
kernel extension uses Sauk underscore
socket to bind to a specific address and
port it uses Sauk underscore bind the
socket and proto SW structures when
they'll be opaque you'll have no direct
access to these structures and the
protocol control block will also be
hidden so you'll need to use things such
as get sock name get pier name and get
sock opt to get access to the
information that's stored in the
protocol control blocks
between the sockets and the protocols we
have socket filters socket filters have
been completely rewritten there now
based on the operations instead of the
implementation it lets you filter data
and commands at the socket layer you'll
be able to receive notification of
changes of state changes to the socket
for example you get a state change
notification when the state when the
socket goes from the connecting state to
the connected state you'll no longer be
able to intercept or prevent these
changes we also allow you to specify
inbound and outbound data filters the
inbound data filter will pass data to
you no matter how it comes in in the
past you used to have to filter SB
append SP appended or SB append control
and a wide variety of similar things and
there were some other problems with that
if you're filtering inbound data and TCP
input called SB append to put the data
in the socket buffer when if your kernel
extension held on to the data so that it
could later re-inject it and it returned
you just returned SB append didn't
actually have any semantics to let the
caller know whether or not there was
data appended to the socket buffer so
tcp would go ahead and wake up the
client who was waiting on the socket the
client would read get zero bytes read
and it would think it was an end of file
and aronia silly erroneously close the
socket which would lead to lots of
strange problems
so we have inbound and outbound data
filters that should just work and make
things a lot simpler we also have
inbound and outbound connection filters
so your inbound connection filters past
the address that the connection is
coming in from and you'll have an
opportunity to refuse that in the case
of TCP will actually send a reset if you
refuse the connection so you could
potentially build a firewall using these
filters at the socket layer instead of
doing it at the packet layer we can also
filter outbound connections so you can
enforce stricter security you can also
filter on binds and get in set socket
options as well as listen and dioctyl
moving down the stack a little bit
attached to the IP protocol we have IP
filters the IP filters give you a place
to filter packets at the IP layer it's
brand-new
you can filter inbound and outbound
packets and on the inbound side you get
the packet after it's been reassembled
and after all of the media specific
headers have been stripped off you also
get to filter both before and after
IPSec processing has occurred so if the
packets are encrypted and authenticated
you'll get to see it both when it's
encrypted and after it's been decrypted
and you'll get to see any credentials or
any authentication that's occurred on
the outbound side you'll get to filter
before the deception before the packets
been fragmented and before before we
applied the IPSec processing this will
let you modify the data before it gets
encrypted and authenticated and inspect
it before it's encrypted and won't mean
anything to you anymore the filters can
be a trap attached to ipv4 as well as
ipv6
and moving down the stack further
attached to the interfaces we have
interface filters that let you filter
packets at the interface layer in the
network interface filter KPI provides
kernel extensions the ability to attach
these interfaces attach these filters to
your interfaces the interface filters
are based on the DLL interface filters
the difference being that the types are
all opaque you'll be able to filter
inbound and outbound packets on an
interface as well as a 'aka yock tools
to an interface and events coming from
an interface
and at the bottom of the networking
stack we have the interfaces themselves
the network interface KPI provides a
number of things you can do with the
interfaces the interface is used to be
represented by AI fnet structures the AI
F net structure will now be opaque and
you will get a reference to it the
reference the structure is reference
counted and will provide accessors for
inspecting various properties of the
interface as well as sending packets and
performing och tolls and other various
operations it also give you functions
for getting a list of interfaces and
finding a specific interface you'll also
have the ability to retrieve a list of
addresses that are attached to the
interface as well as multicast addresses
and you'll be able to join and leave
multicasts you also be able to add an
interface but you'll only be able to add
an interface that belongs to an existing
an existing interface family such as
Ethernet PPP and firewire
and with that I'd like to bring Simon up
[Applause]
so obviously we can't go into huge
amounts of detail in the amount of time
that we've had available I hope that's
giving you an indication of the
direction that where we're going
so to summarize the reason that we're
doing this is is numerous actually where
it's to allow Apple two to innovate in
the kernel to take the OS 10 kernel into
the future where the new hardware and
the new configurations are waiting and
the new functionality is waiting for us
it allows us to improve the quality of
the kernel as was mentioned a couple of
times they've been bug fixes where we've
actually found it difficult to fix
without breaking compatibility in
somewhere it's actually been impossible
it allows developers to write checks
more easily you now don't have 100,000
interfaces to choose from many of which
will be the wrong ones which you may not
know at the time so now the the
programming interface becomes a lot more
clear as through exactly how you can
develop your case we can provide some
future proofing for you we guarantee the
compatibility of an interface from
release to release we actually have a
much greater chance of ensuring that
that's correct as we move forward
because assuring you know the hundred
thousand interfaces that are currently
in there in the kernel including all the
data usage models that there may be is
almost an impossible job and with this
because the state transitions of
interfaces we can provide a much more
predictable rate of change for
developers we can guarantee that exists
that interfaces will exist from one
release to another we understand the
contract and you understand the contract
so we can give you a much more
predictable environment we also believe
that this will provide a better user
experience for when cakes become
out-of-date and things do go wrong as a
the moment probably what will happen is
that the cakes will be loaded and then
sometime later the kernel will crash
because there's some incompatibility of
daily usage between the kernel
and and your text so now it becomes much
more apparent we actually catch it at
load time that that something has
changed in this case and that is no
longer available to be used on this
particular Rev of the system and the
other big thing is that they start today
well actually perhaps not quite today
because we don't have the the interfaces
actually available on the web yet
however we will be getting them on to
the developer website very soon where
you can download the draft interface
specifications you should look at
developer.apple.com
and there'll be a new section I believe
Craig will correct me if I'm wrong the
new section there which will announce
their availability and so keep your eyes
on that space what we would like you to
do is to review the interfaces against
your text to tell us you know where
we've not gone far enough or things that
we're missing or or actually whether
we've done a good job and though you're
quite happy with them that's also very
valuable information and we'd like you
to send us feedback
there is the an email address that you
can use that will come directly through
to us in engineering and we will be
monitoring that very carefully so be
gentle with us we will be continuing to
update the the both actually the the
header files for the containing the
interfaces and the specifications of the
interfaces and the implementation behind
it so you should track the updates for
this and make sure that they are going
in the right direction and ultimately
when we actually have the
implementations we would like to port
your case to use these interfaces and
then give us your feedback on your
experiences ultimately what we want to
do in the release after Panther is to
actually have these interfaces in place
so we're very concerned that we get this
right and we'd like you to work with us
work with Apple to make this a success
for everyone I mean for a success for us
so that we end up with a kernel that we
can develop in and make progress in and
support future configurations and
hardware and future functionality
and one and make it a success for you
that you can implement your cakes in a
much more reliable and predictable
manner and a success for our user base
where they now actually have much more
sensible things happening when when the
kernel moves on and your kext hasn't so
with that like to just wrap up here are
some other sessions that you're where it
could be interested in some of which
have already passed the eye which makes
them sort of somewhat moot oh you have
them on the DVD sorry so session 100 the
i/o kid kernel extension programming
this actually was very interesting about
how you deal with multi-threaded
environments and and real-time priority
environments the open source of apple
session the Bluetooth update all these
would have passed the USB update and the
firewire in depth the darwin update was
yesterday and the one today in this
afternoon firewire and USB that's a
feedback session which i encourage you
to attend so Craig Keithley is the
person that you need to talk to if
you're having trouble with this like you
can't find the downloads and because
he's the only person that will know
where they are we give them to him and
then he puts them somewhere and don't
forget the the KPI - feedback at Apple
comm mailing list
so we have some URLs that you can refer
to sorry this is not URL so the
documentation you can refer to inside
the RS 10 kernel kernel programming
these are all things on the developer
website
sorry ADC website I locate fundamentals
device drivers API reference kernel
extensions API reference and these
things are areas where you could expect
to that we will add to an extent quite
considerably as we go through this
process
you