X-Git-Url: https://code.delx.au/refind/blobdiff_plain/65eb839a6d8d68a439056473a0d3728dfd39d2c4..05d641020fe8cea57fa41b9e19459727a463d0c0:/docs/refind/todo.html

diff --git a/docs/refind/todo.html b/docs/refind/todo.html
index 03bac98..42c3d42 100644
--- a/docs/refind/todo.html
+++ b/docs/refind/todo.html
@@ -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>
+1/16/2013, referencing rEFInd 0.6.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>
@@ -131,22 +131,20 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
 
     <ul>
 
+    <li>The support for booting legacy (BIOS) OSes on UEFI-based PCs
+	currently has a number of limitations. Most importantly, it works
+	off of the list of boot devices stored in the computer's NVRAM. I'd
+	prefer to have it scan disks and partitions, as the Mac's legacy
+	boot support does. Also, the UEFI legacy boot code presents empty
+	optical drives and uses generic icons rather than OS-specific
+	icons.</li>
+
     <li>Currently, rEFInd can detect whether it's compiled for <i>x</i>86
 	or <i>x</i>86-64 systems and displays this information in its
 	"About" screen (<tt>AboutrEFInd()</tt> in <tt>main.c</tt>). I'd
 	like to add detection for Itanium and ARM systems, but I have no
 	way to test such changes.</li>
 
-    <li>The code could be more flexible in its handling of the sizes of
-	various graphical elements, and particularly drawn text. Prior to
-	version 0.2.2, submenu text was invisible on UEFI-based PCs with
-	800x600 and smaller displays because of an inability to properly
-	crop the graphics fields that hold the text. With version 0.2.2,
-	I've put a band-aid on this problem by reducing the field size so
-	that it now works on 800x600 displays, but smaller displays still
-	suffer from this problem. This is just an example of the
-	inflexibility of certain layout issues within rEFInd.</li>
-
     <li>Although the ICNS file format used by rEFInd supports multiple
 	image sizes, if a size that rEFInd needs isn't present in the file,
 	rEFInd can't use the icon. The ability to scale images to the
@@ -157,6 +155,26 @@ 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>Currently, if a filesystem's label comes up empty, rEFInd
+	substitutes the size, so you get displays like <tt>boot
+	EFI\foo\bar.efi from 90 GiB volume</tt>. I'd like to add more
+	checks to substitute the GPT <i>partition</i> label if the
+	<i>filesystem</i> label comes up empty.</li>
+
+    <li>The <tt>default_selection</tt> option in <tt>refind.conf</tt> 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>
@@ -167,14 +185,6 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
 
     <ul>
 
-    <li>I'd like to find a way to get rEFInd to launch BIOS boot loaders on
-	UEFI-based systems. This option currently works only on
-	Macs&mdash;or at least, I've not gotten it to work on any of my
-	UEFI-based PCs. (I've done some experiments to try to get this to
-	work, but so far without success. If you'd like to help on this, <a
-	href="mailto:rodsmith@rodsbooks.com">e-mail me</a> for my
-	thoughts.)</li>
-
     <li>The <a href="http://www.rodsbooks.com/gb-hybrid-efi/">Gigabyte
 	Hybrid EFI</a> has a bug that causes the allegedly case-insensitive
 	<tt>StriCmp()</tt> function to perform a case-sensitive comparison.
@@ -193,17 +203,39 @@ 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 many 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
 	Apple-specific EFI extension, and I know of no standard EFI way to
 	do it.</li>
 
+    <li>The re-scan feature occasionally produces odd results, such as
+	ignoring new media or keeping old media that have been ejected.
+	This should be investigated and fixed.</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>When specifying a volume by name in <tt>dont_scan_dirs</tt>,
+	slashes are converted to backslashes in the specification but not
+	in the actual volume name read from disk. Thus, you can't specify a
+	volume by name if it includes a slash (as in <tt>Fedora
+	/boot</tt>). Workarounds are to rename the volume to omit the slash
+	and to use a filesystem number rather than a volume label.</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 -->
 
@@ -228,49 +260,48 @@ 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>I have thoughts about creating an EFI configuration tool and
+	information utility&mdash;something to tell you about your hard
+	disks, enable you to manage MOKs, adjust boot loader priority in
+	the NVRAM, and so on. This would be useful in system maintenance
+	and in recovering from boot problems.</li>
+
+    <li>An installation tool for the EFI environment would be useful.
+        A simple EFI shell script might work, but because this function
+	requires access to the <tt>bcfg</tt> command, this would work
+	only from a version 2 shell or if <tt>bcfg</tt> were implemented
+	as a standalone program. Another alternative would be a program
+	written in C.</li>
 
     <li>It should be possible to override specific auto-detected boot
 	loader settings&mdash;say, to disable one specific boot loader or
 	change its icon.</li>
 
-    <li>A way to read boot options set via <tt>efibootmgr</tt>,
-	<tt>bless</tt>, or similar options from NVRAM to add to the boot
-	set would be useful.</li>
+    <li>A way to set the color of the font would be useful for theming
+        purposes.</li>
 
-    <li>A way to examine and change the NVRAM settings could be useful.
-	This would enable a CD-based boot of rEFInd to fix a broken disk
-	boot. Perhaps this could be done via a separate tool that could be
-	launched much like the shell or <tt>gptsync</tt>.</li>
+    <li>Going further, the ability to load arbitrary other fonts, ideally
+        in a standard format, would be desirable for theming purposes.</li>
 
-    <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 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>
 
     </ul></li> <!-- New features -->
 
-    <li><b>Improvements to the EFI drivers:</b>
+<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
+    <li>Drivers for additional filesystems are desirable. Given the talk of
+	shifting to Btrfs, that should be the priority; however, other
+	Linux filesystems, UDF, and perhaps others would all be welcome
 	additions. Also along these lines, adding drivers for Linux LVM and
 	RAID setups would be useful, too.</li>
 
@@ -280,10 +311,22 @@ 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 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>
 
-    <li>The driver installation procedure could be improved, perhaps by
-        adding support for drivers to the <tt>install.sh</tt> script.
+    <li>When built with the GNU-EFI package, an attempt to load more than
+        one driver on my 32-bit Mac Mini causes the computer to hang. I do
+	<i>not</i> have this problem with 64-bit drivers on my UEFI-based
+	computers. I don't know if this is a 32-bit issue or a Mac issue.
+	This is <i>not</i> relevant if you're using my binary package,
+	since I build it with the TianoCore EDK2, and the drivers built in
+	that way don't exhibit this bug.</li>
 
     </ul></li> <!-- Drivers -->
 
@@ -291,7 +334,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
 
 <hr />
 
-<p>copyright &copy; 2012 by Roderick W. Smith</p>
+<p>copyright &copy; 2012&ndash;2013 by Roderick W. Smith</p>
 
 <p>This document is licensed under the terms of the <a href="FDL-1.3.txt">GNU Free Documentation License (FDL), version 1.3.</a></p>