]> code.delx.au - refind/blobdiff - docs/refind/todo.html
0.4.5 release
[refind] / docs / refind / todo.html
index 582de71cfe344fbfeb0e1618f6239ebbc3c9e814..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:
-6/21/2012, referencing rEFInd 0.4.3</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>
@@ -175,6 +175,12 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
        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>
@@ -231,11 +237,6 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
        caused by a truncated DevicePath to the shell, which includes the
        shell's pathname but not the device identifier.</li>
 
-    <li>The 32-bit build of rEFInd displays corrupted volume labels for
-       filesystems handled by built-in drivers, but not for the drivers
-       provided with rEFInd. This is presumably related to the 32-bit
-       driver bug noted below.</li>
-
     <li>The code is in need of review to search for memory leaks and
        similar problems.</li>
 
@@ -262,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
@@ -292,17 +295,17 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
        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 32-bit versions of the drivers return filesystem labels that
-       omit the first two characters of the name. If the name is shorter
-       than two characters, the driver may return the wrong volume's
-       label. The 64-bit builds seem to be unaffected by this bug.</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
@@ -323,6 +326,10 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
     <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 -->
 
 </ul>