For a while now, the use of /Extra has been the most popular way of organising preboot and installed patches, drivers etc.. Many bootloaders now support this, but for this example I will be using Chameleon 2.0rc1 r431 which is latest at time of writing.

Note that due to the way the techniques have evolved, single tasks may be accomplished in multiple disfferent ways. For instance, values for graphics (to enable a graphics controller) can be done by an injector kext (like natit or nvenabler) by a Device-Property string, or by a suitably patched DSDT.aml only one instance of one technique should ever be used at any given time, however.

The /Extra folder can contain any combination of:
kexts (In /Extra/Extensions)
kextcaches: (usually in /Extra/Extensions.mkext)
Device Property Lists (by way of the Device Properties entry in /Extra/com.apple.Boot.plist)
DSDT Patches (in /Extra/DSDT.aml)
In the case of chameleon there are also:
smbios.plist (which injects smbios values directly in the bootloader)
a "Themes" folder (which contains themes for the bootloader GUI)


A basic setup with Chameleon might look like this:
Click to view attachment


Injectors:

The 3 kexts included are Injectors:
(sometimes called "legacy" kexts or plist-only kexts) which modify the behaviour of vanilla kexts to extend their functionality. In this case they add support for a range of disk controllers by injecting their device IDs and other parameters.

The most commonly used injectors are graphics injectors: titan, natit, nvinject, nvkush, nvenabler etc.
Similarly injectors exist for sound: e.g. ALCInject and HDAEnabler.
Injectors for SMBIOS values: AppleSMBIOSEFI.kext, SMBIOSEnabler.kext, SMBIOSResolver.kext

"Plist-only" or "Legacy" kexts consist of an empty kext with just the Info.plist inside. The object of this is to add to or override the values in the main kext that is being loaded by the system. typically this will add device IDs or similar values to allow the kext to load with hardware other than that which it was intended for, but crucially *without* modifying the original kext itself, so that functionality will not be lost in the event of an update.

Decryptors:

To boot successfully, a decryptor must also be present, typically dsmos.kext or Appledecrypt.kext
This is necessary because certain binaries in OS X are encrypted, normally this decryption is done my the mac itself. as this is not available a decryptor kext is used instead.

Additionally, a Disabler.kext is often used, this does the opposite of an injector, by blocking other kexts from loading.
Disabler.kext loads itself instead of the "disabled" kext by having the same "personality" in its Info.plist but with a higher IOProbescore. as needed, kexts to be disabled can be added and removed from Disabler.kext by adding and removing entries in its Info.plist.
The earliest example of a disabler is DFE's IntelCPUPMDisabler.kext

Injectors, Disablers, and Decryptors are almost always used from /Extra

Kextcaching:
kextcaching may improve performance and have other advantages

when you add new kexts to /Extra/Extensions, it is therefore a good idea to run: to rebuild it (see man kextcache for more details esp. the -a i386, -k options may be useful)

In some cases preboot media or patches for specific machines are distributed solely as Extensions.mkext . In this case it can be useful to use mkextunpack (see man mkextunpack for details) to get the kexts used to create the kextcache so they can be edited or adjusted.

so, having added dsmos and Disabler, and run kextcache, the chameleon setup now looks like this:

Click to view attachment

Drivers:
Drivers can also be loaded from /Extra/Extensions or /Extra/Extensions.mkext in some cases this is simple and preferred. Often, however, driver kexts have dependencies, and in order to load from /Extra, the kexts upon which the driver depends must also be present.

To find out what vanilla kexts you need to fulfill the dependencies of a particular driver, open its Info.plist and look under OSBundleLibraries. This will contain the explicit dependencies in com.apple.blah type notation. note that although drivers loaded this way will usually survive updates, it is a good idea to replace the vanilla "dependencies" kexts for each new OS version. (and kextcache for reliability and pleasure )

In order to load instead of the drivers in /System/Library/Extensions certain changes tend to be needed in the Info plist of the driver in /Extra/Extensions: the IOProbeScore property and the OSBundleRequired property.
The general rule of thumb is that the IOProbescore should be increased from the default level, as the kext with the higher score gets loaded when there are 2 instances (as is common when you have one copy in /Extra/Extensions and another in /System/Library/Extensions)
Likewise for the kext to be loaded early in the proces, (as is the case with kexts in /Extra/Extensions) its OSBundleRequired property may need to be set to Root (or possibly Network-root?)

