WWDC 2004 Wish List
There are some things I'd like to see at the WWDC:
-
An officially supported kernel API on top of VFS.
Apple has been saying "don't do that" to pretty much any filesystem hackery for a long time now. They even recommend copying the entire HFS source code and modifying it to add new features to HFS. This is pretty ridiculous. I realize that there are a bunch of outstanding issues regarding stackable filesystems (in general and because of Apple's special brand of juju) but man cannot live on leaf filesystems alone.
-
An API for getting in and out of the kernel (that doesn't suck).
Getting data in and out of the kernel is kind of complicated on MacOS X. There are bunch of different API's that can be used in different situations, some IOKit, some at a mach-level, some at the bsd level. I'd like to see something like IOMemoryDescriptor/IOMemoryMap available in libkern that would handle all the mach naked port weirdness for me.
The control situation is a lot worse. Right now it seems the best way to get control from userland to a kernel extension is a sysctl, which is a little ridiculous. Something like mig should be set up to facilitate arbitrary entries into kernel extensions. Again, this is possible now, but Apple doesn't officially support it and there a bunch of gotchas because of mach messaging optimizations to speed up kernel boundary crossings.
I don't really have too much of a problem with not having a good way to to go from kernel code into user code — it seems to me that the best way to do this is have the user code call into the kernel and wait for something interesting to happen.
-
Virtualization Services
I've argued before that virtualization is something that Apple is good at and that they might consider running linux in a virtual machine. What they really should do is provide a Virtualization Services framework. This framework would allow one process (or thread) to act as virtual machine monitor for a process and intercept syscalls, exceptions, etc. Mach exceptions (as currently implemented) provide everything needed here except system call notification. It sounds like they removed the system call notification because it was slowing down the "ultra fast" exceptions needed to support Classic and Carbon. There is also a bunch of vmm stuff in the kernel (it used to say copyright Connectix, but doesn't anymore). I can't make heads or tails of it though. It must just be a special shim between the exception vectors and Connectix's (now Microsoft's) kernel extensions.
As more and more consoles (and embedded devices) move to PowerPC it seems that Apple could have an opportunity to get game developers to use Apple machines because they have native access to the chip. Perhaps Microsoft will use PowerMacs to develop for XBox2 (maybe they already do?).
-
Per-User File Forks
This is a weird one. It seems like a good idea to store per-document metadata (e.g. window location preferences) in a special fork in a file so that this data is inextricably linked to the file. The problem is that on a multi-user system different users may have different preferences, so we need a different fork for each user.
This is possible (more or less) on HFS+ because it allows each file to have an arbitrary number of named forks.
The problem with this is that permissions are determined on a per-file basis. I don't really see a good way around this — either have the file permissions determine access (possibly a security risk) or change the file system and API to have per-fork permissions (not likely).