keyboard handling code.
* Stefan Agner (stefan@agner.ch) turned the original ext2fs/ext3fs driver
into one that can read ext4fs.
-* Samuel Liao ported the GRUB 2 Btrfs code into an EFI driver and
- contributed it to this project.
+* Samuel Liao ported the GRUB 2 Btrfs and NTFS code into EFI drivers and
+ contributed them to this project, along with several miscellaneous
+ improvements.
* Emerson Barcelos (emerson_freitas@yahoo.com.br) wrote the code for
enabling Intel VMX support (the enable_and_lock_vmx token in
mainly because it compiled cleanly with no extra work, aside from
providing a Makefile entry for it.</li>
+<li><b>NTFS</b>—Samuel Liao contributed this driver, which uses the
+ rEFIt/rEFInd driver framework. My own testing of it is limited, but it
+ does work for me. Note that this driver is <i><b>not</b></i> required
+ to boot Windows with rEFInd, since Windows stores its boot loader on
+ the (FAT) ESP. You might use this driver if you want to store large
+ boot files, such as EFI-accessible RAM disk images, from Windows.</li>
+
</ul>
<p>All of these drivers rely on filesystem wrapper code written by rEFIt's author, Christoph Phisterer.</p>
<ul>
-<li><b><a href="https://github.com/pbatard/efifs">Pete Batard's efifs drivers</a></b>—This project is an EFI driver wrapper around GRUB 2's filesystem drivers. Once compiled, the result is that GRUB 2's drivers become standalone EFI filesystem drivers, loadable independently or by rEFInd. (rEFInd version 0.8.3 or later is required.) At present (early July, 2014), several drivers, including NTFS, exFAT, JFS, and XFS, are usable, albeit with some caveats. For instance, using a <tt>root=UUID={uuid-value}</tt> specification to tell a Linux kernel about its root partition doesn't work, although <tt>root=PARTUUID={guid=value}</tt> does work, as does <tt>root=/dev/sd{xy}</tt>. I have no doubt that these drivers will improve rapidly in usability in the near future.</li>
+<li><b><a href="http://efi.akeo.ie">Pete Batard's efifs drivers</a></b>—This project is an EFI driver wrapper around GRUB 2's filesystem drivers. Once compiled, the result is that GRUB 2's drivers become standalone EFI filesystem drivers, loadable independently or by rEFInd. (rEFInd version 0.8.3 or later is required.) At present (driver version 0.7; January 2015), several drivers, including NTFS, exFAT, ext2fs, ReiserFS, Btrfs, JFS, and XFS, are usable, albeit with some caveats. Some drivers are slow, and they hang on some computers, such as one of my Macs. I have no doubt that these drivers will improve rapidly in usability in the near future. Note that the ext2fs driver from this set works with ext3fs and ext4fs, too. In addition to the main link, you can check the <a href="https://github.com/pbatard/efifs">github repository</a> for the source code.</li>
<li><b><a href="http://refit.sourceforge.net">rEFIt's ext2fs and ReiserFS drivers</a></b>—You can gain read-only access to ext2fs, ext3fs, and ReiserFS volumes with these drivers, originally written by Christoph Pfisterer. You can use the binaries in the <tt>refit-bin-0.14/efi/tools/drivers</tt> directory of the binary package directly on a Mac. On a UEFI-based PC, though, you'll need to break the Mac-style "fat" binary into its 32- and 64-bit components. You can use my <a href="http://www.rodsbooks.com/thin/index.html"><tt>thin</tt></a> program for this job. As a practical matter, there's no advantage to using these drivers over rEFInd's drivers, since the latter are updated versions of the former.</li>
</ul>
-<p>Most of these cross-project drivers appear to be related, and most of them have fed into rEFInd's drivers. I used the Clover package, which in turn was based on the VirtualBox drivers, as a starting point. Everybody else has dropped rEFIt's original ReiserFS driver, but I added that back. Of these drivers, only the Clover EFI Tools NTFS driver is missing from rEFInd. Specific versions can have their own quirks, though. For instance, the Clover (and I suspect VirtualBox) drivers don't return volume labels, which causes rEFInd to display loaders on those volumes as being on a disk called <tt>Unknown</tt>. (I fixed that bug for rEFInd's version, and it wasn't present in the original rEFIt drivers.) Most of these drivers also suffer from speed problems on some computers. This is worst with the ext2fs drivers under VirtualBox; on my main computer, that combination takes 3 minutes to load a Linux kernel and initial RAM disk file! Most real computers don't suffer nearly so badly, but some can take an extra five seconds or so to boot a kernel. I've fixed the speed problems in rEFInd's drivers as of version 0.7.0.</p>
-
-<p>Driver availability could increase in the future. Source code to a wide variety of filesystems is available in GRUB Legacy, GRUB 2, Linux, various BSD kernels, and in other projects. Sooner or later somebody's likely to begin porting those drivers to EFI. If you do so, or if you know of additional EFI drivers, please <a href="mailto:rodsmith@rodsbooks.com">tell me about it,</a> so I can share the information here. Likewise if you know of a source for other EFI drivers—say, for a video card or disk controller card.</p>
+<p>The rEFIt, Clover, and VirtualBox drivers are related, and all of them
+have fed into rEFInd's drivers. Specific versions can have their own
+quirks, though. For instance, the Clover (and I suspect VirtualBox) drivers
+don't return volume labels, which causes rEFInd to display loaders on those
+volumes as being on a disk called <tt>Unknown</tt>. (I fixed that bug for
+rEFInd's version, and it wasn't present in the original rEFIt drivers.)
+Most of these drivers also suffer from speed problems on some computers.
+This is worst with the ext2fs drivers under VirtualBox; on my main
+computer, that combination takes 3 minutes to load a Linux kernel and
+initial RAM disk file! Most real computers don't suffer nearly so badly,
+but some can take an extra five seconds or so to boot a kernel. I've fixed
+the speed problems in rEFInd's drivers as of version 0.7.0.</p>
+
+<p>Driver availability could increase in the future. If you know of
+additional EFI drivers, please <a href="mailto:rodsmith@rodsbooks.com">tell
+me about them,</a> so I can share the information here. Likewise if you
+know of a source for other EFI drivers—say, for a video card or disk
+controller card.</p>
<p>Once you've obtained an EFI driver, you can install it in rEFInd just as you would install rEFInd's own drivers, as described earlier.</p>
<h2>Notes on Specific Drivers</h2>
</a>
-<p>I've tested several of the drivers described on this page on a handful of systems. The Pfisterer ext2fs driver (from any source) works on both ext2fs and ext3fs, but not on ext4fs—but Agner's derivative ext4fs driver handles ext4fs, so that's not a problem. The ReiserFS driver is obviously useful only on ReiserFS partitions. (Reiser4 is not supported, as far as I know.) The Btrfs driver is the newest of the lot, and so I've tested it the least, but it's worked for me on two test systems. Given that ext2fs, ext3fs, and ReiserFS are getting a bit on in age by Linux standards, you might do well to use them on a separate Linux <tt>/boot</tt> partition; however, if you're willing to use ext3fs, ext4fs, Btrfs, or ReiserFS on your root (<tt>/</tt>) filesystem, you can use the EFI drivers to read your kernel from it. Note that this assumes you use conventional partitions; to the best of my knowledge, there's no EFI driver for Linux's Logical Volume Manager (LVM) or Redundant Array of Independent Disks (RAID) configurations, so the EFI can't access filesystems stored in these ways.</p>
-
-<p>As noted earlier, rEFInd's drivers prior to version 0.7.0, as well as related drivers from rEFIt, Clover, and VirtualBox, suffer from speed problems. These problems are mostly minor, adding a second or two to boot times; but on some computers, the speed problems can be dramatic, boosting kernel-load times up to as much as three minutes (under VirtualBox). If you run into excessive boot times with such a driver, try switching to the latest rEFInd driver instead.</p>
+<p>I've tested several of the drivers described on this page on a handful
+of systems. The Pfisterer ext2fs driver (from any source) works on both
+ext2fs and ext3fs, but not on ext4fs—but Agner's derivative ext4fs
+driver handles ext4fs, so that's not a problem. The ReiserFS driver is
+obviously useful only on ReiserFS partitions. (Reiser4 is not supported, as
+far as I know.) The Btrfs driver is the newest of the Linux filesystem
+drivers included with rEFInd, and so I've tested it the least, but it's
+worked for me on several test systems. Given that ext2fs, ext3fs, and
+ReiserFS are getting a bit on in age by Linux standards, you might do well
+to use them on a separate Linux <tt>/boot</tt> partition; however, if
+you're willing to use ext3fs, ext4fs, Btrfs, or ReiserFS on your root
+(<tt>/</tt>) filesystem, you can use the EFI drivers to read your kernel
+from it. Note that this assumes you use conventional partitions; to the
+best of my knowledge, there's no EFI driver for Linux's Logical Volume
+Manager (LVM) or Redundant Array of Independent Disks (RAID)
+configurations, so the EFI can't access filesystems stored in these
+ways.</p>
+
+<p>As noted earlier, rEFInd's drivers prior to version 0.7.0, as well as related drivers from rEFIt, Clover, and VirtualBox, suffer from speed problems. These problems are mostly minor, adding a second or two to boot times; but on some computers, the speed problems can be dramatic, boosting kernel-load times up to as much as three minutes (under VirtualBox). If you run into excessive boot times with such a driver, try switching to the latest rEFInd driver instead. You might also try Pete Batard's efifs drivers.</p>
<p>Although ext2fs, ext3fs, ext4fs, and ReiserFS are all case-sensitive, these drivers treat them in a case-insensitive way. Symbolic links work; however, rEFInd 0.6.11 and later ignore symbolic links, since many distributions use them in a way that creates redundant or non-functional entries in the rEFInd menu. You should be able to use hard links if you want to use a single kernel file in multiple ways (say for two distributions).</p>
<li class="tight"><a href="#winprob">Fixing Windows Boot Problems</a></li>
-<li class="tight"><a href="#uninstalling">Uninstalling rEFInd</a></li>
+<li class="tight"><a href="#uninstalling">Uninstalling rEFInd</a>
-</ul>
+ <ul>
+
+ <li class="tight"><a href="#uinst_linux">Uninstalling rEFInd from Linux</a></li>
+
+ <li class="tight"><a href="#uinst_osx">Uninstalling rEFInd from OS X</a></li>
+
+ <li class="tight"><a href="#uinst_windows">Uninstalling rEFInd from Windows</a></li>
+
+ <li class="tight"><a href="#post_uninst">Post-Uninstallation Activity (UEFI-Based PCs)</a></li>
+
+</ul></ul></li>
</div>
<h2>Uninstalling rEFInd</h2>
</a>
-<p>If you decide you don't want to keep rEFInd, you can uninstall it. Doing so is a matter of removing the rEFInd files from your ESP (or from your OS X boot partition, if you installed the program there). In Linux, a command like the following, typed as <tt>root</tt>, should do the trick:</p>
+<p>If you decide you don't want to keep rEFInd, you can uninstall it. Doing so is a matter of removing the rEFInd files from your ESP (or from your OS X boot partition, if you installed the program there). The exact details of how to do this vary from one OS to another, though; and in some cases there are alternatives to completely uninstalling rEFInd that are easier to implement.</p>
+
+<a name="uinst_linux">
+<h3>Uninstalling rEFInd from Linux</h3>
+</a>
+
+<p>In Linux, a command like the following, typed as <tt>root</tt>, should remove rEFInd:</p>
<pre class="listing">
# <tt class="userinput">rm -r /boot/efi/EFI/refind</tt>
</pre>
-<p>This example assumes that your ESP is mounted at <tt>/boot/efi</tt> and that rEFInd is installed in <tt>EFI/refind</tt> on that partition. If you've mounted your ESP elsewhere, or installed rEFInd elsewhere, you should adjust the command appropriately.</p>
+<p>You must type this command as <tt>root</tt> (or use <tt>sudo</tt> in some environments, such as under Ubuntu). This example assumes that your ESP is mounted at <tt>/boot/efi</tt> and that rEFInd is installed in <tt>EFI/refind</tt> on that partition. If you've mounted your ESP elsewhere, or installed rEFInd elsewhere, you should adjust the command appropriately.</p>
-<p>The same procedure works in OS X, with the caveat that the ESP isn't normally mounted in OS X. Thus, you must first mount the ESP, as described earlier, in the section on <a href="#osx">manually installing rEFInd in OS X.</a> (You can forego this step if you installed to the OS X root partition.) You'll also need to use <tt>sudo</tt> to acquire <tt>root</tt> privileges. Thus, you'd probably use a command like the following in OS X:</p>
+<p>If you installed via an RPM or Debian package in Linux, using your package manager will remove the package files, but not the files that the installer places on your ESP. Thus, you must uninstall those files manually, as just described. To complete the job, you'll also have to remove <tt>/boot/refind_linux.conf</tt>, and perhaps the <tt>/etc/refind.d</tt> directory.</p>
-<pre class="listing">
-$ <tt class="userinput">sudo rm -r /Volumes/esp/EFI/refind</tt>
-</pre>
+<a name="uinst_osx">
+<h3>Uninstalling rEFInd from OS X</h3>
+</a>
-<p>Many variants of both of these commands are possible on both OS X and Linux. For instance, you'd probably use <tt>sudo</tt> on Ubuntu. Note that dragging the rEFInd files to the Trash in OS X does <i>not</i> delete them; it just moves them to a different folder. Given the way that Macs reference boot loaders, this means that rEFInd may still launch. If you want to use the Finder to delete rEFInd, be sure to empty the trash after you drag the files there. That should do the job, provided there's no second installation hiding somewhere.</p>
+<p>The easiest way to restore the standard OS X boot loader on a Mac is not to uninstall rEFInd; it's to bypass it. This can be accomplished with the Startup Disk item in the System Preferences panel:</p>
-<p>If you installed via an RPM or Debian package in Linux, using your package manager will remove the package files, but not the files that the installer places on your ESP. Thus, you must uninstall those files manually, as just described. To complete the job, you'll also have to remove <tt>/boot/refind_linux.conf</tt>, and perhaps the <tt>/etc/refind.d</tt> directory.</p>
+ <br /><center><img src="startup-disk.png" align="center" width="668"
+ height="355" alt="The OS X Startup Disk tool enables you to reset a Mac
+ to use the standard OS X boot loader." border=2> </center><br />
+
+<p>Select your startup disk (<i>Macintosh HD OS X, 10.10.1</i> in this example) and then click Restart. The computer should reboot into OS X, bypassing rEFInd.</p>
+
+<p>I recommend stopping here, because the procedure for completely removing rEFInd from a Mac depends on your installation method and tends to be challenging for many Mac users, who are unfamiliar with the necessary command-line tools. Basically, you must reverse the steps described earlier, in <a href="#osx">Installing rEFInd Manually Using Mac OS X:</a></p>
+
+<ol>
+
+<li>You must first determine where rEFInd is installed. If you used the
+ default installation location, this will be <tt>/EFI/refind</tt> on
+ your main partition if you installed rEFInd 0.8.3 or earlier, or in
+ <tt>EFI/refind</tt> or <tt>EFI/BOOT</tt> on the ESP if you installed
+ rEFInd 0.8.4 with the default options. If you used the
+ <tt>--ownhfs</tt> option, rEFInd will be in the
+ <tt>System/Library/CoreServices</tt> directory on the volume you
+ specified.</li>
+
+<li>If necessary, mount the ESP or rEFInd-specific HFS+ volume, as
+ described in <a href="#osx">Installing rEFInd Manually Using Mac OS
+ X.</a></li>
+
+<li>Verify that rEFInd is installed in the directory noted in step #1. If a
+ <tt>refind.conf</tt> file is present, rEFInd is almost certainly
+ installed in that directory. If not, it's not rEFInd there and you
+ should <i>not</i> proceed. <b><i>Be extra cautious about deleting the
+ <tt>System/Library/CoreServices</tt> directory,</i></b> since that's
+ the default location of the OS X boot loader!</li>
+
+<li>Once you've identified the rEFInd directory, delete it, or at least the
+ rEFInd boot file. This file may be called <tt>refind_x64.efi</tt>,
+ <tt>bootx64.efi</tt>, <tt>boot.efi</tt>, or conceivably something else.
+ You may need to use <tt>sudo rm</tt> at the command line to accomplish
+ this task, as in <tt class="userinput">sudo rm -r
+ /Volumes/esp/EFI/refind</tt>. Note that dragging files to the Trash on
+ the Desktop may not be adequate unless you also empty the Trash.</li>
+
+</ol>
+
+<a name="uinst_windows">
+<h3>Uninstalling rEFInd from Windows</h3>
+</a>
<p>From Windows, you must reverse the directions for <a href="#windows">installing in Windows</a>—type <tt class="userinput">mountvol S: /S</tt> to mount your ESP as <tt>S:</tt>, then navigate to the <tt>S:\EFI</tt> directory and delete the <tt>refind</tt> subdirectory.</p>
-<p>In any of these cases, when the computer boots and cannot find the rEFInd files, it should move on to the next boot loader in its list. In my experience, some EFI firmware implementations remove boot loaders they can't find from their NVRAM lists, so nothing else will be required, provided you have another working boot loader in your firmware's list. If your firmware doesn't automatically clean up its NVRAM entries, rEFInd's entry will do little harm; however, you can delete it with the <tt>efibootmgr</tt> utility in Linux:</p>
+<a name="post_uninst">
+<h3>Post-Uninstallation Activity (UEFI-Based PCs)</h3>
+</a>
+
+<p>On a UEFI-based PC, when the computer boots and cannot find the rEFInd files, it should move on to the next boot loader in its list. In my experience, some EFI firmware implementations remove boot loaders they can't find from their NVRAM lists, so nothing else will be required, provided you have another working boot loader in your firmware's list. If your firmware doesn't automatically clean up its NVRAM entries, rEFInd's entry will do little harm; however, you can delete it with the <tt>efibootmgr</tt> utility in Linux:</p>
<pre class="listing">
# <tt class="userinput">efibootmgr --verbose</tt>
<p>This example shows use of <tt>efibootmgr</tt>'s <tt>--verbose</tt> (<tt>-v</tt>) option to display boot programs so as to identify which one is rEFInd, followed by <tt>--delete-bootnum</tt> (<tt>-B</tt>) to delete a boot program and <tt>--bootnum</tt> (<tt>-b</tt>) to identify which one to delete. Of course, in this example there's not much else left, so you'd presumably want to install another boot program at this point! If you already have another one installed, you may want to check the <tt>BootOrder</tt> line to determine which one will take precedence when you reboot. If you don't like what it shows, you can adjust it with the <tt>--bootorder</tt> (<tt>-o</tt>) option; consult <tt>efibootmgr</tt>'s <tt>man</tt> page for details.</p>
-<p>If you're not using Linux, you may be able to find a utility that serves a similar function. The OS X <tt>bless</tt> utility (or its GUI equivalent, the Startup Disk item in System Preferences) should do the trick; but Macs pick up standard OS X boot loaders when they boot and find that a configured non-standard boot loader is missing, so this shouldn't be necessary on Macs. Under Windows, the <tt>bcdedit</tt> command, described in the <a href="#windows">section on installing rEFInd under Windows,</a> may work, although I've not attempted this.</p>
+<p>If you're not using Linux, you may be able to find a utility that serves
+a similar function. Under Windows, the <tt>bcdedit</tt> command, described
+in the <a href="#windows">section on installing rEFInd under Windows,</a>
+may work, although I've not attempted this.</p>
<hr />
-<p>copyright © 2012–2014 by Roderick W. Smith</p>
+<p>copyright © 2012–2015 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>
<li>jamaladdeen on deviantART has created an <a href="http://jamaladdeen.deviantart.com/art/rEFInd-OSX-Standard-Theme-1-0-492876132?ga_submit_new=10%253A1415269035&ga_type=edit&ga_changes=1&ga_recent=1">OS X theme</a> that resembles the OS X environment.</li>
+<li>Brian Lechthaler has created an <a href="http://sta.sh/0raifz8774v">alternative rEFInd banner.</a>
+
</ul>
<p>If you've created or discovered another rEFInd theme, please <a href="mailto:rodsmith@rodsbooks.com">tell me about it</a> so that I can provide a link to it from this page.</p>
INSTALL_DIR = /boot/efi/EFI/refind/drivers
-FILESYSTEMS = ext2 ext4 reiserfs iso9660 hfs btrfs
-FILESYSTEMS_GNUEFI = ext2_gnuefi ext4_gnuefi reiserfs_gnuefi iso9660_gnuefi hfs_gnuefi btrfs_gnuefi
+FILESYSTEMS = ext2 ext4 reiserfs iso9660 hfs btrfs ntfs
+FILESYSTEMS_GNUEFI = ext2_gnuefi ext4_gnuefi reiserfs_gnuefi iso9660_gnuefi hfs_gnuefi btrfs_gnuefi ntfs_gnuefi
TEXTFILES = $(FILESYSTEMS:=*.txt)
# Build the drivers with TianoCore EDK2.....
rm -f fsw_efi.obj
+make DRIVERNAME=btrfs -f Make.tiano
+ntfs:
+ rm -f fsw_efi.obj
+ +make DRIVERNAME=ntfs -f Make.tiano
+
# Build the drivers with GNU-EFI....
gnuefi: $(FILESYSTEMS_GNUEFI)
rm -f fsw_efi.o
+make DRIVERNAME=btrfs -f Make.gnuefi
+ntfs_gnuefi:
+ rm -f fsw_efi.o
+ +make DRIVERNAME=ntfs -f Make.gnuefi
+
# utility rules
clean:
/* slave device got empty root */
if(dno->raw == NULL) {
sb->used_bytes = 0;
- sb->store_time_posix(sb, FSW_DNODE_STAT_CTIME, 0);
- sb->store_time_posix(sb, FSW_DNODE_STAT_ATIME, 0);
- sb->store_time_posix(sb, FSW_DNODE_STAT_MTIME, 0);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_CTIME, 0);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_ATIME, 0);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_MTIME, 0);
return FSW_SUCCESS;
}
sb->used_bytes = fsw_u64_le_swap(dno->raw->nbytes);
- sb->store_time_posix(sb, FSW_DNODE_STAT_ATIME,
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_ATIME,
fsw_u64_le_swap(dno->raw->atime.sec));
- sb->store_time_posix(sb, FSW_DNODE_STAT_CTIME,
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_CTIME,
fsw_u64_le_swap(dno->raw->ctime.sec));
- sb->store_time_posix(sb, FSW_DNODE_STAT_MTIME,
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_MTIME,
fsw_u64_le_swap(dno->raw->mtime.sec));
- sb->store_attr_posix(sb, fsw_u32_le_swap(dno->raw->mode));
+ fsw_store_attr_posix(sb, fsw_u32_le_swap(dno->raw->mode));
return FSW_SUCCESS;
}
vol->extend = vol->extstart + fsw_u64_le_swap (vol->extent->size);
if (vol->extent->type == GRUB_BTRFS_EXTENT_REGULAR
- && (char *) &vol->extent + elemsize
+ && (char *) vol->extent + elemsize
>= (char *) &vol->extent->filled + sizeof (vol->extent->filled))
vol->extend =
vol->extstart + fsw_u64_le_swap (vol->extent->filled);
struct fsw_dnode_stat {
fsw_u64 used_bytes; //!< Bytes actually used by the file on disk
- void (*store_time_posix)(struct fsw_dnode_stat *sb, int which, fsw_u32 posix_time); //!< Callback for storing a Posix-style timestamp
- void (*store_attr_posix)(struct fsw_dnode_stat *sb, fsw_u16 posix_mode); //!< Callback for storing a Posix-style file mode
void *host_data; //!< Hook for a host-specific data structure
};
fsw_status_t fsw_dnode_readlink(struct fsw_dnode *dno, struct fsw_string *link_target);
fsw_status_t fsw_dnode_readlink_data(struct DNODESTRUCTNAME *dno, struct fsw_string *link_target);
fsw_status_t fsw_dnode_resolve(struct fsw_dnode *dno, struct fsw_dnode **target_dno_out);
+void fsw_store_time_posix(struct fsw_dnode_stat *sb, int which, fsw_u32 posix_time);
+void fsw_store_attr_posix(struct fsw_dnode_stat *sb, fsw_u16 posix_mode);
+void fsw_store_attr_efi(struct fsw_dnode_stat *sb, fsw_u16 attr);
/*@}*/
* appropriate member of the EFI_FILE_INFO structure that we're filling.
*/
-static void fsw_efi_store_time_posix(struct fsw_dnode_stat *sb, int which, fsw_u32 posix_time)
+void fsw_store_time_posix(struct fsw_dnode_stat *sb, int which, fsw_u32 posix_time)
{
EFI_FILE_INFO *FileInfo = (EFI_FILE_INFO *)sb->host_data;
* adjustments to the EFI_FILE_INFO structure that we're filling.
*/
-static void fsw_efi_store_attr_posix(struct fsw_dnode_stat *sb, fsw_u16 posix_mode)
+void fsw_store_attr_posix(struct fsw_dnode_stat *sb, fsw_u16 posix_mode)
{
EFI_FILE_INFO *FileInfo = (EFI_FILE_INFO *)sb->host_data;
FileInfo->Attribute |= EFI_FILE_READ_ONLY;
}
+void fsw_store_attr_efi(struct fsw_dnode_stat *sb, fsw_u16 attr)
+{
+ EFI_FILE_INFO *FileInfo = (EFI_FILE_INFO *)sb->host_data;
+
+ FileInfo->Attribute |= attr;
+}
+
/**
* Common function to fill an EFI_FILE_INFO with information about a dnode.
*/
// get the missing info from the fs driver
ZeroMem(&sb, sizeof(struct fsw_dnode_stat));
- sb.store_time_posix = fsw_efi_store_time_posix;
- sb.store_attr_posix = fsw_efi_store_attr_posix;
sb.host_data = FileInfo;
Status = fsw_efi_map_status(fsw_dnode_stat(dno, &sb), Volume);
if (EFI_ERROR(Status))
struct fsw_dnode_stat *sb)
{
sb->used_bytes = dno->raw->i_blocks * 512; // very, very strange...
- sb->store_time_posix(sb, FSW_DNODE_STAT_CTIME, dno->raw->i_ctime);
- sb->store_time_posix(sb, FSW_DNODE_STAT_ATIME, dno->raw->i_atime);
- sb->store_time_posix(sb, FSW_DNODE_STAT_MTIME, dno->raw->i_mtime);
- sb->store_attr_posix(sb, dno->raw->i_mode);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_CTIME, dno->raw->i_ctime);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_ATIME, dno->raw->i_atime);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_MTIME, dno->raw->i_mtime);
+ fsw_store_attr_posix(sb, dno->raw->i_mode);
return FSW_SUCCESS;
}
struct fsw_dnode_stat *sb)
{
sb->used_bytes = dno->raw->i_blocks_lo * EXT4_BLOCK_SIZE(vol->sb); // very, very strange...
- sb->store_time_posix(sb, FSW_DNODE_STAT_CTIME, dno->raw->i_ctime);
- sb->store_time_posix(sb, FSW_DNODE_STAT_ATIME, dno->raw->i_atime);
- sb->store_time_posix(sb, FSW_DNODE_STAT_MTIME, dno->raw->i_mtime);
- sb->store_attr_posix(sb, dno->raw->i_mode);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_CTIME, dno->raw->i_ctime);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_ATIME, dno->raw->i_atime);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_MTIME, dno->raw->i_mtime);
+ fsw_store_attr_posix(sb, dno->raw->i_mode);
return FSW_SUCCESS;
}
struct fsw_dnode_stat *sb)
{
sb->used_bytes = dno->used_bytes;
- sb->store_time_posix(sb, FSW_DNODE_STAT_CTIME, mac_to_posix(dno->ctime));
- sb->store_time_posix(sb, FSW_DNODE_STAT_MTIME, mac_to_posix(dno->mtime));
- sb->store_time_posix(sb, FSW_DNODE_STAT_ATIME, 0);
- sb->store_attr_posix(sb, 0700);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_CTIME, mac_to_posix(dno->ctime));
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_MTIME, mac_to_posix(dno->mtime));
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_ATIME, 0);
+ fsw_store_attr_posix(sb, 0700);
return FSW_SUCCESS;
}
{
sb->used_bytes = (dno->g.size + (ISO9660_BLOCKSIZE-1)) & ~(ISO9660_BLOCKSIZE-1);
/*
- sb->store_time_posix(sb, FSW_DNODE_STAT_CTIME, dno->raw->i_ctime);
- sb->store_time_posix(sb, FSW_DNODE_STAT_ATIME, dno->raw->i_atime);
- sb->store_time_posix(sb, FSW_DNODE_STAT_MTIME, dno->raw->i_mtime);
- sb->store_attr_posix(sb, dno->raw->i_mode);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_CTIME, dno->raw->i_ctime);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_ATIME, dno->raw->i_atime);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_MTIME, dno->raw->i_mtime);
+ fsw_store_attr_posix(sb, dno->raw->i_mode);
*/
return FSW_SUCCESS;
sb->used_bytes = 0;
else
sb->used_bytes = dno->sd_v1->u.sd_blocks * vol->g.log_blocksize;
- sb->store_time_posix(sb, FSW_DNODE_STAT_CTIME, dno->sd_v1->sd_ctime);
- sb->store_time_posix(sb, FSW_DNODE_STAT_ATIME, dno->sd_v1->sd_atime);
- sb->store_time_posix(sb, FSW_DNODE_STAT_MTIME, dno->sd_v1->sd_mtime);
- sb->store_attr_posix(sb, dno->sd_v1->sd_mode);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_CTIME, dno->sd_v1->sd_ctime);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_ATIME, dno->sd_v1->sd_atime);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_MTIME, dno->sd_v1->sd_mtime);
+ fsw_store_attr_posix(sb, dno->sd_v1->sd_mode);
} else if (dno->sd_v2) {
sb->used_bytes = dno->sd_v2->sd_blocks * vol->g.log_blocksize;
- sb->store_time_posix(sb, FSW_DNODE_STAT_CTIME, dno->sd_v2->sd_ctime);
- sb->store_time_posix(sb, FSW_DNODE_STAT_ATIME, dno->sd_v2->sd_atime);
- sb->store_time_posix(sb, FSW_DNODE_STAT_MTIME, dno->sd_v2->sd_mtime);
- sb->store_attr_posix(sb, dno->sd_v2->sd_mode);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_CTIME, dno->sd_v2->sd_ctime);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_ATIME, dno->sd_v2->sd_atime);
+ fsw_store_time_posix(sb, FSW_DNODE_STAT_MTIME, dno->sd_v2->sd_mtime);
+ fsw_store_attr_posix(sb, dno->sd_v2->sd_mode);
}
return FSW_SUCCESS;
// timeout expired
MenuExit = MENU_EXIT_TIMEOUT;
break;
- } else if (HaveTimeout) {
- refit_call1_wrapper(BS->Stall, 100000); // Pause for 100 ms
- TimeoutCountdown--;
- TimeSinceKeystroke++;
- } else if (GlobalConfig.ScreensaverTime > 0) {
- refit_call1_wrapper(BS->Stall, 100000); // Pause for 100 ms
- TimeSinceKeystroke++;
- if (TimeSinceKeystroke > (GlobalConfig.ScreensaverTime * 10)) {
- SaveScreen();
- State.PaintAll = TRUE;
- TimeSinceKeystroke = 0;
- } // if
+ } else if (HaveTimeout || GlobalConfig.ScreensaverTime > 0) {
+ EFI_EVENT TimerEvent;
+ UINTN ElapsCount = 1;
+
+ Status = refit_call5_wrapper(BS->CreateEvent, EVT_TIMER, 0, NULL, NULL, &TimerEvent);
+ if (EFI_ERROR(Status)) {
+ refit_call1_wrapper(BS->Stall, 100000); // Pause for 100 ms
+ } else {
+ EFI_EVENT WaitList[2];
+ UINTN Index;
+
+ refit_call3_wrapper(BS->SetTimer, TimerEvent, TimerRelative, 10000000); // 1s Timeout
+ WaitList[0] = ST->ConIn->WaitForKey;
+ WaitList[1] = TimerEvent;
+ Status = refit_call3_wrapper(BS->WaitForEvent, 2, WaitList, &Index);
+ refit_call1_wrapper(BS->CloseEvent, TimerEvent);
+ if (EFI_ERROR(Status))
+ refit_call1_wrapper(BS->Stall, 100000); // Pause for 100 ms
+ else if(Index == 0)
+ continue;
+ else
+ ElapsCount = 10; // always counted as 1s to end of the timeout
+ }
+ TimeSinceKeystroke += ElapsCount;
+ if(HaveTimeout) {
+ TimeoutCountdown = TimeoutCountdown <= ElapsCount ? 0 : TimeoutCountdown - ElapsCount;
+ } else if (GlobalConfig.ScreensaverTime > 0 &&
+ TimeSinceKeystroke > (GlobalConfig.ScreensaverTime * 10))
+ {
+ SaveScreen();
+ State.PaintAll = TRUE;
+ TimeSinceKeystroke = 0;
+ } // if
} else {
refit_call3_wrapper(BS->WaitForEvent, 1, &ST->ConIn->WaitForKey, &index);
}