An Introduction To And History of Darwin

proclus writes "Roberto Donhert of Aqua icon theme fame (screenshot) has written a concise review of Darwin OS. The article covers the origin and evolution of Darwin OS, as well as the various Darwin distributions that are available for PowerPC and x86 architectures. OSnews has the story. The only thing that I would add is the contributions of Torrey Lyons of XonX, who created the XDarwin Xserver that made so much of this possible. BTW, Roberto also has a commentary about the SCO situation running at OSnews."

Comments

GNU-Darwin supports PPC

[proclus]

It is important to note that GNU-Darwin maintains and supports nearly 10,000 packages for Mac OS X users, in addition to our 8000 for Intel and AMD based computers. We are going to be on these platforms for the duration. Here are the links.

http://www.gnu-darwin.org/packages.shtml
http://www.gnu-darwin.org/x86.shtml

I've written an article which clarifies the relationship of GNU-Darwin to Apple.

http://www.kuro5hin.org/story/2003/1/20/191655/929

Yves de Champlain has also written a very helpful article explaining Apple's relationship to open source and free software.

http://www.osxfaq.com/Editorial/open/index.ws

Regards,
proclus
http://www.gnu-darwin.org/

more Yves

[proclus]

Actually, Yves wrote a whole series, which is quite excellent. Here are the links.

http://www.osxfaq.com/Editorial/open/
http://www.osxfaq.com/Editorial/open/index2.ws
http://www.osxfaq.com/Editorial/open/index3.ws
http://www.osxfaq.com/Editorial/open/index4.ws

Regards,
proclus
http://www.gnu-darwin.org/

Ugh

[Anonymous Coward]

Um......here are the mistakes just on the first page (not including the odd description of microkernel modules):

The differences between a Microkernel ... and a Monolithic Kernel ... is that a Monolithic Kernel is a large chunk of code, where a Microkernel consists of small message passing cores or Modules, with several different Daemons...

The difference between a microkernel and a monolithic kernel is that a microkernel has offloaded most system services to outside the protected boundary.

The Open Step Develpment Environment ...
History, Mach, BSD, OpenSTEP ...

It's ONE word. Capitalized as "OpenStep" or as "OPENSTEP", the former being the standard (the latter being NeXT's later marketspeak).

[OpenStep] is a true object oriented programming environment developed by Avie Tevanian and others at CMU.

Avie Tevanian worked on Mach at CMU. It is an operating system kernel. OpenStep was developed much later by developers at NeXT. Had nothing to do with CMU. It is a development library built on top of Objective-C and Display PostScript, and ran on top of several operating systems (Solaris, NT, Mach/BSD). I do not think that Avie worked on OpenStep significantly while he was a NeXT, but I'm not sure.

Re:Ugh

[Mneme]

But wait, there are more errors

• In Mach, device drivers are IOKits ( Input-Output kits).

  No. In Darwin there is an Embedded-C++ framework called IOKit for writing device drivers. It doesn't come from Mach (Mach is written in C), it is a masterpiece of design that was written from scatch at Apple, inspired by DriverKit, which was an Objective-C framework with the same intent. (Yes, NeXT put Objective-C in the kernel. At the time, they were running on PC hardware and needed a way to write drivers that minimized developer time.)

• The differences between a Microkernel, like what is used in Mac OS X and Darwin, and a Monolithic Kernel ... a Microkernel consists of small message passing cores or Modules, with several different Daemons or "servers" that communicate between the modules

  No. Darwin does not use Mach as a microkernel, and neither did NeXT's kernel. Mach is used in Darwin because it provides an excellent core for the OS with a clean API. But given the way it shares its address space with the BSD layer and IOKit, you cannot call the Darwin kernel a Microkernel. Yes, Mach makes it easy to have a chunk of a device driver out in user space, and Apple encourages developers to do this when they can, but some Linux device drivers do that, too.

