Date: Thu, 22 Mar 2001 09:53:43 -0800 (PST) From: David Wolfskill <david@catwhisker.org> To: mobile@freebsd.org Subject: I found a Linux-based utility for Phoenix BIOS "suspend to disk" Message-ID: <200103221753.f2MHrh295742@bunrab.catwhisker.org>
next in thread | raw e-mail | index | archive | help
It's called "lphdisk" -- URL is http://www.procyon.com/~pda/lphdisk/. I have yet to try it, but (after replacing the reference to <getopt.h> by one to <unistd.h>) I was able to get it to compile. I'm planning to experiment if I can't find the information any other way, but I'm wondering about the comments (and a bit of code I noted) that seems to presume that the suspend-to-disk partition/slice must be the one referenced by the 4th entry in the partition table. The reason that's a concern for me is that when I laid out my disk, I was under the impression that the root filesystem of any bootable slice, as well as any suspend-to-disk "partition", must be within the first 8 GB of the disk. As a result, I laid things out: MBR (1st block) STABLE-1 / & /usr ~1 GB STABLE-2 / & /usr ~1 GB suspend-to-disk ~0.5 GB CURRENT / & /usr, ~16 GB swap, /var, /home, &c. I have yet to "prepare" the suspend-to-disk "partition", since I had no way to run the supplied "PHDISK.EXE". (It appears to have an operating dependency on software I neither have, want, nor would entrust my system to.) Thus, I intend to look at the lphdisk code to see if I can better- understand what limitations there might be: maybe the Phoenix BIOS requires that suspend-to-disk be pointed to by the last partition-table entry? In that case, does the order of table entries need to correspond to the order of the "partitions" themselves? That is, using the above actual layout, could it be valid to have the 3rd table entry point to the 4th "partition", and the 4th table entry point to the 3rd "partition"? Or is that likely to Really Confuse some brain-dead excuse for software somewhere...? Or maybe it's OK for the suspend-to-disk "partition" to be at the tail end of a 20 GB disk...? Anyway, I sent a note to the code's author last night. If it looks to be of use in a FreeBSD environment, I'm thinking that it might be worth turning into a "port". (The license is the Artistic one, vs. GPL, by the author's stated intent. This is a Good Thing.) Thoughts, clarifications, questions, wisdom, &c. are all welcome, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103221753.f2MHrh295742>