]> code.delx.au - refind/blobdiff - docs/refind/todo.html
0.4.5 release
[refind] / docs / refind / todo.html
index 9201b69dfe3fb0c263a41ea47fa7263b3c4ca3f2..993af2dfc4e0f3f2b6cdc46763352b4ae4ef4619 100644 (file)
@@ -15,7 +15,7 @@
 href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
 
 <p>Originally written: 3/14/2012; last Web page update:
-5/20/2012, referencing rEFInd 0.4.0</p>
+8/12/2012, referencing rEFInd 0.4.5</p>
 
 
 <p>I'm a technical writer and consultant specializing in Linux technologies. This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!</p>
@@ -157,10 +157,30 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
        from the partition data is harder than extracting the volume's
        label or counting up the filesystem numbers.</li>
 
+    <li>The default_selection option in refind.conf could be improved by
+       supporting a list of default options, so that if the first item
+       isn't found, rEFInd will try to boot the second one in the list,
+       and so on. This could be handy in case a driver fails to load, or
+       to provide an override in case the user inserts a specific
+       removable disk&mdash;by placing the removable disk's name first in
+       the list, it will take precedence over the normal hard disk
+       default.</li>
+
+    <li>Along the lines of the previous item, the default_selection might
+       be expanded to support some form of specification of disk types, as
+       in a special entry for any optical disk or any external disk, no
+       matter what its name is.</li>
+
     <li>It would be useful to be able to specify paths to boot loaders
        and/or initial RAM disks relative to the rEFInd directory (or the
        boot loader's directory, in the case of initrds).</li>
 
+    <li>Various options (<tt>dont_scan_dirs</tt>, <tt>also_scan_dirs</tt>,
+       <tt>scan_driver_dirs</tt>, etc.) refer to directories or files,
+       either on the ESP or on all partitions. A way to identify specific
+       partitions for these options would be useful in some
+       situations.</li>
+
     </ul></li> <!-- Improvements -->
 
 <li><b>Known bugs that need squashing:</b>
@@ -193,9 +213,9 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
        implementation, and a dismal one at that, so I'm inclined to just
        let it go.</li>
 
-    <li>The Shutdown option works correctly on Macs, but not on UEFI-based PCs.
-        On such systems, Shutdown reboots the computer. This should be
-        fixed.</li>
+    <li>The Shutdown option works correctly on Macs, but not on UEFI-based
+       PCs. On such systems, Shutdown reboots the computer. This should be
+       fixed.</li>
 
     <li>The media-ejection feature (F12) should be extended to work on
        UEFI-based PCs and early Macs. At the moment, it relies on an
@@ -206,13 +226,19 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
        ignoring new media or keeping old media that have been ejected.
        This should be investigated and fixed.</li>
 
-    <li>The re-scan feature renders the user interface immobile until
-        the re-scan is complete. This is usually just a second or two,
-       but it can be longer if an optical disc needs to be spun up.
-       Adding a temporary "scanning media" notice would be helpful.</li>
+    <li>The "scanning for new boot loaders" message that appears during the
+       re-scan feature is primitive. Some sort of dynamic icon would be
+       nice, but perhaps impractical, given the single-tasking nature of
+       EFI.</li>
+
+    <li>On my Mac Mini, launching a shell, returning, and performing a
+       re-scan causes the system to be unable to launch the shell again. I
+       have not observed this behavior on UEFI-based PCs. It seems to be
+       caused by a truncated DevicePath to the shell, which includes the
+       shell's pathname but not the device identifier.</li>
 
     <li>The code is in need of review to search for memory leaks and
-       similar problems.</p>
+       similar problems.</li>
 
     </ul></li> <!-- Known bugs -->
 
@@ -237,8 +263,10 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
        forum thread</a> for more information.</li>
 
     <li>I'd like to find a way to enable users to enter customizations for
-       boot options and then save them to the <tt>refind.conf</tt>
-       file.</li>
+       boot options and then save them to the <tt>refind.conf</tt> file.
+       One possible way to implement this would be to have manual boot
+       stanzas override auto-detected boot loader definitions for the same
+       boot loader file.</li>
 
     <li>It should be possible to override specific auto-detected boot
        loader settings&mdash;say, to disable one specific boot loader or
@@ -256,27 +284,28 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
     <li>I'd like to give the user the ability to set custom options on a
        single-boot basis, similar to what's possible in GRUB.</li>
 
+    <li>A way to set the color of the font would be useful for theming
+        purposes.</li>
+
+    <li>Going further, the ability to load arbitrary other fonts, ideally
+        in a standard format, would be desirable for theming purposes.</li>
+
+    <li>A GUI configuration tool would be nice, but it's low on my personal
+       priority list. If you'd like to contribute, I prefer something
+       written in a cross-platform GUI toolkit, so that a single code base
+       can be used on any of the major OSes.</li>
+
+    <li>A way to "source" one configuration file from another one would be
+       helpful for some types of configuration scripts. (This would enable
+       overriding options in a secondary file without modifying the
+       default original file, for instance.)</li>
+
     </ul></li> <!-- New features -->
 
     <li><b>Improvements to the EFI drivers:</b>
 
     <ul>
 
-    <li>The drivers I've built fail to load on a 32-bit Mac Mini; I get an
-       "incompatible version" error message at an EFI shell, or an error
-       code of 80000019 when rEFInd tries to load them. (These two
-       messages are equivalent.) I suspect the problem is related to the
-       EFI version 1.<i>x</i> used on the Mac, as opposed to UEFI
-       2.<i>x</i> used on PCs. I'm looking into the problem. In the
-       meantime, if you have this problem, I recommend tracking down
-       equivalent drivers from other sources. (See the <a
-       href="drivers.html">drivers page</a> for some pointers.) I'd
-       appreciate <a href="mailto:rodsmith@rodsbooks.com">hearing from
-       you</a> if you have problems along these lines. Please tell me what
-       type of computer you're using, and especially the firmware version
-       data (from rEFInd's "about" screen). This may help me narrow down
-       the cause.</li>
-
     <li>Drivers for additional filesystems are required. Given the recent
        shift to ext4fs, that should be the priority; however, other Linux
        filesystems, UDF, and perhaps others would all be welcome
@@ -289,10 +318,17 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
        the problem is worst with VirtualBox, and the next worst is a
        system that uses <a
        href="http://www.rodsbooks.com/bios2uefi/">DUET</a>). Nonetheless,
-       I'd like to track down the cause and fix it.
+       I'd like to track down the cause and fix it.</li>
 
     <li>The driver installation procedure could be improved, perhaps by
-        adding support for drivers to the <tt>install.sh</tt> script.
+        adding support for drivers to the <tt>install.sh</tt> script.</li>
+
+    <li>The HFS+ driver returns a volume label of "HFS+ volume", no matter
+        what the volume's real label is.</li>
+
+    <li>This may not be possible, or it may require a new driver, but a way
+       to have the drivers access files (like a Linux loopback mount) is
+       desirable.</li>
 
     </ul></li> <!-- Drivers -->