[clug] [OT] With Coders like these, how far can Apple go?

[steve jenkin]

I was gob-smacked at some statements I saw on the Apple Developer site...

They have a section entitled:

"Keep Out: Why You Should Avoid Programming in the Kernel"
[It's a black art and too hard/perfect for ordinary mortals.]

Thank goodness these ideas don't propagate in the FOSS world, especially
the Linux kernel.
Though Linus will give you a well deserved serve for being a fool and
attempting to submit code beyond your understanding/capability.

------------

Another page says: "there's Right Way and a Wrong Way"...

<https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming/IOKit/IOKit.html#//apple_ref/doc/uid/TP30000905-CH213-SW1>

"Part of the philosophy of the I/O Kit is to make the design completely
open. Rather than hiding parts of the API in an attempt to protect
developers from themselves, all of the I/O Kit source is available as
part of Darwin. You can use the source code as an aid to designing (and
debugging) new drivers.

"Instead of hiding the interfaces, Apple’s designers have chosen to lead
by example. Sample code and classes show the recommended (easy) way to
write a driver. However, you are not prevented from doing things the
hard way (or the wrong way). Instead, attention has been concentrated on
making the “best” ways easy to follow."


------------

<https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming/keepout/keepout.html#//apple_ref/doc/uid/TP30000905-CH205-TPXREF108>

*Keep Out*

This document assumes a broad general understanding of kernel
programming concepts. There are many good introductory operating systems
texts. This is not one of them. For more information on basic operating
systems programming, you should consider the texts mentioned in the
bibliography at the end of this document.

Many developers are justifiably cautious about programming in the
kernel. A decision to program in the kernel is not to be taken lightly.
Kernel programmers have a responsibility to users that greatly surpasses
that of programmers who write user programs.

*Why You Should Avoid Programming in the Kernel*

Kernel code must be nearly perfect. A bug in the kernel could cause
random crashes, data corruption, or even render the operating system
inoperable. It is even possible for certain errant operations to cause
permanent and irreparable damage to hardware, for example, by disabling
the cooling fan and running the CPU full tilt.

Kernel programming is a *black art* that should be avoided if at all
possible. Fortunately, kernel programming is usually unnecessary. You
can write most software entirely in user space. Even most device drivers
(FireWire and USB, for example) can be written as applications, rather
than as kernel code. A few low-level drivers must be resident in the
kernel's address space, however, and this document might be marginally
useful if you are writing drivers that fall into this category.

Despite parts of this document being useful in driver writing, this is
not a document about writing drivers. In OS X, you write device drivers
using the I/O Kit. While this document covers the I/O Kit at a
conceptual level, the details of I/O Kit programming are beyond the
scope of this document. Driver writers are encouraged to read I/O Kit
Fundamentals for detailed information about the I/O Kit.

This document covers most aspects of kernel programming with the
exception of device drivers. Covered topics include scheduling, virtual
memory pagers and policies, Mach IPC, file systems, networking protocol
stacks, process and thread management, kernel security, synchronization,
and a number of more esoteric topics.

*To summarize, kernel programming is an immense responsibility*. You
must be exceptionally careful to ensure that your code does not cause
the system to crash, does not provide any unauthorized user access to
someone else’s files or memory, does not introduce remote or local root
exploits, and does not cause inadvertent data loss or corruption.
-- 
Steve Jenkin, Info Tech, Systems and Design Specialist.
0412 786 915 (+61 412 786 915)
PO Box 48, Kippax ACT 2615, AUSTRALIA

sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin