1 | TODO List for Chameleon Boot Loader␊ |
2 | ====================================␊ |
3 | - Fix the module system when booting chameleon with multiboot. Cleanup the xcode 4 fix.␊ |
4 | ␊ |
5 | - Integrate Prasys current work on options and quick shortcut modified version of 18seven␊ |
6 | ␊ |
7 | - Add auto-detection of efi string algorithm to enable graphics enabler to be enabled by default while not conflicting with other efi string overridden content␊ |
8 | (original idea of Galaxy)␊ |
9 | ␊ |
10 | - Add a more sophisticated acpi loading mechanism to enable loading custom acpi tables when dsdtdrop=y␊ |
11 | Here's a specification to think about:␊ |
12 | First we must care about if a forced DSDT full path has been specified (was the pb smith had in␊ |
13 | his first tries) and take it for the DSDT path as is.␊ |
14 | Then we have the case where no DSDT path was set where we run our usual DSDT search algorithm to find this file.␊ |
15 | In the latter case, the file has to be named DSDT.aml and be in one of the / /Extra or bt(0,0)/Extra directory.␊ |
16 | ␊ |
17 | Now a first idea to implement correctly the acpi tables loading would be:␊ |
18 | ␊ |
19 | Whatever the path was hardcoded in the DSDT option or was automatically found, we extract the path part of ␊ |
20 | the DSDT file that has been successfully found and we run a loop to enumerate all other acpi files in the same directory.␊ |
21 | Now for each acpi file found, we should compare the name with an existing acpi table found in the system that␊ |
22 | we would normally load and replace this usual injection by the content of the file.␊ |
23 | ␊ |
24 | Once DropDSDT=y is set, no other acpi table than dsdt is loaded, then it is the responsibility of user␊ |
25 | to provide any other acpi table.␊ |
26 | ␊ |
27 | - Add a new module capable of writing proprietary Chameleon data to ioreg:␊ |
28 | Using the DT__xxx() API, we will create a set of functions to write␊ |
29 | to log info, chameleon boot info to be retrieved by helper applications...␊ |
30 | the only public function for log info purpose of this module would be:␊ |
31 | logMessageToIOREG(...); // var args printf style format␊ |
32 | flushLogToIOREG(); // store a unique log info property to the ioreg␊ |
33 | ␊ |
34 | The preferred internal behavior of the log info ioreg buffer␊ |
35 | would be to store the messages in a consolidated buffer then only write once,␊ |
36 | this buffer (i.e just before call the kernel) with flushLogToIOREG();␊ |
37 | The other public function for writing chameleon boot info data would be:␊ |
38 | ␊ |
39 | verbose() should incorporate a call to logMessageToIOREG() ␊ |
40 | to permit helper applications to extract␊ |
41 | this log info (i.e: the chameleon system pref pane)␊ |
42 | ␊ |
43 | - Add API for displaying and logging messages like:␊ |
44 | ␊ |
45 | void verbose(...)␊ |
46 | {␊ |
47 | ...␊ |
48 | logMessageToIOREG("%s: %sn", title, s);␊ |
49 | ␊ |
50 | }␊ |
51 | ␊ |
52 | void display_and_log( const char* title, const char* msg) ␊ |
53 | {␊ |
54 | printf("%s: %sn", title, s);␊ |
55 | logMessageToIOREG(title,s);␊ |
56 | }␊ |
57 | ␊ |
58 | void deprecated(const char * s)␊ |
59 | {␊ |
60 | display_and_log("WARNING: Deprecated option",s); ␊ |
61 | sleep(1); ␊ |
62 | }␊ |
63 | ␊ |
64 | void error_message(const char * s)␊ |
65 | {␊ |
66 | display_and_log("ERROR",s); ␊ |
67 | getc();␊ |
68 | }␊ |
69 | ␊ |
70 | - Case insensitive parsing for the bootConfig options:␊ |
71 | should help the common/novice user to setup more easily.␊ |
72 | |