WWDC1997 Session 201

Transcript

Kind: captions
Language: en
[Music]
good afternoon welcome to session number
201 rep C core OS kernel runtime my name
is John signa I'm the rap C core OS
evangelist and for the last I'd say five
months the expressions been running
through my mind has been may you live in
interesting times because the last five
months have definitely been interesting
starting off with the January noun sment
of the new OS structure and for that
first month of the during January the
question that came up frequently was
luck colonel is Rhapsody going to use
and it was a choice between the new
kernel and the mach kernel and both as
you know and the month came we made the
decision we went with the mock turtle
and ironically two months Orsini two
weeks later was Macworld in tokyo and
actually got my first experience with
some hands-on experience with the mach
kernel and to be honest it wasn't quite
what I had expected it was a little bit
difficult I'll just show you
okay
I did this so it just like Brett has
nowhere to go but up but I'll go ahead
and introduce Brett Hali who is the
manager for the core OS kernel group and
the tech lead for the PowerPC bring up
and he'll actually talk about the real
not Colonel Brett okay we can all grown
now so imagine by now you've all seen
this particular architecture diagram
should be getting pretty familiar with
it by now and just for a quick review
that for those of you who slept in this
morning or something
a couple of key components that are here
as a part of Rhapsody certainly the
focus of this particular session will be
on the chorus you're here but other very
key core parts of of the technology of
the blue box which only runs on Rhapsody
and only runs on the PowerPC and the
yellow box which is the truly portable
environment for writing applications as
we move forward it's important to note
that in this particular Pete's picture
everything in this picture except for
the blue box has to run and on the
various platform for the deliver to
specifically PowerPC and Intel beyond
that the focus really is here - - as we
get into the core OS and down into the
various details of the kernel and such
that you really aren't going to be
programming to anything but the yellow
box api's will try and give you some of
the overview of the technology that's in
the chorus but the vast majority of the
people here will be focusing in the
yellow box and you'll find that the
services in the yellow box are very very
rich all the way down to abstractions
for if you will kernel level services
and there's a specifically a session on
the foundation kit which you should go
to later in
we could give you a little bit more
insight to that as we focus now on the
car s is really a fit of key components
that make up this part of the system of
course it's really provides the
foundation and infrastructure for the
yellow box and the blue box our charter
here is really to provide the best
possible performance in hardware
integration for Rhapsody it's our job to
support take full advantage of great
Apple hardware innovations and other
innovations that are developed by
yourselves so that they all integrate
well into the system and provide up
through from the bottom all the way up
to the user experience a very smooth and
apple experience as part of that it
means that we have to support quite a
lot of Technology in the core RS being
able to enable clone vendors and plug
and play technology and seamless
hardware integration being able to
support across PowerPC and Intel
platforms being able to deal with
processor advances like ongoing PowerPC
developments like Arthur or opinion -
another key area that impacts the core
OS is in symmetric multiprocessing and
really it's in this space where we have
to do all our work to make the other
yellow box perform well and in this
space and of course things such as
firewire and new i/o are all driven from
the Kouros perspective I'm going to
focus specifically on the Mach
microkernel the BSD space and the
runtime and we'll get hornbill into
detail event in a moment but it should
be noted that there are other very very
important components in the core us such
as the file systems which immediately
follow this one and encourage you to go
there to get information and details
about what we're doing the file systems
IO which is an obviously another very
critical component of the chorus and
networking so let's focus now really on
the kernel on on Mach specifically so
it's important to note some of the
history of my
should be noted that that mark was
originally developed at CMU in the mid
80s by a number of graduate students
including our fearless leader RV - the
game development of Mark continued
through early 90s at CMU and have
development has continued since that
point in areas such as university of
utah the open Software Foundation
Research Institute it's been integrated
into a number of different products
things like a lot from OSF one the canoe
heard and of course next step Marc's
been ported to virtually every processor
architecture and was designed from day
one to DNP that's what one of the key
goals of Maude's some of the other key
features that make up the kernel of
course for things like tasking in across
the communication virtual memory
multiprocessor architecture that's all
all that we'll get into in a moment but
it should be noted that since I won't be
able to cover everything that you're
going to want to know about the
microkernel that there are other places
that you can get information there's a
good book that's out there called
programming under mark there's numerous
sources on the net that you can get
access to information such as news
groups comp OS mark the mark project at
CMU has a lot of online documentation
the Research Institute OSF resource
Institute and even available here is
things like frumenty Linux which is also
based on mark so to start with we get
into in the kernel when they're the key
if you will basis of application
development it's you gotta have a task
or something in which to put a program
in and the task is a an entity which is
responsible for managing the resources
for an application space things like the
memory virtual memory space that's
available and other resources within the
test in addition to the tasks there's at
least one thread that's associated with
the task which is where your actual
program run
and as we talk about that later and get
into where BSD or the UNIX component
fits in these team together with some
additional state and information really
comprise the concept of a process
threads are a scheduling entity that's
used by mark so they end up holding
certainly the register state and other
thing that's actually scheduled on for a
given given program if a task can have
more than one thread in fact they can
have any number of threads and part of
the mock architecture allows each of the
threads to be to be managed
independently so that they're done per
schedule preemptively and if you end up
being in a multiprocessor situation
threads can be on independent processes
obviously a single task in the system is
kind of boring
so being able to run multiple tasks and
things become very critical and one
thing that's very different from the
standard Mac way of writing an
application is that you will end up
modularizing your system your
application in a kind of a different
model than you have in the past
specifically allowing it to be
multi-threaded is one important area but
also breaking things up so that they're
in multiple processes that you have if
you will what things that might be done
today in a faceless background app will
actually be done as a background process
and you may actually wish to factor your
application in such a way that it's
broken into multiple processes such that
it can be used in conjunction with like
web objects or some other entity from
the web where the UI is presented in a
separate way so another and probably the
most important thing that MOC provides
us is an inter process communication
model everything that the task does out
from in order to communicate to the
outside world outside of the program is
done through a mock IPC now again as I
mentioned before you really should be
programming to the higher level of
interfaces the foundation layer which
will shield you from the specific
details of how this is done but this is
a service of panel very specifically by
the microkernel and it serves a very
very important purpose the communication
to and from a given task is done through
through IPC and that a through a
mechanism called a port there may be any
number of ports that exist for a given
process and the ports are actually
shared amongst threads you can delegate
all the communication responsibilities
to a given thread within an application
or or you can delegate to any of the
threads that's done as part of your
design but the communication to and from
the kernel and to and from other
applications are done through this
mechanism of our IPC now in order to be
able to make that work because ports are
not global entities were actually not
externally visible from the path it's
necessary to establish through a
well-known third party a mechanism for
being able to communicate from task one
to test two and it's done by the means
of the kernel again by and another third
third-party entity which in the case of
Rhapsody as things like the nm server to
name server it sits in the background
allows you to talk to well well-known
servers or allow you to register ports
and service and so that they can be used
by applications to be able to enable
this communication because the concept
of report is actually specifically
protected import have what are known as
port rights the ability to determine
whether or not you can send or receive
on a given port if you actually have to
pass the ability to receive a request
off to another task so that a
communication can occur in this
particular case task one would like to
be able to talk to task two
but needs to be able to establish that
communication path through the port's to
be able to do that what's interesting
about the way Mach is designed and
because everything is done through this
mechanism of might be of IPC is that
it's not necessary that these two taps
have to be on the same processor or on
the same system for that matter but the
mechanisms intended to be abstract so
that it's possible to move towards a
more distributed type of environment
from the perspective of memory
management not going to go into the
basics of VM 101 if you will there's
really a couple of key services that
that exist for Marco specifically it
should be noted that the vm system is
designed to be to work in if you will a
very lazy or on-demand manner so that
when you request large quantities of
memory for example in the demo that you
saw this morning with the mac the blue
box running where the teach techs have
huge memory requirements this when you
actually request the vm ofor for market
isn't allocated on the disk or even
allocated all at once it's actually
allocated on demand so you don't have to
have for example like you do now and in
Mac OS some huge file that sits out
there just to make sure that you can do
the M it's actually as needed and as a
result applications can actually
allocate large VM areas and use them as
they need or as another kind of model of
use which we'll talk about when we get
into some of the basic runtime and use
with shared libraries where a file is
actually mapped into memory and it's
actually loaded in backing store created
when it's actually used the other aspect
of the VM system is that unlike for
example aux or even the Lin
for example you don't have to have a
separate partition for the backing store
its allocated if you will dynamically on
the existing filesystem space another
very important aspect of the vm system
and is very very critical to
establishing the performance of the
system and something that use very
heavily through throughout the open step
environment in yellow is copy-on-write
and this is the ability to pass
information from one task to another and
then to be able to share the actual data
in memory and only make a copy of it
when it's actually written to or
modified for those of you familiar with
UNIX 101 when you do a fork typically
the process that's created has to have
an exact duplicate of the process the
parent process and that can be very
expensive it takes a lot of time to do
that and it takes a lot of resources to
do that with mark
when you fork another process the VM
space is duplicated in the system but it
isn't actually you will commit it until
the pages that are that need to be
modified are actually modified the next
layer if you will the system is the BSD
Aero POSIX layer and this really
provides the personality api's and
services for the system it's important
to note that marketing of itself is
actually not terribly interesting it
provides DN services and the IPC
services and in processor scheduling and
those kinds of things but that in and of
itself isn't enough to be able to write
applications you actually need to be
able to get to a file system and to
networking and to be able to have other
core infrastructure in order to make the
useful environment to do anything and
this particular part of the system is
responsible for exporting up those key
services in addition it's responsible
for providing the infrastructure for the
security policy of the system and this
is yet another new area that is very
different from the interest
Mac OS there is the concept of multiple
users in security in the system there is
file protection and as they go into the
pall systems discussion will be some
made some some more data on this but
they certainly built into the the base
of the system is the concept of security
it doesn't mean that where you go
through this process of having B level
really heavy stuff but it is an
important notion that does exist in the
system and it's coupled with the memory
protection mechanisms are there provides
a much more secure environment for
applications to exist so in the BSD
space again this is something where
there's huge quantities of information
available and so just this kind of as a
reference the things to look at extra
daily if you want to go out and get more
details on BSD our unix bsd there's also
numerous sites on the internet for open
BSD free SB net BSD there's also a very
good book that's out designing
implementation of the four point four
BSD operating system and I'll mention is
the by the way Bertrand when he drew his
picture earlier about how the system is
layered indicated it over time will
actually look at upgrading or replacing
some of those layers and this is an
example of a place where through the
process of creating rhapsody where where
i've actually done that the next the
thing that you've got in your attack up
this morning the current next step for
4.1 4.2 our base systems are based on
bsd for three rhapsody is based on bsd
for four so it's a little more modern
version of the UNIX environment more
POSIX compliant if you will so at this
point what I'd like to do is go and
actually show a little bit about how the
system actually operates and to give you
a little bit an idea about how how it is
we've been bringing up the system so you
got here okay so over on this side
right your last I guess we've got the
current PowerPC Rhapsody in it's a
console mode if you will that we use for
as part of the bring up process and on
the other side we actually have a
version of Intel next step with the
yellow box UI of the changes that you
think you've seen so far the first thing
I want to show you is that here we have
a UNIX command line is met exciting and
someone earlier mentioned that the
yellows command was going to be a
replacement for the finder and that's
that's a vicious rumor it isn't true so
let's do this so what I'm actually going
to do is helmut into this this other
system over here a Rhapsody box and one
thing you'll notice we have messages
from the console are actually showing up
here that I noting that I happen to go
to super user status and I'm going to
actually now start up the blue box from
here and this one really is intended to
give you an idea that one the blue box
thing is real we've actually got this up
and running and that there are other
things going on in the system such as
networking and such the demo gods be
willing there we go so blue box is
coming up now which is all a really
really quite interesting but Edition
that I can actually continue do things
like seeing what it is that's running on
the system and that blue is actually
just a UNIX process the sum number of
threads that are used implemented it's
just another application on the system
it should give you some idea also that
we have things like networking in fact
actually activating in conjunction with
this and trying to do something a little
more exciting
oh boy then all this there doesn't just
work and that we do have pre-emptive
activity going on while blue is running
blew within it space is certainly
cooperative and if you go through the
sessions later this week they'll talk to
you more about how all this interaction
and stuff works but indeed there is a
real system there and lots of other
things are running the other thing that
should be mentioned here is kind of a
little bit about the process we took to
bring up the system we actually need
something a little bit different from
traditional Mac phones in terms of going
to network first so they actually
brought the system up over the net the
system actually boots off of an NFS
server and we use that as of how we
brought the system up we're adding
additional services for discs and things
like that or move along the other thing
to note is I talked about the BSD and
the POSIX and mock space is that in this
particular example you see that there
isn't any direct dependency in blue for
the yellow box and that most of the
services necessary any of the system are
built on just that core infrastructure
but that's where a lot of the real guts
of the system work now I don't want to
mislead you hanging as we move forward
there's there will be become a
significant interaction with with yellow
box in terms of integrated user
experience but just so that you know
from a perspective of kind of what's
there in the system that just the
services that are the part of the BSD
POSIX Basin and mock are really the
critical part of getting the
applications running another thing I'll
mention is that the mock IPC as I
mentioned is there really the core way
that the kernel and tasks and other
tasks that communicate with each other
and one important communication that
occurs between mock and process is even
being able to deal with things like
exceptions so that it is possible for
example to be able to create a debugging
environment where debugger can grab
exceptions for a given application and
be able to process them and be able to
deal with things like breakpoints at
stuff
exception handling is handled for any
type of failure condition anything from
floating point to break points or things
of that nature and after one kind of one
of the low-level services for example
that the blue box deals with in terms of
being able to to deal with you know some
emulation of the low level abstractions
of the system through exception handling
and IPC Bacchus lives
so we get into some of the the runtime
issues one of the things that's a
certainly very interesting about the
runtime that exists here one that should
note is it's not CFM it's not talk based
the runtime has been driven from kind of
a long history of next development of
having to support multiple processor
architectures as a result the focus has
been not on trying to drive - which is
typically done focused only on a given
process architecture for your runtime to
be able to support a broad range of
issues and therefore we're kind of
raising the level of the issues that
have to be dealt with focusing obviously
on position independent code dynamic
shared libraries dynamic binding issues
things of that nature the other part of
the runtime issue here though is that
the way it integrates in the mock and to
be able to provide a really effective
and efficient environment for an
application that the dynamic shared
libraries for example are dealt with by
taking advantage of en map files
multiple processes multiple applications
actually share the shared library space
in the code against the multiple
processes the other piece that comes
with that is and this is really the real
heart of the benefit of the runtime
environment is is the object runtime
this is really what makes yellow box and
all the frameworks an object in space
really sing well together
a typical C++ type of object application
tends to be bound up all at application
build time or you have to create special
api's and mechanisms to be able to love
plugins or deal with things or there's
certainly use of something like foam
which is yet another mod
for doing sudo late down binding of
applications the object one time within
Rhapsody however is much more late bound
than conventional in the sense that it's
totally again lazy evaluated it's
everything is done as needed basis so
when the application is loaded into
memory it isn't all bound at that time
but it's bound as needed shared
libraries to for example that already
exist in memory are bound fairly quickly
and those libraries that exist on disk
are bound in is needed and there's a
built in concept and mechanism of
plug-in since called bundles which allow
applications to be able at any time in
the lifecycle of an application to be
able to load in new functionality if you
will
subclass a subclass from various objects
and things within the application
there's an enormous amount of
information that that going to follow
this and I encourage you to go to
session 4:15 and get more about it this
is really one of the kind of very neat
features if you will of Rhapsody and
this coupled with using shared libraries
and modularizing application out into
threads and multiple processes it's kind
of a lot changes though kind of the
landscape of how applications are
developed in a very positive way the
other thing to note about the runtime is
that this couples with the copy-on-write
features that I mentioned before within
the VM system so you have an awful lot
more reuse in the system but there's
also an awful lot more sharing that's
going on
in terms of the actual resources of the
system and that they're only consume
more physical resources when they're
needed so in that that means not only
sharing of code but sharing of data
within the system and that as long as
you're just reading the data as it comes
that's being shared and there's no
additional resources at all that it
consumed it's only when you write to
them or modify them and that
applications and the tools that exist
are designed to bring order the data
within
we'll give an application in such a way
to reduce the amount of duplication
memory duplication is necessary the
other important aspect of the runtime is
kind of how things are packaged up so
it's not pests containers these are for
Rhapsody the focus here is around a
runtime of disk format called mock Oh me
it's not an awful lot behind mark oh
that's really interesting in terms of
going into specific details but one
thing that is worth noting is that it is
designed to be able to package multiple
processor architectures within one
container so it's possible for example
to write an application or a Munich's
tool or any other thing that can be kept
on the server and is that much like an
existing PowerPC 68k application is now
on Rhapsody you can do that will be able
to do the same thing for Intel and
PowerPC
based applications and tools so the
given you will package can contain
either and again just like you can with
today's fad binaries that exist for Mac
OS you can strip the binary to be
specific to the given run running
platform should you wish to make the
reduce the file size so kind of take
what we've gone through so far and
indicate that really in the chorus base
from the standpoint of the kernel and
standpoint of the BSD environment from
the standpoint of the runtime most of
this stuff the details of a and the
api's are really not anything that
you're going to be using 99% of you will
use the foundation framework and other
parts of the yellow box and it's
important to try and focus as best you
can and stay within that space as it's
in that area that we get for your
portability applications that are
written to the foundation or port to
Intel the PowerPC to anywhere that
yellow runs
including NT Windows 95 and Mac OS
certainly there going to be situations
where you really want to tune an
application to a given platform but as
much as possible your application should
be written to take advantage of the
foundation so that you get that
portability the other important facility
that mechanism that exists in there is
being able to be thread safe
so if you write applications to the raw
for example mock services it's all up to
you to make sure that you've got a
thread safe pile of code and that can be
very very difficult to do certainly you
can go one level up into the UNIX layer
and take advantage of something like C
threads and there are additional
services that that help you but then
there are concerns about which libraries
might be thread safe or which libraries
aren't if you focus within the
foundation and within yellow box the
boundaries of thread safe usage are very
well-defined for those people who need
to be able to write UNIX demons who
can't wait to get the latest units viddy
got to have the latest version of Emacs
for some reason you want to write
command-line tools or other development
tools that might be valuable certainly
the focus for you then will be able to
write to the POSIX of BSD for for API
there's certainly lots of free software
that's out there lots of things that are
available on the net certainly you can
get things like Apache or any of those
kinds of things and those if those are
the kinds of apps that you want to have
and targeting background daemons for
example then this is the API second when
you use it's really only for the
debugger developers people are writing
monitoring tools
[Music]
those people who just absolutely have
got to have control over the VM
environment to a very high degree of
control that need to write to the Mach
AP is really your focus should be as
high up through the system as you can
preferably in the yellow box if you can
at the level of mark get to some of
those key features obviously though you
lose some of the portability capability
but forget to be highly tuned to a given
platform that may be the valuable thing
for you to do so I've one more demo if
you will and it's mainly to kind of take
all this and wrap it up into behind the
scenes perspective of what's there so
this is the the demo of the stone
designs create product that was ported
at the end of last week in a matter of
hours to the PowerPC Rhapsody it was
shown that Bert Ron's presentation
earlier I want to give you a sense of
what's really here behind this
application what's really running and
they give you a little better sense of
where the system is at if you lo at this
particular stage as I mentioned earlier
we're actually bringing the system up
over the network so we're running in a
networked environment and if NFS mounted
if you will but even with that I can
still actually we have full file system
access and this is all very transparent
as far as the application and users
concerned there's a number of background
services that are actually running at
this point certainly things like
networking and such as I had shown in me
when I do is did the PS and the other
demo there's a number of different
processes that are actually executing at
the same time and there may be for
example NSS or nm server which is
responsible for some of the name service
negotiation within the actual yellow box
itself it also has a number of services
that are there that exist in the
background for example the ability to do
things like cut and paste a more handled
through a server
pasteboard server which allows you its
deals are they going between multiple
processes if you will it arbitrates the
pasteboard or the clipboard there are
other servers as well that deal with
drag-and-drop and those kinds of things
and it's not really so important as to
what they are but the way that the
system's architected is a little
different than the Mac OS in the
perspective that there are lots of
processes that are running and that the
way things tend to be factored out
really take advantage of the multi
thread multi-threaded nature of the
system the fact that there are multiple
protected editor spaces the fact that
you can communicate between different
tasks to get your job done and there's
benefit in breaking out a given
application and potentially given on
this given the particular need that you
might have to have a server that's
responsible background server that's
responsible for managing a particular
service for example one of the things
I've seen one of the apps that we saw
ways they have a license server runs in
the background or they might be a
background compute server which might be
done either on a different name images
you just do it as a separate thread or
again you want to provide a compute
engine that can be used for some
particular reason for a web interface so
that you can come make a common set of
services in your system that are broken
out modular between your actual
application background services and such
and net access other things that that
come into play here is that we actually
have multiple applications running where
in this particular case we actually have
three things we have a terminal window
so that if you just absolutely have got
to get to the command line it's there
and TextEdit and this create program so
there's these are multiple separate
processes and there's communication or
whether this communication that occurs
like I said through the use of like the
pasteboard server to copy things back
and forth between these different
you know process of doing this
particular operation involved a number
of different processes and services in
addition these the multiple applications
through shared libraries can actually
share code to be honest in the current
system for demo purposes we haven't
bound the system up these shared
libraries enabled yet but in a typical
configuration or in existing systems all
the libraries that are part of the
frameworks and software actually shared
between the multiple applications so all
the document management all a lot of the
things like a fonts color panels those
kinds of things are actually shared
objects and entities that are used
between the multiple applications and
processes and that takes advantage of
all the services that we talked about
before so I need to close up this part
part of it if we're going to provide
some time for doing a lot of question
and answers that when I go back over a
little bit of a timeline here that
virtue I mentioned this morning you know
as we actually started this process
supporting to the PowerPC in the in
early February and is kind of a curve of
activity that's actually pretty
interesting as we are bringing up the
system and then as soon as we got to the
UNIX if you will command line that many
many things were able to be brought up
in parallel and it's very much because
of the layered nature of the system that
the fact that there is a lot of
portability of the code that most of the
things like the commands and the
application and frameworks and such once
we got to a base level of functionality
those things came over fairly painlessly
and as even demonstrated by the ability
of the third-party apps that we've seen
it's just literally a matter of recount
so I think you may have noted that in
the timeline that there was quite an
amount of acceleration that occurred in
the development process and that really
attributes itself to the way the system
is layered and then I focus very much in
the platform space is limited to the
items that I talked about this morning
that you know the bulk of the the
platform dependencies the CPU descent
dependencies are limited to the kernel
to the BSD layer on into the runtime
environment so one thing that else that
should be taken from this is that there
is a lot of other services that are part
of the system that we interact with and
I didn't get a chance to go into today
things like the file systems in i/o and
the run more detailed object runtime and
I encourage you very much to go to the
other sessions to get some of that
information and on that note I'm going
to complete here and we'll actually be
able to take some questions and stuff
thank you
[Applause]
Thank You Brett while we're waiting for
the panelists to come up turns over to
like to point out some additional
sessions coming up we have following
this session at six ten in this Hall we
have raps key core OS the file system on
Thursday at 8:30 a.m. in room a one we
have understanding raps key drivers
Friday 5:50 we have raps network api's
and services I point these sessions out
right now before you go up to answer or
to ask questions please keep in mind
these sessions are there that if you
have a file system question or driver or
networking related questions it's best
to hold off on those until the
appropriate sessions because we'll
probably a lot of cases will answer your
questions in the presentations there in
addition there's some additional
programming sessions that are related on
common object model Roxy runtime and
into the open staff foundation framework
both those sessions are repeated and
finally on Thursday 11:10 room j4 will
have a core OS feedback forum in
addition if you're unable to attend that
forum and you have some feedback for us
you can use the rap C - dev - feedback
at Apple comm email address we do read
that we do forward it on so with that
I'd like to go ahead and open the floor
to QA please when you as I believe two
microphones please before you ask you a
question state your name company and
your question and before we do so why
don't you go ahead and introduce each of
you cells our analysis I'm Winston
Hendrickson I'm the director of Rhapsody
Corollas Eric version chorus Colonel
Jeff Glasson manager of the BSD part of
the kernel Kevin Enderby compiled a
grunt
back and forth okay when we just go
ahead and we'll just start up in the
front here on the right your lives
University of Illinois what kind of
excuse ability would you have been
Rhapsody released for running multiple
blue boxes and also the user interface
for putting the blue box in a background
and or switching between multiple blue
boxes actually I think so actually for a
lot of the details about the blue box is
probably best handled in efficient but
certainly some of the the core
technology there enables multiple
processes there's a much more
complicated issue of the user interface
interaction issues with Rhapsody and I
think they're probably best suited to
answer the how the unit how you would
use the interface in that manner okay
when we move to the far right Marshall
Aladdin systems this morning during one
of the keynotes people were one of the
speaker's was talking about two versions
of reps the a client version a server
version what are the changes in the core
OS and the kernel to support a server
version whatever really are the
differences here so in terms of the
server product I believe there's a
server session during this week probably
go into some more detail but but but I'm
not going to totally cheese out there
the main differences that have been
discussed so far around the area of say
on file system volume formats that are
available and supported on things like
dynamic tuning remote administration so
on and so forth
I don't know Conrad if I if I got all
the ones there but it's going to be
things of that nature on certainly you
could say well some of those could end
up going in the desktop product and
perhaps they will over time but the
server product will
having needs around specific file system
features or features for administration
and so on and so forth that may not be
necessary in the desktop product Thanks
when we move to I guess it's our Center
Jonathan Oil Eastman Kodak just a
question with regard to the yellow box
running on other systems like Mac OS and
Wintel since they're not going to be
writing on top of the mach kernel as
Rhapsody would be it is is the kernel
somehow emulated for the foundation
layer or what would how do you handle
the cases where you've got open step API
riding on top of a non pre-emptive
environment so the foundation framework
is actually responsible for dealing with
that level of abstraction visit all the
core chorus services things like file
systems thread management and all that
is done through the foundation and it
has to do obviously some emulation if
you will of certain kinds of services
such as if you will are now with this
things to the mock IPC being able to
pass is a communication back and forth
between multiple processes an
implementation on wind 95 for example is
going to be if you will less robust or
is not as nice of an implementation as
it exists on Rhapsody because of the
level of negation of services but the
foundation instructs that from the
application yeah because it seems to me
that if the foundation assumes
pre-emptive 'ti or make certain
assumptions about the OS that's not that
it's not there there'd have to be some
kind of emulation and then
there would be obviously performance
differences between how it would run on
a true Rhapsody either PowerPC or Intel
than it would writing on top of 95 or
mac OS so this morning in Berlin session
was early this afternoon he actually
talked about the fact that we're still
wrestling with the issue of thread
handling pre-emptive thread issues on
terms of Mac OS and we don't really have
the answers quite yet as to how we're
going to address that issue that's
currently being handled on Windows 95
and certainly an mt through layers of
emulation just do you know any of the
details yeah we Windows 95 actually is
multi-threaded so the the main the main
way things are dealt with at the lowest
level is we've got a wrapper emulation
package that kind of emulates the mock
IDC API is that foundation can actually
call out it's very lightweight on
Windows 95 it actually uses some mail
slots so if you're familiar with the
win32 code so it's very lightweight
thanks let's go back to the far left
idea Bob Wells allele with respect to
the merge between the objective-c
runtime and the Java VM
how will Java garbage collection work
the Java VM garbage collection is
handled completely inside the Java
package so check to see does not have
its own garbage collector as part of a
language it does have an auto release
mechanism and they are completely
separate so you know it was it was quite
well so front-left mountain hill
couldn't university west australia just
wondering regarding the command-line
interface what sort of access to
allowing for end users and do anticipate
a lot of unix utilities and like being
ported over just as a straight till up
with CLI interfaces without much of a a
mac user experience on top well the full
berkeley for for bsd set of utilities
will be provided it's not going to be
encouraged for normal mac user but if
you're used to a UNIX environment by all
means you can use it and you think the
slam that have negative effects as far
as a mac experiences concerned I think
we've we've done pretty well hiding
hiding the UNIX thing and Fortran talked
about this morning and if you've ever if
you've seen next step or the Rhapsody
yellow box implementations there's GUI
to do basically everything from system
administration to browsing the file
system to formatting disks it's all
hidden you never have to see a shell
prompt let's go to the front
Chris wolf from following information
systems and wolf where I add too short
but unrelated questions which version of
the Mont kernel serves as the basis for
the rack to the implementation and did
you resolve the issue in any of these
external layers about the infamous
non-sweet non-drinking spot pile bug in
next step okay the the kernel is based
off the open step kernel least amok
kernel so it's basically two five with a
lot of other stuff in it there's some
300 isms in there that's what's going to
be going out with the developer release
there's still some issues it's not
necessarily what's going to go out with
premiere we're still making some
decisions on on that the non shrinking
stockpile bug has not been fixed yet to
my knowledge but I certainly want to fix
it we might mix it to we'll take that as
feedback okay let's take the far right
theater of Cho from Massachusetts
Institute of Technology with regards to
the BSC for for environment how much of
being about how much of the development
environment will be shipped in terms of
C compilers the standard libraries that
you might expect on a BSD four for
system etc well as I said before all of
the standard BSD like section two and
three calls will be there for your UNIX
weenies out there we're going to ship
take a new compiler environment so GCC
all everything that's part of BSD will
be there curses term cap again are oh
yeah okay back Center
Metro Lobell multi-node Microsystems and
parallel processing connection you
mentioned I think that the that the mach
kernel using pieces of three to five and
three oh is that correct yes
and I'm wondering is can how much of the
API then the maka API can we depend on
how much has been modified how much is
still available if we really want to
write to it well just kind of the
obvious caveat and that you know for
portability reasons that that's
certainly not encouraged but at this
particular point the api's that are
exposed I think are actually fairly well
documented and will be documented and
there are two five plus a number of
additional API so at this particular
stage there isn't a full 300 API set or
two part but two five is intact plus if
it's of additionals yes here with the
only exception that I'm aware of is that
the VM system is not completely to five
component it's very close but it isn't
doesn't exact API mentions it's very
documentation to tell us what you you
know what's available what's changed
yeah there is documentation that's been
available I'm not sure the current state
of those dots and know that we will be
documenting the system so thanks thank
you okay far left the chels applause you
hey next time user group during the
presentation you kept saying using the
term microkernel when describing the Mac
could you clarify that because you just
said a minute ago two point five I put
as a monolithic kernel so it isn't three
Oh in a sense of a truly isolated
microkernel where the server if you will
the bsd environment is server eyes din
user process or in the case of the OSF
our eyes server colocation so it isn't a
microkernel in that particular inspector
it is architectural II from the
standpoint of how its implemented in the
system so it's a four semantic clarity
yes you're right it's not you will a
true isolated microphone it's isn't
likely then in the future that you'll be
moving over to proper my to pedal muscle
even using MK Linux well so I think
we're we're evaluating over time which
of the technologies from the 300 and the
MK based it's used for example for any
Linux or really from the OSF Research
Institute and other sources are
appropriate for Rhapsody so I think
Burke I made it pretty clear that we
over time will evolve the system is
appropriate to be able to meet the needs
of our developers and hardware platforms
and other things that we're delivering
to and we obviously have some experience
with that code base of 300 and such in
certainly some technology for example
part of the IPC system itself has been
pulled on through from 300 and will
continue to take more technology as
appropriate the reason I mentioned the
MK limits is because I heard of
announcement recently that HP a now
negative ported on K Linux for the a
risk that's true they have followed our
lead on it ok thanks ok front left
please yeah john wallis power on
software there's obviously a big wall
between the yellow box and the blue box
most notably the blue box seems to be a
second-class citizen running inside of
the yellow block yellow box meaning that
all my Mac apps on the current system
are running separate from my yellow apps
is there any community mechanism where
on there will be a unified yellow app on
top of blue app on top of yellow app on
top of blue app in the
in the ratcheting system for our we have
to live with the unacceptable situation
of our current Mac OS being a
second-class citizen so in terms of the
human interface in the integration
between the yellow and the blue box
the current plan calls for being able to
have two modes one which is the blue box
taking over the full screen another is
the blue box within a window certainly
over time as with all things we're going
to investigate you know any types of
improved integration that you know our
user studies and so on and so forth
dictator the appropriate thing to do but
it means that nothing in the beginning
not at this point now the other piece of
this is that I don't think the the blue
box is actually a second-class citizen
and actually what we've been finding
just with the bring up of the blue box
so so far is that it it runs in the
environment with quite a lot of
efficiency and that the users experience
I think is the issue that it's a
question if in a system level that is of
the case in one other one of the things
sort of this tag-team question answer on
the the user experience group has
certain concerns about some of the
subtle differences between things you
can do in a blue application and things
you could do in a yellow application and
there's some concern with having a high
integration between the two that there
might be subtle confusions that get
bestowed upon the user that could end up
being more harmful than good and so it's
an issue we want to investigate over
time but that's really where the concern
stems from I recommend attending the
blue box Mac OS compatibility session
tomorrow
let's talk actually
well confuse me
you what shows you what happened when
you walk up to an empty mic you said
something in the last answer that
actually Peaks my feet the concern of
mine you said that you can run the blue
box at the fullscreen I only have one
Macintosh that has only one screen and
that's my power book to me full screen
means all monitors different depths as
many as I can many video cards as I can
cram into my 9500 I just want to verify
that you meant the same thing
fullscreen means all screen yes thank
you
this is probably the last question since
we're running out of time here so up in
the front
IBM microelectronics had a question as a
developer running yellow box
applications on a mock kernel is it
possible to access the processor
instructions specifically MMX type
instructions yes absolutely
compatibility or your cross-platform
capabilities there well sure when you I
mean when you dip down in take advantage
of a specific platform then you've got
to conditional eyes that out either in
runtime or in compile time okay there's
something but there's nothing
specifically keeping you from going
through the kernel firm no in addition
some of the key libraries that you're
probably will be interested to take
advantage of MMX such as technology or
for example a QuickTime or quick-draw 3d
or any of those things obviously those
libels libraries will already be built
for to take advantage of those
particular things on the given platform
okay on that question we're out of time
I'd like to thank you for attending and
again remember the file system session
is in the same Hall following in about
20 minutes and the other sessions
related Iowa drivers on Thursday and
files or assuming young networking on
Friday thank you
[Music]
internal rain