chrisp
4th April 2006, 01:15 PM
I had a quick look at the code and am now looking for ways to integrate XOM and rEFIt. Basically this requires that rEFIt can tell xom.efi that it should not display its own menu and just boot Windows. I can see two ways to achieve this:
1. Have XOM accept command line options. '-s' to skip the built-in menu, '-h' to boot from hard disk only (no CD), '-c' to boot from CD only, '-v' to boot in verbose mode (i.e. enable the text console).
2. Separate XOM into a boot menu front-end and a Windows loader back-end. Have the two communicate via command line options as above. ('-s' would be unnecessary in this case, but some more switches to implement F1, F6 and F7.) rEFIt just calls the back-end loader.
Both solutions have their benifits and drawbacks. The first solution would be easier to implement short-term, and keeps xom.efi as an all-in-one standalone solution. The second solution would probably result in cleaner code for both parts, but also require some duplication of code.
As for the implementation: lib.c seems to contain some code to access command-line options. I don't think the code as it stands will do the right thing, though. As I understand the Shell Interface stuff, the shell installs the protocol on the child image handle, so you should look for the Shell protocol on the image's own handle. The existing code just searches for any Shell Interface protocol instances in the system, and will probably get the wrong instance.
Anyway, I believe it would be best to just parse the options from LoadedImage->LoadOptions. That's what elilo and Apple's boot.efi do, and it is easily implemented in front-ends like rEFIt.
1. Have XOM accept command line options. '-s' to skip the built-in menu, '-h' to boot from hard disk only (no CD), '-c' to boot from CD only, '-v' to boot in verbose mode (i.e. enable the text console).
2. Separate XOM into a boot menu front-end and a Windows loader back-end. Have the two communicate via command line options as above. ('-s' would be unnecessary in this case, but some more switches to implement F1, F6 and F7.) rEFIt just calls the back-end loader.
Both solutions have their benifits and drawbacks. The first solution would be easier to implement short-term, and keeps xom.efi as an all-in-one standalone solution. The second solution would probably result in cleaner code for both parts, but also require some duplication of code.
As for the implementation: lib.c seems to contain some code to access command-line options. I don't think the code as it stands will do the right thing, though. As I understand the Shell Interface stuff, the shell installs the protocol on the child image handle, so you should look for the Shell protocol on the image's own handle. The existing code just searches for any Shell Interface protocol instances in the system, and will probably get the wrong instance.
Anyway, I believe it would be best to just parse the options from LoadedImage->LoadOptions. That's what elilo and Apple's boot.efi do, and it is easily implemented in front-ends like rEFIt.