Re: Various questions from someone starting out Kern development
Re: Various questions from someone starting out Kern development
- Subject: Re: Various questions from someone starting out Kern development
- From: Jim Magee <email@hidden>
- Date: Mon, 1 Mar 2004 15:49:11 -0500
On Feb 29, 2004, at 12:24 AM, Rob Ballantyne wrote:
>
I've looked at some of the doc and read some of the list looking for
>
various things. I can't find em. I hope the questions are not too
>
obvious and that I haven't missed finding them somewhere. I'd greatly
>
appreciate any answers and/or pointers to doc I haven't found yet.
These are some pretty good questions for a "newbie." As Justin stated
in a related follow-up, some have been answered before. But maybe its
time for a little recap anyway.
>
1. As I recall Mach based systems are usually a collection of
>
communicating Mach tasks/servers but it appears that the Darwin/Mac
>
OS X kernel must be a single monolithic Mach Task. Although there
>
is no netname server at all, the bootstrap server subsumes these
>
responsibilities I've read, not even the bootstrap server is
>
available to the Kernel task(s). So the questions here are:
>
is the BSD kernel a single Mach task? Are there any other Mach
>
tasks (doing Mach IPC) within the kernel boundry?
Most of the kernel is a single task. There is one "wart"/vestige where
there is a second task sharing the address space with the rest of the
kernel. That is the BSD code that handles Mach exceptions and turns
them into BSD signals. It actually runs in a separate task within the
kernel. But, there is little valid reason to do it that way - the
added protection is minimal. Mostly, it is driven by the fact that
ports are referenced by names in that environment, just like
user-space, rather than by pointers to Mach port data structures.
Therefore, references to stale names are not as fatal as references to
stale pointers. But if you depend upon that, you aren't robust enough
to be in the kernel anyway. In the BSD exception handler case, It is
just something we haven't gotten around to "fixing" yet.
>
2. I've also read in the list that the way to do kernel/userland
>
boundry crossings with Mach is to somehow pass the required port
>
rights from userland into the kernel. How is this usually done?
>
Are there realtivly simple examples of services (Mach servers if
>
that's possible) living in kernel land that are in the kernel
>
that someone can point me to?
Unless you are making use of an existing interface that passes port
rights, its somewhat of a catch-22 situation. IOKit user-clients
already do this passing, and so are highly recommended mechanisms for
"getting hooked up." Other code, reached through direct system calls,
take advantage of a "know fact." All such calls are done in the
context of the calling task (using the calling thread - which holds a
reference on that task). So, you can just pass a 32-bit value port
name and "look up that port name" while in the context of that call to
get a send right reference to it using Mach's in-kernel IPC interfaces.
Of course, all of Mach's interfaces are SPI in the Mac OS X world, even
these in-kernel Mach interfaces for KEXTs. So, anything using them
will not get release-to-release binary compatibility they can depend
upon.
>
3. Older Mach documentation pretty explicitly states that MachIPC is
>
a wire protocol in addition to an in kernel IPC mechanism. Are the
>
hooks still in Darwin/Mac OS X to do IPC between distributed
>
processes?
Error recovery in a distributed (over the wire) world is hard.
Embedding those semantics into Mach messaging makes it slow(er than it
needs to be). Given the wide variety of choices for over-the-wire
protocols and their associated error recovery semantics, we felt it
wasn't necessary to add yet another - and would only hamper our ability
to use Mach IPC in more performance critical ways within a machine.
So, one of the first steps for Mac OS X/Darwin was to remove
distributed Mach IPC as a part of the supported environment.
That doesn't mean that we wouldn't use it "across the wire" in a
tightly coupled distributed system/cluster. It's just that we probably
would never recommend using it in a loosely coupled environment.
--Jim
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.