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