Device Property Strings
Device Property Strings are in the form of a single hex string. They are generated by converting information in plist format to hex & then pasting it into /Extra/com.apple.Boot.plist Typical uses for this are to inject values for graphics, network, and sound.

Device properties (also called devprops or EFI Strings) are an older technique introduced in PC-EFI, and do much the same thing as injectors, but do so wityhout loading an extra driver, so are preferred by some, and sometimes considered more "vanilla"

DSDT Patches
DSDT Patches modify the system's DSDT (Differentiated System Descriptor Tables) which is an ACPI table generally part of the machine's BIOS. Its purpose is to describe the hardware to the System so as to tell it how to distribute power to the various devices.
The patch is usually in the form of a DSDT.aml file, (this can be decompiled & recompiled with "IASL" see info on this elsewhere) Although in some instances it may be in the form of a kext.
The purpose of patching the DSDT is to change the way the system "sees" the hardware in order to improve its functioning with OS X, either by making the hardware appear more like a Mac or by fixing power
management bugs that stop OS X from booting. In some cases it can also be used to inject values to enable certain hardware such as a gfx or audio controller.

I too am used to the old way, I have not updated from munky's boot through EFI partition, because my system is stable and effective for everyday use. I have used it for almost 3 years, with the only change being a reload using the EFI partition. I feel the /Extra is a good compromise, but we should be utilizing the EFI partition instead of adding more to they system disk.

I know that should I ball things us, I can simply drop my retail disk in, hit esc, and boot from that DVD to repair/rebuild my system.

from the hobbyist's prospective /Extra may be easier, but from the I want a machine I can enjoy messing with and the satisfaction of I got it to run with only a disabler and the audio kext edited, I prefer using EFI.

Putting your files on the reformatted EFI system partition is just an added finesse to essentially the same technique, the rules pointed out (and to be elaborated on) above are equally true for this technique too. Just in the interest of accuracy, in no way are you "Using EFI" when you use this technique, it is simply another place from which you load your /Extra, it could equally be a ramdisk image, a usb stick, or a CDROM.

Updated and cleaned, please comment/adjust/correct/add as needed.. I think this is an important topic, and certainly not one on which I am the biggest expert. links and descriptions also welcome.

I hate /Extra.
1. If I have two partions with Leo and Snow and installed Chameleon 2 it uses common /Extra for both systems. Nonsense.
2. I have WiFi Broadcom 4315 which can work with vanilla driver but edited info,plist for new deviceID. Usually it is recommended create legacy kext and place it into /Extra. Yes, it works. But! If I forget to switch on Radio I can do it after the system is loaded. The driver is already loaded in system but not works. I need to do kextunload and then kextload. It works again.
Now a question. What kext I need to kextload? Legacy?! Vanilla? Nonsense. I need to kextload patched kext sitting in /System/Library/Extensions/

actually there's support for /Extra/10.5 & /Extra/10.6 paths for Extensions / Extensions.mkext

Chameleon 2.0 rc2 will probe the partition chosen to boot and select the correct path.

only useful when used on an EFI System partition install, and remove /Extra/Extensions and/or /Extra/Extensions.mkext.

i think you mean RC3,

it's a good news, i also don't like the way that chameleon choose the default /Extra folder, it should use the /extra folder on the partition that we booting onto

no rc2.

i don't understand , you mean rc2 already do that ??

since i have some problem with rc2 and snow, i use pcefi 10.1, so i don't really know about rc2 features

but if rc2 have this feature i will try it again

hi
yes rc2 does already contain this feature.

ok thank, i will try again

It is not obvious from official installation of RC2-640.pkg
RC3 - yes.

unfortunately thats part of the problem with chameleon .. no f'in docs.

seems the developers are more interested in glory than copying the docs from the wiki.

Back to the original topic -- the care and feeding of /Extra:
Here's a script that may be useful for managing /Extra. Note that it is meant only as a starting point and needs to be adapted for your own situation and care and feeding preferences, so to speak.
http://www.projectosx.com/forum/index.php?showtopic=570