In my opinion, IOKit is what makes Darwin special. The way it uses inheritance and its concepts of drivers having different interrelationships on different `planes' (e.g., power, USB topology, code dependencies, etc.) make it easier to write drivers and support things like dynamic device attachment and power management that Linux still struggles with.

Re:Ugh

[DJSpray]

As a developer writing IOKit drivers for MacOS X, I have to respectfully disagree with calling the Embedded C++ framework a "masterpiece of design." I'll grant it this: it works. But it doesn't support expedient coding, porting, or good modern C++ practice.

The limited dialect of C++ has been a major hassle, and the embedded C++ standard seems to be completely arbitrary. There are a lot of consequences for the C++ developer trying to write good code in the kernel. This is all allegedly done for the sake of a lower footprint and efficiency, but I just plain don't believe this arguments. I will believe that supporting these C++ features, especially as GCC has gone through revisions, would cause binary ABI compability thrashing... but that's a problem to be solved by the kernel developers. Solving it by turning C++ back (mostly) into C is not helpful.

Here's what "EC++" means to me:

- no exceptions: means that you can't have non-trivial constructors. So you're expected to use macros to generate a default constructor for your class, which initializes the base class reference count and what-not.

- no non-trivial constructors: means that you can't properly use constructor chaining and set up const members.

- not being able to set up const members means that your class can't be initialized containing reference objects.

- instead of using constructors the way Bjarne intended, there's a paradigm of using init() methods and explicitly calling the superclass init(), checking for errors everywhere.

- for memory management, I have to explicitly manage reference-counting in certain circumstances. This is because copy-construction and assignment operators can't be implemented properly in order to create a true smart-pointer class.

- the CF (CoreFoundation) container classes won't work in the kernel. To work around this, there is a simplified version of these containers available, where we have OSArray and OSNumber and what-not instead of CFArray and CFNumber. In certain circumstances, such as when working with the registry, voodoo magic results in user-space CF container objects being magically transmogrified into OS container objects. The design of both frameworks is biased towards the Objective-C runtime and not very "C++" ish.

- One feature that would have been of great utility in the kernel, where loadable modules fit into a single environment: namespaces! Instead, we're expected to preface the names of classes with com_mycompany_myproduct... uglifying everything in sight. This can be eased a little using macros, but then we've got... macros. What was the rationale that the EC++ consortium used for banning namespaces?

"The typical target CPU for the Embedded C++ specifications does not have much memory. Therefore, the size of application programs cannot be very large. Under such conditions, names seldom, if ever, come into conflict.." but the kernel is not a typical embedded application; it is precisely a place where many drivers from many different vendors will be prone to name collision.

Actually, Apple's documentation is silent on the subject of namespaces (as it is silent on many subjects). The compiler accepts them, but using them results in problems when using the macros for defining our default constructors...

- RTTI. No dynamic cast; instead we use another... wait for it... macro. With "fake" RTTI in the OSObject base class taking the place of a standard language mechanism.

Now, templates, streams, and STL, I'm actually in favor of keeping out of the kernel. (Although the standard string class, and perhaps istringstream would be nice, if it could be implemented without STL and templates). So I don't want to see all of C++ banned. Forbidding exceptions arguably makes some sense, but the consequences in this implementation cascade into a lot of pain.

Modern C++ practice calls for declaring const things const, using references instead of pointers where practical, and maintaining an allocation-is-initialization style. Embedded C++ bans "mutable," bans RTTI, forces explicit initialization, screws up const members and the use of reference members, and basically results in banning much of the modern C++ world that helps make code more robust. I don't think this is progress!

Re:What I really want..

[ZigMonty]

I haven't done this in a while but, IIRC, you put the number of the syscall you want to make in r0 and the arguments in r3 and up (like a normal function call). The result is put into r3.

Now, if the system call succeeds, control is returned to the instruction *after* the next instruction (ie. it skips one). If the syscall fails, the instruction is not skipped.

Hmm... that's not very clear. Here's an example:

li r0, [syscall_num]
li r3, [arg1]
li r4, [arg2]
[etc...]
sc
b ERROR
[code for if the syscall succeeds]
b END
ERROR:
[code for if the syscall fails]
END:

If the call succeeds, the branch to ERROR is not executed. To find the syscall number you need, have a look at /usr/include/sys/syscall.h.

Re:I swear to Jesus that I am not trolling.

[PygmySurfer]

GNU-Darwin just happens to be the best-selling UNIX on the market today mostly because of the Mac OS X GUI layer running on top of it.

Actually, that'd be Darwin, not GNU-Darwin.

Re:What I really want..

[dadragon]

There are a bunch at IBM's technical library, and also Motorola's tech library. The Linux ABI is well documented, as are the other BSDs, but not Darwin.

Here is one, "PowerPC Microprocessor Family: The Programming Environments for 32-Bit Microprocessors"
Here is one that is PowerPC Linux specific.

Re:What I really want..

[bsartist]

The Mach-O (Darwin) ABI is documented in this PDF. Or, have a look at libffi for a working example - it's part of GCC 3, and supports Darwin.