From MAILER-DAEMON Fri Oct 03 12:24:37 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KlnSH-0001cY-4W for mharc-grub-devel@gnu.org; Fri, 03 Oct 2008 12:24:37 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KlnSE-0001bw-PN for grub-devel@gnu.org; Fri, 03 Oct 2008 12:24:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KlnSC-0001ai-I5 for grub-devel@gnu.org; Fri, 03 Oct 2008 12:24:34 -0400 Received: from [199.232.76.173] (port=39731 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KlnSC-0001aa-9b for grub-devel@gnu.org; Fri, 03 Oct 2008 12:24:32 -0400 Received: from gateway04.websitewelcome.com ([67.18.124.7]:45221) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KlnSB-0002Th-SP for grub-devel@gnu.org; Fri, 03 Oct 2008 12:24:32 -0400 Received: (qmail 18942 invoked from network); 3 Oct 2008 16:35:55 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway04.websitewelcome.com with SMTP; 3 Oct 2008 16:35:55 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:36440 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KlnS7-0001jn-IZ for grub-devel@gnu.org; Fri, 03 Oct 2008 11:24:27 -0500 Date: Fri, 3 Oct 2008 09:24:07 -0700 From: Colin D Bennett To: The development of GRUB 2 Message-ID: <20081003092407.4298e3e9@gibibit.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/+M5cFoSw/H77oSpLLWu_849"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Status of GSoC patches for graphical menu X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2008 16:24:35 -0000 --Sig_/+M5cFoSw/H77oSpLLWu_849 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I merged the updates to GRUB mainline into my working set of patches and will provide updated versions of the patches yet to be committed to mainline GRUB. Here is the status of the patches I've sent so far: --- --------------------------------------- ----------- # Description Status --- --------------------------------------- ----------- #01 grub-mkrescue i386-pc multiple overlays COMMITTED #02 Minor tweak: Comment fix COMMITTED #03 Menu viewer interface POSTED #04 Multiple fallback entries POSTED #05 Menu entry class attribute POSTED #06 VBE optimization for BGR/BGRA COMMITTED #07 VBE double buffering POSTED #08 vbeinfo enhancements COMMITTED #09 Bitmap scaling POSTED #10 new font engine POSTED #11 font tools POSTED #12 videotest enhancements POSTED --- --------------------------------------- ----------- Regards, Colin --Sig_/+M5cFoSw/H77oSpLLWu_849 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjmRysACgkQokx8fzcGbYcSPwCfWJov9iARgIQ9eTxVWqeFeN0s 2JgAnjntJifdihhN7I1vFd2BcVIwWyZT =57m3 -----END PGP SIGNATURE----- --Sig_/+M5cFoSw/H77oSpLLWu_849-- From MAILER-DAEMON Fri Oct 03 16:16:57 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Klr57-0005DL-Bn for mharc-grub-devel@gnu.org; Fri, 03 Oct 2008 16:16:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Klr55-0005Cx-Mt for grub-devel@gnu.org; Fri, 03 Oct 2008 16:16:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Klr50-00056S-PN for grub-devel@gnu.org; Fri, 03 Oct 2008 16:16:55 -0400 Received: from [199.232.76.173] (port=44134 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Klr50-00056L-K2 for grub-devel@gnu.org; Fri, 03 Oct 2008 16:16:50 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:56423 helo=jenni2.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Klr4z-00009K-2L for grub-devel@gnu.org; Fri, 03 Oct 2008 16:16:50 -0400 Received: from [127.0.0.1] (84.248.105.254) by jenni2.inet.fi (8.5.014) id 48DA2F0A0083B9BC for grub-devel@gnu.org; Fri, 3 Oct 2008 23:16:42 +0300 Message-ID: <48E67DB3.8030408@nic.fi> Date: Fri, 03 Oct 2008 23:16:51 +0300 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <20080831000157.0c548199@gamma.lan> <48BAC517.4060002@nic.fi> <48BD5F00.9090902@nic.fi> In-Reply-To: <48BD5F00.9090902@nic.fi> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #09 Bitmap scaling X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2008 20:16:55 -0000 Vesa J=E4=E4skel=E4inen wrote: > Vesa J=E4=E4skel=E4inen wrote: >> It is really necessary that all generic graphical menu code like bitma= p >> scaler works always. Not just for some optimized formats as otherwise = it >> would render graphical menu unusable in some cases. It can be not so >> pretty on low end systems, but it should at least work. That is the >> reason there is map/unmap functions in video api. >> >> So there has to be first generic implementation and then you can use >> optimized one if there exist one. >=20 > Just thinking as this is operating in a bitmap, we could just make sure > we use only couple of formats and let video driver dot the rest. That > would simplify it a bit. Hi, Now that Colin is back in action I am reviving this thread :). I have been thinking this a bit and I think best solution to bitmaps is something like following. Two types of bitmap: easily accessible and optimized bitmaps for hardware= =2E Easily accessible are meant to be modified by user and provides slow blitting performance. Basically we should only support two formats. RGB888 and ARGB8888 (order can be different). This way we can make easy code to modify bitmaps. When there is no need to modify bitmap anymore, one calls grub_video_bitmap_optimize(bitmap, rendering_target) and then bitmap is optimized to match reder_targets format. there would be two new helpers that gives access to bitmap data. grub_video_bitmap_lock() and to release it grub_video_bitmap_unlock(). Lock will fail if bitmap is optimized. I am wondering should we have grub_video_bitmap_unoptimize() to map back to editable mode. But that might be more pain and promote bad ways to do conversion. Now bitmap loaders would be modified to return data in easily accessible format so bitmaps can be modified and so on. Now to bitmap scaling. This can only be done for easily accessible formats and could be something like this: +grub_err_t +grub_video_bitmap_create_scaled (struct grub_video_bitmap **dst, + int dst_width, int dst_height, + struct grub_video_bitmap *src, + enum + grub_video_bitmap_scale_method scale_method); Now in example static bitmaps would be optimized right away in order to make their blitting fast. I do not know if we need special handling for transparent bitmaps. May need some experimenting. Actual scalers would be hidden from API and can only be specified by enum type. It could be a good idea to implement all scalers in same file. Unless there is some weird scaler that needs thousands of lines of code. Any opinions? Thanks, Vesa J=E4=E4skel=E4inen From MAILER-DAEMON Sat Oct 04 11:37:11 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Km9Bv-0004it-45 for mharc-grub-devel@gnu.org; Sat, 04 Oct 2008 11:37:11 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Km9Bt-0004iC-KN for grub-devel@gnu.org; Sat, 04 Oct 2008 11:37:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Km9Br-0004gs-T4 for grub-devel@gnu.org; Sat, 04 Oct 2008 11:37:08 -0400 Received: from [199.232.76.173] (port=39025 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Km9Br-0004gn-ON for grub-devel@gnu.org; Sat, 04 Oct 2008 11:37:07 -0400 Received: from fk-out-0910.google.com ([209.85.128.184]:24377) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Km8V0-0007gj-Jr for grub-devel@gnu.org; Sat, 04 Oct 2008 10:52:51 -0400 Received: by fk-out-0910.google.com with SMTP id 18so1520465fkq.10 for ; Sat, 04 Oct 2008 07:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:x-google-sender-auth; bh=XrPacpfZ8bKGHmGSWJqXZmuYqihPBN6McQOLvtCh1js=; b=ZYNEV/rPVY/o4hrGoagGOTjCnH/Ks7OSM0YbxEPQxjOMe3/wTf5IqKNrg7n7Ckb6U2 cQcR2gnZjpBBWJQY2MQn3KfuHUXDVgx3Td3SloVYNaPJRRkX8eT6XoqiY7k1uPMXdbvg 77+CtL9ikflhLFqFh8V6VVfpUnE5w/Eo1YXSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :x-google-sender-auth; b=PvN5sZ3KrqEPsvaD2/75wfcUpq4qSKH74I9/xWtAq6q441672fjiIcijUqT7y8zcOU yevd+Yx7hZ0jUnRxaeq0IXH3akONYtMKQfz24j6EkU28EZaRXdbeJRWlK3LTvWKxx3Uu z69HDtedatIBieDmhE6QgoscaUznNYhEkMqac= Received: by 10.180.239.7 with SMTP id m7mr1800303bkh.87.1223131967518; Sat, 04 Oct 2008 07:52:47 -0700 (PDT) Received: by 10.181.15.13 with HTTP; Sat, 4 Oct 2008 07:52:47 -0700 (PDT) Message-ID: Date: Sun, 5 Oct 2008 00:52:47 +1000 From: "Cameron Braid" Sender: cbraid@gmail.com To: grub-devel@gnu.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_33371_17062011.1223131967504" X-Google-Sender-Auth: 341cb79c2b93dbb3 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: grub2 /boot on lvm on ubuntu - incorrect magic number X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 15:37:10 -0000 ------=_Part_33371_17062011.1223131967504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have the following setup * ubuntu hardy on amd64 * grub2 from subversion trunk r1885 * root partition is a lvm device (/dev/mapper/Ubuntu-hardy64) * /boot is a folder on the root filesystem * /dev/sdd is one of the hard drives in the physical volume * the /boot/grub/device.map contains an entry for all of my hard drives when running grub-install I get the following error : beast:grub2$ sudo grub-install /dev/sdd error: Unknown metadata header error: Unknown metadata header grub-probe: error: no mapping exists for `Ubuntu-hardy64' Auto-detection of a filesystem module failed. Please specify the module with the option `--modules' explicitly. I found that grub-install exists after the "grub-probe" command is unable to resolve a filesystem for this device. So, I ran the same probe command with the verbosity increased. see attached grub-probe.txt This didn't really show up anything, so I modified lvm.c to tell me if it was the version or the magic number that was wrong. It was the magic number. I am not a C programmer, but fezie on #grub was able to help me print out what my actual magic number is : grub_util_info("magic = %hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX",mdah->magic[0],mdah->magic[1],mdah->magic[2],mdah->magic[3],mdah->magic[4],mdah->magic[5],mdah->magic[6],mdah->magic[7],mdah->magic[8],mdah->magic[9],mdah->magic[10],mdah->magic[11],mdah->magic[12],mdah->magic[13],mdah->magic[14],mdah->magic[15]); which produces : 61-20-7B-0A-69-64-20-3D-20-22-32-43-39-54-54-4C which obviously doesn't match GRUB_LVM_FMTT_VERSION (in hex : 20-4C-56-4D-32-20-78-5B-35-41-25-72-30-4E-2A-3E - fezie ran the same code on his debian amd64 box) So, my magic number is wrong. Is this an issue with ubuntu's LVM, or an issue with my LVM device ? Is there a tool to fix this, or can grub2 work around it ? Cheers, Cameron ------=_Part_33371_17062011.1223131967504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I have the following setup

* ubuntu hardy on amd64
* grub2 from subversion trunk r1885
* root partition is a lvm device (/dev/mapper/Ubuntu-hardy64)
* /boot is a folder on the root filesystem
* /dev/sdd is one of the hard drives in the physical volume
* the /boot/grub/device.map contains an entry for all of my hard drives

when running grub-install I get the following error :

beast:grub2$ sudo grub-install /dev/sdd
error: Unknown metadata header
error: Unknown metadata header
grub-probe: error: no mapping exists for `Ubuntu-hardy64'
Auto-detection of a filesystem module failed.
Please specify the module with the option `--modules' explicitly.

I found that grub-install exists after the "grub-probe" command is unable to resolve a filesystem for this device.  So, I ran the same probe command with the verbosity increased. see attached grub-probe.txt

This didn't really show up anything, so I modified lvm.c to tell me if it was the version or the magic number that was wrong.  It was the magic number.

I am not a C programmer, but fezie on #grub was able to help me print out what my actual magic number is :

grub_util_info("magic = %hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX-%hhX",mdah->magic[0],mdah->magic[1],mdah->magic[2],mdah->magic[3],mdah->magic[4],mdah->magic[5],mdah->magic[6],mdah->magic[7],mdah->magic[8],mdah->magic[9],mdah->magic[10],mdah->magic[11],mdah->magic[12],mdah->magic[13],mdah->magic[14],mdah->magic[15]);

which produces : 61-20-7B-0A-69-64-20-3D-20-22-32-43-39-54-54-4C

which obviously doesn't match GRUB_LVM_FMTT_VERSION (in hex : 20-4C-56-4D-32-20-78-5B-35-41-25-72-30-4E-2A-3E - fezie ran the same code on his debian amd64 box)

So, my magic number is wrong.

Is this an issue with ubuntu's LVM, or an issue with my LVM device ?

Is there a tool to fix this, or can grub2 work around it ?

Cheers,

Cameron
------=_Part_33371_17062011.1223131967504-- From MAILER-DAEMON Sat Oct 04 11:52:20 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Km9QZ-0003mV-Pz for mharc-grub-devel@gnu.org; Sat, 04 Oct 2008 11:52:19 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Km9QY-0003lL-12 for grub-devel@gnu.org; Sat, 04 Oct 2008 11:52:18 -0400 Received: from [199.232.76.173] (port=35515 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Km9QX-0003kw-1m for grub-devel@gnu.org; Sat, 04 Oct 2008 11:52:17 -0400 Received: from smtp.aircanopy.net ([66.160.208.25]:45849) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Km9QW-00039F-9h for grub-devel@gnu.org; Sat, 04 Oct 2008 11:52:16 -0400 X-ASG-Debug-ID: 1223135533-7fdd00350000-Td4drV X-Barracuda-URL: http://66.160.208.25:8000/cgi-bin/mark.cgi Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net (Spam Firewall) with ESMTP id 0A06D802E21 for ; Sat, 4 Oct 2008 10:52:13 -0500 (CDT) Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net with ESMTP id ubH7hCTk8sGaOGaT for ; Sat, 04 Oct 2008 10:52:13 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by aczmr1.aircanopy.net (Postfix) with ESMTP id EE0BB1D9F7 for ; Sat, 4 Oct 2008 10:52:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.914 Received: from aczmr1.aircanopy.net ([127.0.0.1]) by localhost (aczmr1.aircanopy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeomcMGYO7lf for ; Sat, 4 Oct 2008 10:52:13 -0500 (CDT) Received: from aczmb1.aircanopy.net (aczmb1.aircanopy.net [66.160.208.170]) by aczmr1.aircanopy.net (Postfix) with ESMTP id 668351D9CF for ; Sat, 4 Oct 2008 10:52:13 -0500 (CDT) Date: Sat, 4 Oct 2008 10:52:13 -0500 (CDT) From: Andy Goth To: The development of GRUB 2 Message-ID: <1191751462.32701223135533223.JavaMail.root@aczmb1> In-Reply-To: X-ASG-Orig-Subj: Re: grub2 /boot on lvm on ubuntu - incorrect magic number MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [66.160.219.98] X-Mailer: Zimbra 5.0.8_GA_2462.SLES10_64 (ZimbraWebClient - FF2.0 (Linux)/5.0.8_GA_2462.SLES10_64) X-Barracuda-Connect: aczmr1.aircanopy.net[66.160.208.172] X-Barracuda-Start-Time: 1223135534 X-Barracuda-Virus-Scanned: by Aircanopy Spam Firewall at aircanopy.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.7224 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Subject: Re: grub2 /boot on lvm on ubuntu - incorrect magic number X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 15:52:18 -0000 "Cameron Braid" wrote: > I found that grub-install exists after the "grub-probe" command is > unable to resolve a filesystem for this device. So, I ran the same > probe command with the verbosity increased. see attached > grub-probe.txt The attachment seems to be missing. -- Andy Goth | http://andy.junkdrome.org/ unununium@{aircanopy.net,openverse.com} From MAILER-DAEMON Sat Oct 04 12:13:05 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Km9kf-0003f0-2a for mharc-grub-devel@gnu.org; Sat, 04 Oct 2008 12:13:05 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Km9kd-0003dz-BK for grub-devel@gnu.org; Sat, 04 Oct 2008 12:13:03 -0400 Received: from [199.232.76.173] (port=34727 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Km9kc-0003dL-9U for grub-devel@gnu.org; Sat, 04 Oct 2008 12:13:02 -0400 Received: from smtp.aircanopy.net ([66.160.208.25]:45928) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Km9UH-0005OW-IH for grub-devel@gnu.org; Sat, 04 Oct 2008 11:56:09 -0400 X-ASG-Debug-ID: 1223135768-7e9b01b90000-Td4drV X-Barracuda-URL: http://66.160.208.25:8000/cgi-bin/mark.cgi Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net (Spam Firewall) with ESMTP id 2C69E802EC4 for ; Sat, 4 Oct 2008 10:56:08 -0500 (CDT) Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net with ESMTP id pNwpnsdriN1StIDT for ; Sat, 04 Oct 2008 10:56:08 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by aczmr1.aircanopy.net (Postfix) with ESMTP id 247771D9CF for ; Sat, 4 Oct 2008 10:56:08 -0500 (CDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.911 Received: from aczmr1.aircanopy.net ([127.0.0.1]) by localhost (aczmr1.aircanopy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJLHbI6A1grl for ; Sat, 4 Oct 2008 10:56:07 -0500 (CDT) Received: from aczmb1.aircanopy.net (aczmb1.aircanopy.net [66.160.208.170]) by aczmr1.aircanopy.net (Postfix) with ESMTP id CE01318216 for ; Sat, 4 Oct 2008 10:56:07 -0500 (CDT) Date: Sat, 4 Oct 2008 10:56:07 -0500 (CDT) From: Andy Goth To: The development of GRUB 2 Message-ID: <264154299.32731223135767648.JavaMail.root@aczmb1> In-Reply-To: X-ASG-Orig-Subj: Re: grub2 /boot on lvm on ubuntu - incorrect magic number MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [66.160.219.98] X-Mailer: Zimbra 5.0.8_GA_2462.SLES10_64 (ZimbraWebClient - FF2.0 (Linux)/5.0.8_GA_2462.SLES10_64) X-Barracuda-Connect: aczmr1.aircanopy.net[66.160.208.172] X-Barracuda-Start-Time: 1223135768 X-Barracuda-Virus-Scanned: by Aircanopy Spam Firewall at aircanopy.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.7224 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Subject: Re: grub2 /boot on lvm on ubuntu - incorrect magic number X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 16:13:03 -0000 "Cameron Braid" wrote: > * root partition is a lvm device (/dev/mapper/Ubuntu-hardy64) > > beast:grub2$ sudo grub-install /dev/sdd >From looking at the GRUB 1.96 sources, I get the impression that this command line should be: $ sudo grub-install /dev/mapper/Ubuntu-hardy64 in order for grub-probe to see the abstraction as GRUB_DEV_ABSTRACTION_LVM. I could be majorly wrong, and this may have changed between 1.96 and the version that Cameron is using, but... I'm just trying to figure out how GRUB works. :^) -- Andy Goth | http://andy.junkdrome.org/ unununium@{aircanopy.net,openverse.com} From MAILER-DAEMON Sat Oct 04 18:56:59 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmG3X-0000dZ-1m for mharc-grub-devel@gnu.org; Sat, 04 Oct 2008 18:56:59 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmG3U-0000dD-Ow for grub-devel@gnu.org; Sat, 04 Oct 2008 18:56:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmG3O-0000cY-SY for grub-devel@gnu.org; Sat, 04 Oct 2008 18:56:55 -0400 Received: from [199.232.76.173] (port=60473 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmG3O-0000cV-Mv for grub-devel@gnu.org; Sat, 04 Oct 2008 18:56:50 -0400 Received: from fg-out-1718.google.com ([72.14.220.157]:49505) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmG3O-0001c3-2w for grub-devel@gnu.org; Sat, 04 Oct 2008 18:56:50 -0400 Received: by fg-out-1718.google.com with SMTP id l26so1657468fgb.30 for ; Sat, 04 Oct 2008 15:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=ffu7xH1sLS+ribVGOdwAdxSr6HKyl1DbISPdBZf11bc=; b=j6H2kQnuhvXaLUpf96qLBX34B2FcSj3s0XWr5Gl1bYXgbm95hP1kr25lUlBFl75KAX WYeifHzUNh6VR+eBekTgZLpYj1WaPBDwMGOWTtZ/44CGahX4VVcXyZCIRqIpMmGJJbUB WbMe2uC097W73R0PgCzjEVsVnM7Vt3IVw9cms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=RC2zCefTN6QCOhry0d5GfVwMg+vYCgXXC4/UXw3oHdoMSVm8KhD4cpG+hJuUqBdo/2 gUtfujVCMYxjM8IWIHUKzoKAFzX/5xuO2KXwmOsIzpEsnZ/wiT1zJxdhMAiM6BP68CUH ux2hOYX3HdGCg2ZUHjq1E47Q6s3XVAromvbvA= Received: by 10.180.225.16 with SMTP id x16mr2246238bkg.91.1223161008656; Sat, 04 Oct 2008 15:56:48 -0700 (PDT) Received: by 10.181.15.13 with HTTP; Sat, 4 Oct 2008 15:56:48 -0700 (PDT) Message-ID: Date: Sun, 5 Oct 2008 08:56:48 +1000 From: "Cameron Braid" Sender: cbraid@gmail.com To: "The development of GRUB 2" In-Reply-To: <1191751462.32701223135533223.JavaMail.root@aczmb1> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_36883_23316214.1223161008632" References: <1191751462.32701223135533223.JavaMail.root@aczmb1> X-Google-Sender-Auth: 9c879b5d920011ae X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: grub2 /boot on lvm on ubuntu - incorrect magic number X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 22:56:57 -0000 ------=_Part_36883_23316214.1223161008632 Content-Type: multipart/alternative; boundary="----=_Part_36884_26868545.1223161008632" ------=_Part_36884_26868545.1223161008632 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Silly me! Here is is Cameron On Sun, Oct 5, 2008 at 1:52 AM, Andy Goth wrote: > "Cameron Braid" wrote: > > I found that grub-install exists after the "grub-probe" command is > > unable to resolve a filesystem for this device. So, I ran the same > > probe command with the verbosity increased. see attached > > grub-probe.txt > > The attachment seems to be missing. > > -- > Andy Goth | http://andy.junkdrome.org/ > unununium@{aircanopy.net,openverse.com} > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ------=_Part_36884_26868545.1223161008632 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Silly me!

Here is is

Cameron

On Sun, Oct 5, 2008 at 1:52 AM, Andy Goth <unununium@aircanopy.net> wrote:
"Cameron Braid" <cameron@braid.com.au> wrote:
> I found that grub-install exists after the "grub-probe" command is
> unable to resolve a filesystem for this device. So, I ran the same
> probe command with the verbosity increased. see attached
> grub-probe.txt

The attachment seems to be missing.

--
Andy Goth | http://andy.junkdrome.org/
unununium@{aircanopy.net,openverse.com}


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

------=_Part_36884_26868545.1223161008632-- ------=_Part_36883_23316214.1223161008632 Content-Type: text/plain; name=grub-probe.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_flwugz0t0 Content-Disposition: attachment; filename=grub-probe.txt a2Vybi9kaXNrLmM6MjIwOiBPcGVuaW5nIGBoZDAnLi4uCmdydWItcHJvYmU6IGluZm86IHRoZSBz aXplIG9mIGhkMCBpcyA4MDI5MzI0OAprZXJuL2Rpc2suYzozNjg6IFJlYWRpbmcgYGhkMCcuLi4K dXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYScgaW4gb3Bl bl9kZXZpY2UoKWtlcm4vZGlzay5jOjM2ODogUmVhZGluZyBgaGQwJy4uLgprZXJuL2Rpc2suYzoz Njg6IFJlYWRpbmcgYGhkMCcuLi4Ka2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDAnLi4uCmtl cm4vZGlzay5jOjMxMjogQ2xvc2luZyBgaGQwJy4Ka2Vybi9kaXNrLmM6MjIwOiBPcGVuaW5nIGBo ZDAnLi4uCmdydWItcHJvYmU6IGluZm86IHRoZSBzaXplIG9mIGhkMCBpcyA4MDI5MzI0OAprZXJu L3BhcnRpdGlvbi5jOjEwNjogRGV0ZWN0aW5nIGdwdF9wYXJ0aXRpb25fbWFwLi4uCmtlcm4vZGlz ay5jOjM2ODogUmVhZGluZyBgaGQwJy4uLgprZXJuL3BhcnRpdGlvbi5jOjExMjogZ3B0X3BhcnRp dGlvbl9tYXAgZGV0ZWN0aW9uIGZhaWxlZC4Ka2Vybi9wYXJ0aXRpb24uYzoxMDY6IERldGVjdGlu ZyBhcHBsZV9wYXJ0aXRpb25fbWFwLi4uCmtlcm4vZGlzay5jOjM2ODogUmVhZGluZyBgaGQwJy4u LgpwYXJ0bWFwL2FwcGxlLmM6MTI5OiBiYWQgbWFnaWMgKGZvdW5kIDB4ZWI0Yzsgd2FudGVkIDB4 NDU1MgprZXJuL3BhcnRpdGlvbi5jOjExMjogYXBwbGVfcGFydGl0aW9uX21hcCBkZXRlY3Rpb24g ZmFpbGVkLgprZXJuL3BhcnRpdGlvbi5jOjEwNjogRGV0ZWN0aW5nIHBjX3BhcnRpdGlvbl9tYXAu Li4Ka2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDAnLi4uCnBhcnRtYXAvcGMuYzoxNDM6IHBh cnRpdGlvbiAwOiBmbGFnIDB4MCwgdHlwZSAweDgzLCBzdGFydCAweDNmLCBsZW4gMHg3YTkwYjUK a2Vybi9wYXJ0aXRpb24uYzoxMTc6IHBjX3BhcnRpdGlvbl9tYXAgZGV0ZWN0aW9uIHN1Y2NlZWRl ZC4Ka2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDAnLi4uCnBhcnRtYXAvcGMuYzoxNDM6IHBh cnRpdGlvbiAwOiBmbGFnIDB4MCwgdHlwZSAweDgzLCBzdGFydCAweDNmLCBsZW4gMHg3YTkwYjUK a2Vybi9kaXNrLmM6MjIwOiBPcGVuaW5nIGBoZDAsMScuLi4KZ3J1Yi1wcm9iZTogaW5mbzogdGhl IHNpemUgb2YgaGQwIGlzIDgwMjkzMjQ4Cmtlcm4vZGlzay5jOjM2ODogUmVhZGluZyBgaGQwLDEn Li4uCmtlcm4vZGlzay5jOjM2ODogUmVhZGluZyBgaGQwLDEnLi4uCnBhcnRtYXAvYXBwbGUuYzox Mjk6IGJhZCBtYWdpYyAoZm91bmQgMHhlYjRjOyB3YW50ZWQgMHg0NTUyCmtlcm4vZGlzay5jOjM2 ODogUmVhZGluZyBgaGQwLDEnLi4uCnBhcnRtYXAvcGMuYzoxNDM6IHBhcnRpdGlvbiAwOiBmbGFn IDB4MCwgdHlwZSAweDgzLCBzdGFydCAweDNmLCBsZW4gMHg3YTkwYjUKa2Vybi9kaXNrLmM6MzY4 OiBSZWFkaW5nIGBoZDAsMScuLi4KdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2 aWNlIGAvZGV2L3NkYTEnIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVu aW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RhMScgaW4gb3Blbl9kZXZpY2UoKWtlcm4vZGlzay5jOjM2 ODogUmVhZGluZyBgaGQwLDEnLi4uCnV0aWwvaG9zdGRpc2suYzozMTY6IG9wZW5pbmcgdGhlIGRl dmljZSBgL2Rldi9zZGExJyBpbiBvcGVuX2RldmljZSgpa2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5n IGBoZDAsMScuLi4Ka2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDAsMScuLi4Ka2Vybi9kaXNr LmM6MzEyOiBDbG9zaW5nIGBoZDAsMScuCnBhcnRtYXAvcGMuYzoxNDM6IHBhcnRpdGlvbiAxOiBm bGFnIDB4ODAsIHR5cGUgMHg4Mywgc3RhcnQgMHg3YTkwZjQsIGxlbiAweDdhY2ZiNQprZXJuL2Rp c2suYzoyMjA6IE9wZW5pbmcgYGhkMCwyJy4uLgpncnViLXByb2JlOiBpbmZvOiB0aGUgc2l6ZSBv ZiBoZDAgaXMgODAyOTMyNDgKa2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDAsMicuLi4Ka2Vy bi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDAsMicuLi4KcGFydG1hcC9hcHBsZS5jOjEyOTogYmFk IG1hZ2ljIChmb3VuZCAweGViNGM7IHdhbnRlZCAweDQ1NTIKa2Vybi9kaXNrLmM6MzY4OiBSZWFk aW5nIGBoZDAsMicuLi4KcGFydG1hcC9wYy5jOjE0MzogcGFydGl0aW9uIDA6IGZsYWcgMHgwLCB0 eXBlIDB4ODMsIHN0YXJ0IDB4M2YsIGxlbiAweDdhOTBiNQpwYXJ0bWFwL3BjLmM6MTQzOiBwYXJ0 aXRpb24gMTogZmxhZyAweDgwLCB0eXBlIDB4ODMsIHN0YXJ0IDB4N2E5MGY0LCBsZW4gMHg3YWNm YjUKa2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDAsMicuLi4KdXRpbC9ob3N0ZGlzay5jOjMx Njogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYTInIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hv c3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RhMicgaW4gb3Blbl9kZXZp Y2UoKWtlcm4vZGlzay5jOjM2ODogUmVhZGluZyBgaGQwLDInLi4uCnV0aWwvaG9zdGRpc2suYzoz MTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGEyJyBpbiBvcGVuX2RldmljZSgpdXRpbC9o b3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYTInIGluIG9wZW5fZGV2 aWNlKClrZXJuL2Rpc2suYzozNjg6IFJlYWRpbmcgYGhkMCwyJy4uLgp1dGlsL2hvc3RkaXNrLmM6 MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RhMicgaW4gb3Blbl9kZXZpY2UoKXV0aWwv aG9zdGRpc2suYzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGEyJyBpbiBvcGVuX2Rl dmljZSgpa2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDAsMicuLi4KdXRpbC9ob3N0ZGlzay5j OjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYTInIGluIG9wZW5fZGV2aWNlKCl1dGls L2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RhMicgaW4gb3Blbl9k ZXZpY2UoKWtlcm4vZGlzay5jOjMxMjogQ2xvc2luZyBgaGQwLDInLgpwYXJ0bWFwL3BjLmM6MTQz OiBwYXJ0aXRpb24gMjogZmxhZyAweDAsIHR5cGUgMHgwLCBzdGFydCAweDAsIGxlbiAweDAKcGFy dG1hcC9wYy5jOjE0MzogcGFydGl0aW9uIDM6IGZsYWcgMHgwLCB0eXBlIDB4MCwgc3RhcnQgMHgw LCBsZW4gMHgwCmtlcm4vZGlzay5jOjMxMjogQ2xvc2luZyBgaGQwJy4Ka2Vybi9kaXNrLmM6MjIw OiBPcGVuaW5nIGBoZDEnLi4uCmdydWItcHJvYmU6IGluZm86IHRoZSBzaXplIG9mIGhkMSBpcyAz MTI1ODE4MDgKa2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDEnLi4uCnV0aWwvaG9zdGRpc2su YzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGInIGluIG9wZW5fZGV2aWNlKClrZXJu L2Rpc2suYzozNjg6IFJlYWRpbmcgYGhkMScuLi4Ka2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBo ZDEnLi4uCmtlcm4vZGlzay5jOjM2ODogUmVhZGluZyBgaGQxJy4uLgp1dGlsL2hvc3RkaXNrLmM6 MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RiJyBpbiBvcGVuX2RldmljZSgpdXRpbC9o b3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYicgaW4gb3Blbl9kZXZp Y2UoKXV0aWwvaG9zdGRpc2suYzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGInIGlu IG9wZW5fZGV2aWNlKCl1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9k ZXYvc2RiJyBpbiBvcGVuX2RldmljZSgpdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUg ZGV2aWNlIGAvZGV2L3NkYicgaW4gb3Blbl9kZXZpY2UoKXV0aWwvaG9zdGRpc2suYzozMTY6IG9w ZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGInIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hvc3RkaXNr LmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RiJyBpbiBvcGVuX2RldmljZSgpdXRp bC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYicgaW4gb3Blbl9k ZXZpY2UoKXV0aWwvaG9zdGRpc2suYzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGIn IGluIG9wZW5fZGV2aWNlKCl1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2Ug YC9kZXYvc2RiJyBpbiBvcGVuX2RldmljZSgpdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0 aGUgZGV2aWNlIGAvZGV2L3NkYicgaW4gb3Blbl9kZXZpY2UoKXV0aWwvaG9zdGRpc2suYzozMTY6 IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGInIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hvc3Rk aXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RiJyBpbiBvcGVuX2RldmljZSgp dXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYicgaW4gb3Bl bl9kZXZpY2UoKXV0aWwvaG9zdGRpc2suYzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9z ZGInIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZp Y2UgYC9kZXYvc2RiJyBpbiBvcGVuX2RldmljZSgpdXRpbC9ob3N0ZGlzay5jOjMxNjogb3Blbmlu ZyB0aGUgZGV2aWNlIGAvZGV2L3NkYicgaW4gb3Blbl9kZXZpY2UoKXV0aWwvaG9zdGRpc2suYzoz MTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGInIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hv c3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RiJyBpbiBvcGVuX2Rldmlj ZSgpdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYicgaW4g b3Blbl9kZXZpY2UoKXV0aWwvaG9zdGRpc2suYzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rl di9zZGInIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBk ZXZpY2UgYC9kZXYvc2RiJyBpbiBvcGVuX2RldmljZSgpdXRpbC9ob3N0ZGlzay5jOjMxNjogb3Bl bmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYicgaW4gb3Blbl9kZXZpY2UoKXV0aWwvaG9zdGRpc2su YzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGInIGluIG9wZW5fZGV2aWNlKCl1dGls L2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RiJyBpbiBvcGVuX2Rl dmljZSgpdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYicg aW4gb3Blbl9kZXZpY2UoKXV0aWwvaG9zdGRpc2suYzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBg L2Rldi9zZGInIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRo ZSBkZXZpY2UgYC9kZXYvc2RiJyBpbiBvcGVuX2RldmljZSgpdXRpbC9ob3N0ZGlzay5jOjMxNjog b3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYicgaW4gb3Blbl9kZXZpY2UoKXV0aWwvaG9zdGRp c2suYzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGInIGluIG9wZW5fZGV2aWNlKCl1 dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RiJyBpbiBvcGVu X2RldmljZSgpdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3Nk YicgaW4gb3Blbl9kZXZpY2UoKXV0aWwvaG9zdGRpc2suYzozMTY6IG9wZW5pbmcgdGhlIGRldmlj ZSBgL2Rldi9zZGInIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5n IHRoZSBkZXZpY2UgYC9kZXYvc2RiJyBpbiBvcGVuX2RldmljZSgpdXRpbC9ob3N0ZGlzay5jOjMx Njogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYicgaW4gb3Blbl9kZXZpY2UoKXV0aWwvaG9z dGRpc2suYzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGInIGluIG9wZW5fZGV2aWNl KCl1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RiJyBpbiBv cGVuX2RldmljZSgpdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2 L3NkYicgaW4gb3Blbl9kZXZpY2UoKXV0aWwvaG9zdGRpc2suYzozMTY6IG9wZW5pbmcgdGhlIGRl dmljZSBgL2Rldi9zZGInIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVu aW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RiJyBpbiBvcGVuX2RldmljZSgpdXRpbC9ob3N0ZGlzay5j OjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYicgaW4gb3Blbl9kZXZpY2UoKXV0aWwv aG9zdGRpc2suYzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGInIGluIG9wZW5fZGV2 aWNlKCl1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RiJyBp biBvcGVuX2RldmljZSgpdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAv ZGV2L3NkYicgaW4gb3Blbl9kZXZpY2UoKXV0aWwvaG9zdGRpc2suYzozMTY6IG9wZW5pbmcgdGhl IGRldmljZSBgL2Rldi9zZGInIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hvc3RkaXNrLmM6MzE2OiBv cGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RiJyBpbiBvcGVuX2RldmljZSgpdXRpbC9ob3N0ZGlz ay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYicgaW4gb3Blbl9kZXZpY2UoKWtl cm4vZGlzay5jOjMxMjogQ2xvc2luZyBgaGQxJy4Ka2Vybi9kaXNrLmM6MjIwOiBPcGVuaW5nIGBo ZDEnLi4uCmdydWItcHJvYmU6IGluZm86IHRoZSBzaXplIG9mIGhkMSBpcyAzMTI1ODE4MDgKa2Vy bi9kaXNrLmM6Mjk5OiBPcGVuaW5nIGBoZDEnIGZhaWxlZC4Ka2Vybi9kaXNrLmM6MzEyOiBDbG9z aW5nIGBoZDEnLgprZXJuL2Rpc2suYzoyMjA6IE9wZW5pbmcgYGhkMicuLi4KZ3J1Yi1wcm9iZTog aW5mbzogdGhlIHNpemUgb2YgaGQyIGlzIDk3Njc3MzE2OAprZXJuL2Rpc2suYzoyOTk6IE9wZW5p bmcgYGhkMicgZmFpbGVkLgprZXJuL2Rpc2suYzozMTI6IENsb3NpbmcgYGhkMicuCmtlcm4vZGlz ay5jOjIyMDogT3BlbmluZyBgaGQyJy4uLgpncnViLXByb2JlOiBpbmZvOiB0aGUgc2l6ZSBvZiBo ZDIgaXMgOTc2NzczMTY4Cmtlcm4vZGlzay5jOjI5OTogT3BlbmluZyBgaGQyJyBmYWlsZWQuCmtl cm4vZGlzay5jOjMxMjogQ2xvc2luZyBgaGQyJy4Ka2Vybi9kaXNrLmM6MjIwOiBPcGVuaW5nIGBo ZDMnLi4uCmdydWItcHJvYmU6IGluZm86IHRoZSBzaXplIG9mIGhkMyBpcyA5NzY3NzMxNjgKa2Vy bi9kaXNrLmM6Mjk5OiBPcGVuaW5nIGBoZDMnIGZhaWxlZC4Ka2Vybi9kaXNrLmM6MzEyOiBDbG9z aW5nIGBoZDMnLgprZXJuL2Rpc2suYzoyMjA6IE9wZW5pbmcgYGhkMycuLi4KZ3J1Yi1wcm9iZTog aW5mbzogdGhlIHNpemUgb2YgaGQzIGlzIDk3Njc3MzE2OAprZXJuL2Rpc2suYzoyOTk6IE9wZW5p bmcgYGhkMycgZmFpbGVkLgprZXJuL2Rpc2suYzozMTI6IENsb3NpbmcgYGhkMycuCmVycm9yOiBV bmtub3duIG1ldGFkYXRhIGhlYWRlcgpkaXNrL3JhaWQuYzo2MDQ6IFNjYW5uaW5nIGZvciBSQUlE IGRldmljZXMKa2Vybi9kaXNrLmM6MjIwOiBPcGVuaW5nIGBoZDAnLi4uCmdydWItcHJvYmU6IGlu Zm86IHRoZSBzaXplIG9mIGhkMCBpcyA4MDI5MzI0OAprZXJuL2Rpc2suYzozNjg6IFJlYWRpbmcg YGhkMCcuLi4KdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3Nk YScgaW4gb3Blbl9kZXZpY2UoKWtlcm4vZGlzay5jOjMxMjogQ2xvc2luZyBgaGQwJy4Ka2Vybi9k aXNrLmM6MjIwOiBPcGVuaW5nIGBoZDAnLi4uCmdydWItcHJvYmU6IGluZm86IHRoZSBzaXplIG9m IGhkMCBpcyA4MDI5MzI0OAprZXJuL3BhcnRpdGlvbi5jOjEwNjogRGV0ZWN0aW5nIGdwdF9wYXJ0 aXRpb25fbWFwLi4uCmtlcm4vZGlzay5jOjM2ODogUmVhZGluZyBgaGQwJy4uLgprZXJuL3BhcnRp dGlvbi5jOjExMjogZ3B0X3BhcnRpdGlvbl9tYXAgZGV0ZWN0aW9uIGZhaWxlZC4Ka2Vybi9wYXJ0 aXRpb24uYzoxMDY6IERldGVjdGluZyBhcHBsZV9wYXJ0aXRpb25fbWFwLi4uCmtlcm4vZGlzay5j OjM2ODogUmVhZGluZyBgaGQwJy4uLgpwYXJ0bWFwL2FwcGxlLmM6MTI5OiBiYWQgbWFnaWMgKGZv dW5kIDB4ZWI0Yzsgd2FudGVkIDB4NDU1MgprZXJuL3BhcnRpdGlvbi5jOjExMjogYXBwbGVfcGFy dGl0aW9uX21hcCBkZXRlY3Rpb24gZmFpbGVkLgprZXJuL3BhcnRpdGlvbi5jOjEwNjogRGV0ZWN0 aW5nIHBjX3BhcnRpdGlvbl9tYXAuLi4Ka2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDAnLi4u CnBhcnRtYXAvcGMuYzoxNDM6IHBhcnRpdGlvbiAwOiBmbGFnIDB4MCwgdHlwZSAweDgzLCBzdGFy dCAweDNmLCBsZW4gMHg3YTkwYjUKa2Vybi9wYXJ0aXRpb24uYzoxMTc6IHBjX3BhcnRpdGlvbl9t YXAgZGV0ZWN0aW9uIHN1Y2NlZWRlZC4Ka2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDAnLi4u CnBhcnRtYXAvcGMuYzoxNDM6IHBhcnRpdGlvbiAwOiBmbGFnIDB4MCwgdHlwZSAweDgzLCBzdGFy dCAweDNmLCBsZW4gMHg3YTkwYjUKZGlzay9yYWlkLmM6NjA0OiBTY2FubmluZyBmb3IgUkFJRCBk ZXZpY2VzCmtlcm4vZGlzay5jOjIyMDogT3BlbmluZyBgaGQwLDEnLi4uCmdydWItcHJvYmU6IGlu Zm86IHRoZSBzaXplIG9mIGhkMCBpcyA4MDI5MzI0OAprZXJuL2Rpc2suYzozNjg6IFJlYWRpbmcg YGhkMCwxJy4uLgprZXJuL2Rpc2suYzozNjg6IFJlYWRpbmcgYGhkMCwxJy4uLgpwYXJ0bWFwL2Fw cGxlLmM6MTI5OiBiYWQgbWFnaWMgKGZvdW5kIDB4ZWI0Yzsgd2FudGVkIDB4NDU1MgprZXJuL2Rp c2suYzozNjg6IFJlYWRpbmcgYGhkMCwxJy4uLgpwYXJ0bWFwL3BjLmM6MTQzOiBwYXJ0aXRpb24g MDogZmxhZyAweDAsIHR5cGUgMHg4Mywgc3RhcnQgMHgzZiwgbGVuIDB4N2E5MGI1Cmtlcm4vZGlz ay5jOjM2ODogUmVhZGluZyBgaGQwLDEnLi4uCnV0aWwvaG9zdGRpc2suYzozMTY6IG9wZW5pbmcg dGhlIGRldmljZSBgL2Rldi9zZGExJyBpbiBvcGVuX2RldmljZSgpdXRpbC9ob3N0ZGlzay5jOjMx Njogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkYTEnIGluIG9wZW5fZGV2aWNlKClrZXJuL2Rp c2suYzozMTI6IENsb3NpbmcgYGhkMCwxJy4KcGFydG1hcC9wYy5jOjE0MzogcGFydGl0aW9uIDE6 IGZsYWcgMHg4MCwgdHlwZSAweDgzLCBzdGFydCAweDdhOTBmNCwgbGVuIDB4N2FjZmI1CmRpc2sv cmFpZC5jOjYwNDogU2Nhbm5pbmcgZm9yIFJBSUQgZGV2aWNlcwprZXJuL2Rpc2suYzoyMjA6IE9w ZW5pbmcgYGhkMCwyJy4uLgpncnViLXByb2JlOiBpbmZvOiB0aGUgc2l6ZSBvZiBoZDAgaXMgODAy OTMyNDgKa2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDAsMicuLi4Ka2Vybi9kaXNrLmM6MzY4 OiBSZWFkaW5nIGBoZDAsMicuLi4KcGFydG1hcC9hcHBsZS5jOjEyOTogYmFkIG1hZ2ljIChmb3Vu ZCAweGViNGM7IHdhbnRlZCAweDQ1NTIKa2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDAsMicu Li4KcGFydG1hcC9wYy5jOjE0MzogcGFydGl0aW9uIDA6IGZsYWcgMHgwLCB0eXBlIDB4ODMsIHN0 YXJ0IDB4M2YsIGxlbiAweDdhOTBiNQpwYXJ0bWFwL3BjLmM6MTQzOiBwYXJ0aXRpb24gMTogZmxh ZyAweDgwLCB0eXBlIDB4ODMsIHN0YXJ0IDB4N2E5MGY0LCBsZW4gMHg3YWNmYjUKa2Vybi9kaXNr LmM6MzY4OiBSZWFkaW5nIGBoZDAsMicuLi4KdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0 aGUgZGV2aWNlIGAvZGV2L3NkYTInIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hvc3RkaXNrLmM6MzE2 OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RhMicgaW4gb3Blbl9kZXZpY2UoKWtlcm4vZGlz ay5jOjMxMjogQ2xvc2luZyBgaGQwLDInLgpwYXJ0bWFwL3BjLmM6MTQzOiBwYXJ0aXRpb24gMjog ZmxhZyAweDAsIHR5cGUgMHgwLCBzdGFydCAweDAsIGxlbiAweDAKcGFydG1hcC9wYy5jOjE0Mzog cGFydGl0aW9uIDM6IGZsYWcgMHgwLCB0eXBlIDB4MCwgc3RhcnQgMHgwLCBsZW4gMHgwCmtlcm4v ZGlzay5jOjMxMjogQ2xvc2luZyBgaGQwJy4KZGlzay9yYWlkLmM6NjA0OiBTY2FubmluZyBmb3Ig UkFJRCBkZXZpY2VzCmtlcm4vZGlzay5jOjIyMDogT3BlbmluZyBgaGQxJy4uLgpncnViLXByb2Jl OiBpbmZvOiB0aGUgc2l6ZSBvZiBoZDEgaXMgMzEyNTgxODA4Cmtlcm4vZGlzay5jOjM2ODogUmVh ZGluZyBgaGQxJy4uLgp1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9k ZXYvc2RiJyBpbiBvcGVuX2RldmljZSgpa2Vybi9kaXNrLmM6MzEyOiBDbG9zaW5nIGBoZDEnLgpr ZXJuL2Rpc2suYzoyMjA6IE9wZW5pbmcgYGhkMScuLi4KZ3J1Yi1wcm9iZTogaW5mbzogdGhlIHNp emUgb2YgaGQxIGlzIDMxMjU4MTgwOAprZXJuL3BhcnRpdGlvbi5jOjEwNjogRGV0ZWN0aW5nIGdw dF9wYXJ0aXRpb25fbWFwLi4uCmtlcm4vZGlzay5jOjM2ODogUmVhZGluZyBgaGQxJy4uLgprZXJu L3BhcnRpdGlvbi5jOjExMjogZ3B0X3BhcnRpdGlvbl9tYXAgZGV0ZWN0aW9uIGZhaWxlZC4Ka2Vy bi9wYXJ0aXRpb24uYzoxMDY6IERldGVjdGluZyBhcHBsZV9wYXJ0aXRpb25fbWFwLi4uCmtlcm4v ZGlzay5jOjM2ODogUmVhZGluZyBgaGQxJy4uLgpwYXJ0bWFwL2FwcGxlLmM6MTI5OiBiYWQgbWFn aWMgKGZvdW5kIDB4MDsgd2FudGVkIDB4NDU1MgprZXJuL3BhcnRpdGlvbi5jOjExMjogYXBwbGVf cGFydGl0aW9uX21hcCBkZXRlY3Rpb24gZmFpbGVkLgprZXJuL3BhcnRpdGlvbi5jOjEwNjogRGV0 ZWN0aW5nIHBjX3BhcnRpdGlvbl9tYXAuLi4Ka2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDEn Li4uCnBhcnRtYXAvcGMuYzoxNDM6IHBhcnRpdGlvbiAwOiBmbGFnIDB4MCwgdHlwZSAweDhlLCBz dGFydCAweDEsIGxlbiAweDEyYTE4YWMwCmtlcm4vcGFydGl0aW9uLmM6MTE3OiBwY19wYXJ0aXRp b25fbWFwIGRldGVjdGlvbiBzdWNjZWVkZWQuCmtlcm4vZGlzay5jOjM2ODogUmVhZGluZyBgaGQx Jy4uLgpwYXJ0bWFwL3BjLmM6MTQzOiBwYXJ0aXRpb24gMDogZmxhZyAweDAsIHR5cGUgMHg4ZSwg c3RhcnQgMHgxLCBsZW4gMHgxMmExOGFjMApkaXNrL3JhaWQuYzo2MDQ6IFNjYW5uaW5nIGZvciBS QUlEIGRldmljZXMKa2Vybi9kaXNrLmM6MjIwOiBPcGVuaW5nIGBoZDEsMScuLi4KZ3J1Yi1wcm9i ZTogaW5mbzogdGhlIHNpemUgb2YgaGQxIGlzIDMxMjU4MTgwOAprZXJuL2Rpc2suYzozNjg6IFJl YWRpbmcgYGhkMSwxJy4uLgprZXJuL2Rpc2suYzozNjg6IFJlYWRpbmcgYGhkMSwxJy4uLgpwYXJ0 bWFwL2FwcGxlLmM6MTI5OiBiYWQgbWFnaWMgKGZvdW5kIDB4MDsgd2FudGVkIDB4NDU1MgprZXJu L2Rpc2suYzozNjg6IFJlYWRpbmcgYGhkMSwxJy4uLgpwYXJ0bWFwL3BjLmM6MTQzOiBwYXJ0aXRp b24gMDogZmxhZyAweDAsIHR5cGUgMHg4ZSwgc3RhcnQgMHgxLCBsZW4gMHgxMmExOGFjMAprZXJu L2Rpc2suYzozNjg6IFJlYWRpbmcgYGhkMSwxJy4uLgp1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVu aW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RiMScgaW4gb3Blbl9kZXZpY2UoKXV0aWwvaG9zdGRpc2su YzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGIxJyBpbiBvcGVuX2RldmljZSgpa2Vy bi9kaXNrLmM6MzEyOiBDbG9zaW5nIGBoZDEsMScuCnBhcnRtYXAvcGMuYzoxNDM6IHBhcnRpdGlv biAxOiBmbGFnIDB4MCwgdHlwZSAweDAsIHN0YXJ0IDB4MCwgbGVuIDB4MApwYXJ0bWFwL3BjLmM6 MTQzOiBwYXJ0aXRpb24gMjogZmxhZyAweDAsIHR5cGUgMHgwLCBzdGFydCAweDAsIGxlbiAweDAK cGFydG1hcC9wYy5jOjE0MzogcGFydGl0aW9uIDM6IGZsYWcgMHgwLCB0eXBlIDB4MCwgc3RhcnQg MHgwLCBsZW4gMHgwCmtlcm4vZGlzay5jOjMxMjogQ2xvc2luZyBgaGQxJy4KZGlzay9yYWlkLmM6 NjA0OiBTY2FubmluZyBmb3IgUkFJRCBkZXZpY2VzCmtlcm4vZGlzay5jOjIyMDogT3BlbmluZyBg aGQyJy4uLgpncnViLXByb2JlOiBpbmZvOiB0aGUgc2l6ZSBvZiBoZDIgaXMgOTc2NzczMTY4Cmtl cm4vZGlzay5jOjM2ODogUmVhZGluZyBgaGQyJy4uLgp1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVu aW5nIHRoZSBkZXZpY2UgYC9kZXYvc2RjJyBpbiBvcGVuX2RldmljZSgpa2Vybi9kaXNrLmM6MzEy OiBDbG9zaW5nIGBoZDInLgprZXJuL2Rpc2suYzoyMjA6IE9wZW5pbmcgYGhkMicuLi4KZ3J1Yi1w cm9iZTogaW5mbzogdGhlIHNpemUgb2YgaGQyIGlzIDk3Njc3MzE2OAprZXJuL3BhcnRpdGlvbi5j OjEwNjogRGV0ZWN0aW5nIGdwdF9wYXJ0aXRpb25fbWFwLi4uCmtlcm4vZGlzay5jOjM2ODogUmVh ZGluZyBgaGQyJy4uLgp1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBkZXZpY2UgYC9k ZXYvc2RjJyBpbiBvcGVuX2RldmljZSgpa2Vybi9wYXJ0aXRpb24uYzoxMTI6IGdwdF9wYXJ0aXRp b25fbWFwIGRldGVjdGlvbiBmYWlsZWQuCmtlcm4vcGFydGl0aW9uLmM6MTA2OiBEZXRlY3Rpbmcg YXBwbGVfcGFydGl0aW9uX21hcC4uLgprZXJuL2Rpc2suYzozNjg6IFJlYWRpbmcgYGhkMicuLi4K cGFydG1hcC9hcHBsZS5jOjEyOTogYmFkIG1hZ2ljIChmb3VuZCAweGViNGM7IHdhbnRlZCAweDQ1 NTIKa2Vybi9wYXJ0aXRpb24uYzoxMTI6IGFwcGxlX3BhcnRpdGlvbl9tYXAgZGV0ZWN0aW9uIGZh aWxlZC4Ka2Vybi9wYXJ0aXRpb24uYzoxMDY6IERldGVjdGluZyBwY19wYXJ0aXRpb25fbWFwLi4u Cmtlcm4vZGlzay5jOjM2ODogUmVhZGluZyBgaGQyJy4uLgpwYXJ0bWFwL3BjLmM6MTQzOiBwYXJ0 aXRpb24gMDogZmxhZyAweDAsIHR5cGUgMHg4ZSwgc3RhcnQgMHgzZiwgbGVuIDB4M2EzODRjMDIK a2Vybi9wYXJ0aXRpb24uYzoxMTc6IHBjX3BhcnRpdGlvbl9tYXAgZGV0ZWN0aW9uIHN1Y2NlZWRl ZC4Ka2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDInLi4uCnBhcnRtYXAvcGMuYzoxNDM6IHBh cnRpdGlvbiAwOiBmbGFnIDB4MCwgdHlwZSAweDhlLCBzdGFydCAweDNmLCBsZW4gMHgzYTM4NGMw MgpkaXNrL3JhaWQuYzo2MDQ6IFNjYW5uaW5nIGZvciBSQUlEIGRldmljZXMKa2Vybi9kaXNrLmM6 MjIwOiBPcGVuaW5nIGBoZDIsMScuLi4KZ3J1Yi1wcm9iZTogaW5mbzogdGhlIHNpemUgb2YgaGQy IGlzIDk3Njc3MzE2OAprZXJuL2Rpc2suYzozNjg6IFJlYWRpbmcgYGhkMiwxJy4uLgprZXJuL2Rp c2suYzozNjg6IFJlYWRpbmcgYGhkMiwxJy4uLgpwYXJ0bWFwL2FwcGxlLmM6MTI5OiBiYWQgbWFn aWMgKGZvdW5kIDB4ZWI0Yzsgd2FudGVkIDB4NDU1MgprZXJuL2Rpc2suYzozNjg6IFJlYWRpbmcg YGhkMiwxJy4uLgpwYXJ0bWFwL3BjLmM6MTQzOiBwYXJ0aXRpb24gMDogZmxhZyAweDAsIHR5cGUg MHg4ZSwgc3RhcnQgMHgzZiwgbGVuIDB4M2EzODRjMDIKa2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5n IGBoZDIsMScuLi4KdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2 L3NkYzEnIGluIG9wZW5fZGV2aWNlKCl1dGlsL2hvc3RkaXNrLmM6MzE2OiBvcGVuaW5nIHRoZSBk ZXZpY2UgYC9kZXYvc2RjMScgaW4gb3Blbl9kZXZpY2UoKWtlcm4vZGlzay5jOjMxMjogQ2xvc2lu ZyBgaGQyLDEnLgpwYXJ0bWFwL3BjLmM6MTQzOiBwYXJ0aXRpb24gMTogZmxhZyAweDAsIHR5cGUg MHgwLCBzdGFydCAweDAsIGxlbiAweDAKcGFydG1hcC9wYy5jOjE0MzogcGFydGl0aW9uIDI6IGZs YWcgMHgwLCB0eXBlIDB4MCwgc3RhcnQgMHgwLCBsZW4gMHgwCnBhcnRtYXAvcGMuYzoxNDM6IHBh cnRpdGlvbiAzOiBmbGFnIDB4MCwgdHlwZSAweDAsIHN0YXJ0IDB4MCwgbGVuIDB4MAprZXJuL2Rp c2suYzozMTI6IENsb3NpbmcgYGhkMicuCmRpc2svcmFpZC5jOjYwNDogU2Nhbm5pbmcgZm9yIFJB SUQgZGV2aWNlcwprZXJuL2Rpc2suYzoyMjA6IE9wZW5pbmcgYGhkMycuLi4KZ3J1Yi1wcm9iZTog aW5mbzogdGhlIHNpemUgb2YgaGQzIGlzIDk3Njc3MzE2OAprZXJuL2Rpc2suYzozNjg6IFJlYWRp bmcgYGhkMycuLi4KdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2 L3NkZCcgaW4gb3Blbl9kZXZpY2UoKWtlcm4vZGlzay5jOjMxMjogQ2xvc2luZyBgaGQzJy4Ka2Vy bi9kaXNrLmM6MjIwOiBPcGVuaW5nIGBoZDMnLi4uCmdydWItcHJvYmU6IGluZm86IHRoZSBzaXpl IG9mIGhkMyBpcyA5NzY3NzMxNjgKa2Vybi9wYXJ0aXRpb24uYzoxMDY6IERldGVjdGluZyBncHRf cGFydGl0aW9uX21hcC4uLgprZXJuL2Rpc2suYzozNjg6IFJlYWRpbmcgYGhkMycuLi4KdXRpbC9o b3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkZCcgaW4gb3Blbl9kZXZp Y2UoKWtlcm4vcGFydGl0aW9uLmM6MTEyOiBncHRfcGFydGl0aW9uX21hcCBkZXRlY3Rpb24gZmFp bGVkLgprZXJuL3BhcnRpdGlvbi5jOjEwNjogRGV0ZWN0aW5nIGFwcGxlX3BhcnRpdGlvbl9tYXAu Li4Ka2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDMnLi4uCnBhcnRtYXAvYXBwbGUuYzoxMjk6 IGJhZCBtYWdpYyAoZm91bmQgMHhlYjRjOyB3YW50ZWQgMHg0NTUyCmtlcm4vcGFydGl0aW9uLmM6 MTEyOiBhcHBsZV9wYXJ0aXRpb25fbWFwIGRldGVjdGlvbiBmYWlsZWQuCmtlcm4vcGFydGl0aW9u LmM6MTA2OiBEZXRlY3RpbmcgcGNfcGFydGl0aW9uX21hcC4uLgprZXJuL2Rpc2suYzozNjg6IFJl YWRpbmcgYGhkMycuLi4KcGFydG1hcC9wYy5jOjE0MzogcGFydGl0aW9uIDA6IGZsYWcgMHgwLCB0 eXBlIDB4OGUsIHN0YXJ0IDB4M2YsIGxlbiAweDNhMzg0YzAyCmtlcm4vcGFydGl0aW9uLmM6MTE3 OiBwY19wYXJ0aXRpb25fbWFwIGRldGVjdGlvbiBzdWNjZWVkZWQuCmtlcm4vZGlzay5jOjM2ODog UmVhZGluZyBgaGQzJy4uLgpwYXJ0bWFwL3BjLmM6MTQzOiBwYXJ0aXRpb24gMDogZmxhZyAweDAs IHR5cGUgMHg4ZSwgc3RhcnQgMHgzZiwgbGVuIDB4M2EzODRjMDIKZGlzay9yYWlkLmM6NjA0OiBT Y2FubmluZyBmb3IgUkFJRCBkZXZpY2VzCmtlcm4vZGlzay5jOjIyMDogT3BlbmluZyBgaGQzLDEn Li4uCmdydWItcHJvYmU6IGluZm86IHRoZSBzaXplIG9mIGhkMyBpcyA5NzY3NzMxNjgKa2Vybi9k aXNrLmM6MzY4OiBSZWFkaW5nIGBoZDMsMScuLi4Ka2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBo ZDMsMScuLi4KcGFydG1hcC9hcHBsZS5jOjEyOTogYmFkIG1hZ2ljIChmb3VuZCAweGViNGM7IHdh bnRlZCAweDQ1NTIKa2Vybi9kaXNrLmM6MzY4OiBSZWFkaW5nIGBoZDMsMScuLi4KcGFydG1hcC9w Yy5jOjE0MzogcGFydGl0aW9uIDA6IGZsYWcgMHgwLCB0eXBlIDB4OGUsIHN0YXJ0IDB4M2YsIGxl biAweDNhMzg0YzAyCmtlcm4vZGlzay5jOjM2ODogUmVhZGluZyBgaGQzLDEnLi4uCnV0aWwvaG9z dGRpc2suYzozMTY6IG9wZW5pbmcgdGhlIGRldmljZSBgL2Rldi9zZGQxJyBpbiBvcGVuX2Rldmlj ZSgpdXRpbC9ob3N0ZGlzay5jOjMxNjogb3BlbmluZyB0aGUgZGV2aWNlIGAvZGV2L3NkZDEnIGlu IG9wZW5fZGV2aWNlKClrZXJuL2Rpc2suYzozMTI6IENsb3NpbmcgYGhkMywxJy4KcGFydG1hcC9w Yy5jOjE0MzogcGFydGl0aW9uIDE6IGZsYWcgMHgwLCB0eXBlIDB4MCwgc3RhcnQgMHgwLCBsZW4g MHgwCnBhcnRtYXAvcGMuYzoxNDM6IHBhcnRpdGlvbiAyOiBmbGFnIDB4MCwgdHlwZSAweDAsIHN0 YXJ0IDB4MCwgbGVuIDB4MApwYXJ0bWFwL3BjLmM6MTQzOiBwYXJ0aXRpb24gMzogZmxhZyAweDAs IHR5cGUgMHgwLCBzdGFydCAweDAsIGxlbiAweDAKa2Vybi9kaXNrLmM6MzEyOiBDbG9zaW5nIGBo ZDMnLgpncnViLXByb2JlOiBpbmZvOiBvcGVuaW5nIFVidW50dS1oYXJkeTY0Cmtlcm4vZGlzay5j OjIyMDogT3BlbmluZyBgVWJ1bnR1LWhhcmR5NjQnLi4uCmtlcm4vZGlzay5jOjI5OTogT3Blbmlu ZyBgVWJ1bnR1LWhhcmR5NjQnIGZhaWxlZC4Ka2Vybi9kaXNrLmM6MzEyOiBDbG9zaW5nIGBVYnVu dHUtaGFyZHk2NCcuCmdydWItcHJvYmU6IGVycm9yOiBubyBtYXBwaW5nIGV4aXN0cyBmb3IgYFVi dW50dS1oYXJkeTY0JwoK ------=_Part_36883_23316214.1223161008632-- From MAILER-DAEMON Sat Oct 04 18:59:20 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmG5n-0000yo-QR for mharc-grub-devel@gnu.org; Sat, 04 Oct 2008 18:59:19 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmG5l-0000ya-CY for grub-devel@gnu.org; Sat, 04 Oct 2008 18:59:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmG5i-0000yO-Tq for grub-devel@gnu.org; Sat, 04 Oct 2008 18:59:16 -0400 Received: from [199.232.76.173] (port=60535 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmG5i-0000yL-LN for grub-devel@gnu.org; Sat, 04 Oct 2008 18:59:14 -0400 Received: from fk-out-0910.google.com ([209.85.128.186]:35452) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmG5i-0002PP-BP for grub-devel@gnu.org; Sat, 04 Oct 2008 18:59:14 -0400 Received: by fk-out-0910.google.com with SMTP id 18so1665851fkq.10 for ; Sat, 04 Oct 2008 15:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=qLCVVYRiLw7+3giC5cpYvs4vc89uCY7NQCbwwDghL6w=; b=hgJoSWNhtjAUfFkkDFPkPjLq61TDLVkjL4uSvMJ6GDxt3DAscKWwnu9P5/895oBixr LG8uKLOJdqUeL0NpBP/iVpSj+Z62Da4nJdhm9CG7b+rkIH7MuMgmdRzUEndGOlGsvI7b fhC7k7BmnYDFIvwiQPtnsbagHLWrJd0jSmKfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=q3YbW2asZem1pAyoAsiZLAnurH/p1iuXNTj3qBptfOU+sDyR9OK7iKEtmqYP4TLZyT OdmBgNi6ZwxWk6/6jyN1x3lyw9z10hoJfeRwEgw48dVHoc+rppEQFVVz7q50j0oD8Esz theQ63+L9iihCJ4NI1HUM3hnGy1SwQFeiZHrI= Received: by 10.180.252.8 with SMTP id z8mr2250296bkh.82.1223161152235; Sat, 04 Oct 2008 15:59:12 -0700 (PDT) Received: by 10.181.15.13 with HTTP; Sat, 4 Oct 2008 15:59:12 -0700 (PDT) Message-ID: Date: Sun, 5 Oct 2008 08:59:12 +1000 From: "Cameron Braid" Sender: cbraid@gmail.com To: "The development of GRUB 2" In-Reply-To: <264154299.32731223135767648.JavaMail.root@aczmb1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_36923_14927646.1223161152211" References: <264154299.32731223135767648.JavaMail.root@aczmb1> X-Google-Sender-Auth: 02a8ce37fd551edf X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: grub2 /boot on lvm on ubuntu - incorrect magic number X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 22:59:18 -0000 ------=_Part_36923_14927646.1223161152211 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline > $ sudo grub-install /dev/mapper/Ubuntu-hardy64 I thought that the install_device argument to grub-install had to be a harddisk (to use the MBR) or a partition in which the grub image was installed. And I thought that grub detects the abstraction based on what /boot points to. Cameron On Sun, Oct 5, 2008 at 1:56 AM, Andy Goth wrote: > "Cameron Braid" wrote: > > * root partition is a lvm device (/dev/mapper/Ubuntu-hardy64) > > > > beast:grub2$ sudo grub-install /dev/sdd > > From looking at the GRUB 1.96 sources, I get the impression that this > command line should be: > > $ sudo grub-install /dev/mapper/Ubuntu-hardy64 > > in order for grub-probe to see the abstraction as GRUB_DEV_ABSTRACTION_LVM. > > I could be majorly wrong, and this may have changed between 1.96 and the > version that Cameron is using, but... I'm just trying to figure out how GRUB > works. :^) > > -- > Andy Goth | http://andy.junkdrome.org/ > unununium@{aircanopy.net,openverse.com} > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ------=_Part_36923_14927646.1223161152211 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
> $ sudo grub-install /dev/mapper/Ubuntu-hardy64

I thought that the install_device argument to grub-install had to be a harddisk (to use the MBR) or a partition in which the grub image was installed.  And I thought that grub detects the abstraction based on what /boot points to.

Cameron


On Sun, Oct 5, 2008 at 1:56 AM, Andy Goth <unununium@aircanopy.net> wrote:
"Cameron Braid" <cameron@braid.com.au> wrote:
> * root partition is a lvm device (/dev/mapper/Ubuntu-hardy64)
>
> beast:grub2$ sudo grub-install /dev/sdd

From looking at the GRUB 1.96 sources, I get the impression that this command line should be:

$ sudo grub-install /dev/mapper/Ubuntu-hardy64

in order for grub-probe to see the abstraction as GRUB_DEV_ABSTRACTION_LVM.

I could be majorly wrong, and this may have changed between 1.96 and the version that Cameron is using, but... I'm just trying to figure out how GRUB works. :^)

--
Andy Goth | http://andy.junkdrome.org/
unununium@{aircanopy.net,openverse.com}


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

------=_Part_36923_14927646.1223161152211-- From MAILER-DAEMON Sun Oct 05 00:44:04 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmLTQ-0006QK-CX for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 00:44:04 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmLTO-0006Q6-Cx for grub-devel@gnu.org; Sun, 05 Oct 2008 00:44:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmLTL-0006Pm-T5 for grub-devel@gnu.org; Sun, 05 Oct 2008 00:44:00 -0400 Received: from [199.232.76.173] (port=46420 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmLTL-0006Pj-PI for grub-devel@gnu.org; Sun, 05 Oct 2008 00:43:59 -0400 Received: from gateway02.websitewelcome.com ([69.93.106.20]:36156) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KmLTL-0003iz-M4 for grub-devel@gnu.org; Sun, 05 Oct 2008 00:44:00 -0400 Received: (qmail 8141 invoked from network); 5 Oct 2008 05:00:07 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway02.websitewelcome.com with SMTP; 5 Oct 2008 05:00:07 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:55376 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KmLT9-0000wi-Pk for grub-devel@gnu.org; Sat, 04 Oct 2008 23:43:47 -0500 Date: Sat, 4 Oct 2008 21:43:28 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081004214328.57e8f709@gibibit.com> In-Reply-To: <20080830235833.3b29b3c2@gamma.lan> References: <20080830235833.3b29b3c2@gamma.lan> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/nrMENW07vs4KfPu.wmdROvh"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: [PATCH] GSoC #07 VBE double buffering (vs r1885) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 04:44:03 -0000 --Sig_/nrMENW07vs4KfPu.wmdROvh Content-Type: multipart/mixed; boundary="MP_/GJ8HTpPRlXAP5VqtFbwynbV" --MP_/GJ8HTpPRlXAP5VqtFbwynbV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Clean patch against trunk SVN revision 1885. Regards, Colin --MP_/GJ8HTpPRlXAP5VqtFbwynbV Content-Type: text/x-patch; name=07_vbe-doublebuf_r1885.patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=07_vbe-doublebuf_r1885.patch =3D=3D=3D modified file 'include/grub/video.h' --- include/grub/video.h 2008-09-07 14:55:58 +0000 +++ include/grub/video.h 2008-10-05 04:29:17 +0000 @@ -47,10 +47,10 @@ #define GRUB_VIDEO_MODE_TYPE_DEPTH_MASK 0x0000ff00 #define GRUB_VIDEO_MODE_TYPE_DEPTH_POS 8 =20 -/* Defined predefined render targets. */ -#define GRUB_VIDEO_RENDER_TARGET_DISPLAY ((struct grub_video_render_target= *) 0) -#define GRUB_VIDEO_RENDER_TARGET_FRONT_BUFFER ((struct grub_video_render_t= arget *) 0) -#define GRUB_VIDEO_RENDER_TARGET_BACK_BUFFER ((struct grub_video_render_ta= rget *) 1) +/* The basic render target representing the whole display. This always + renders to the back buffer when double-buffering is in use. */ +#define GRUB_VIDEO_RENDER_TARGET_DISPLAY \ + ((struct grub_video_render_target *) 0) =20 /* Defined blitting formats. */ enum grub_video_blit_format =3D=3D=3D modified file 'video/i386/pc/vbe.c' --- video/i386/pc/vbe.c 2008-09-07 14:55:58 +0000 +++ video/i386/pc/vbe.c 2008-10-05 04:29:17 +0000 @@ -63,6 +63,7 @@ static struct { struct grub_video_render_target render_target; + int is_double_buffered; /* Is the video mode double buffered? */ =20 unsigned int bytes_per_scan_line; unsigned int bytes_per_pixel; @@ -77,6 +78,24 @@ static grub_uint32_t mode_in_use =3D 0x55aa; static grub_uint16_t *mode_list; =20 +static struct=20 +{ + grub_size_t page_size; /* The size of a page in bytes. */ + + /* For page flipping strategy. */ + int displayed_page; /* The page # that is the front buffer. */ + int render_page; /* The page # that is the back buffer. */ + + /* For blit strategy. */ + grub_uint8_t *offscreen_buffer; + + /* Virtual functions. */ + int (*update_screen) (void); + int (*destroy) (void); +} doublebuf_state; + +static void double_buffering_init (void); + static void * real2pm (grub_vbe_farptr_t ptr) { @@ -376,6 +395,7 @@ /* Reset frame buffer and render target variables. */ grub_memset (&framebuffer, 0, sizeof(framebuffer)); render_target =3D &framebuffer.render_target; + grub_memset (&doublebuf_state, 0, sizeof(doublebuf_state)); =20 return GRUB_ERR_NONE; } @@ -391,6 +411,9 @@ /* TODO: Decide, is this something we want to do. */ return grub_errno; =20 + if (doublebuf_state.destroy) + doublebuf_state.destroy(); + /* TODO: Free any resources allocated by driver. */ grub_free (mode_list); mode_list =3D 0; @@ -533,9 +556,12 @@ render_target->viewport.width =3D active_mode_info.x_resolution; render_target->viewport.height =3D active_mode_info.y_resolution; =20 - /* Set framebuffer pointer and mark it as non allocated. */ + /* Mark framebuffer memory as non allocated. */ render_target->is_allocated =3D 0; - render_target->data =3D framebuffer.ptr; + /* Set up double buffering information. */ + framebuffer.is_double_buffered =3D + ((mode_type & GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED) !=3D 0); + double_buffering_init (); =20 /* Copy default palette to initialize emulated palette. */ for (i =3D 0; @@ -556,6 +582,166 @@ return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "no matching mode found."); } =20 +/*=20 + Set framebuffer render target page and display the proper page, based on + `doublebuf_state.render_page' and `doublebuf_state.displayed_page', + respectively.=20 + + Returns 0 upon success, nonzero upon failure. + */ +static int +doublebuf_pageflipping_commit (void) +{ + /* Set the render target's data pointer to the start of the render_page.= */ + framebuffer.render_target.data =3D + ((char *) framebuffer.ptr) + + doublebuf_state.page_size * doublebuf_state.render_page; + + /* Tell the video adapter to display the new front page. */ + int display_start_line =3D + framebuffer.render_target.mode_info.height=20 + * doublebuf_state.displayed_page; +=20 + grub_vbe_status_t vbe_err =3D=20 + grub_vbe_bios_set_display_start (0, display_start_line); + if (vbe_err !=3D GRUB_VBE_STATUS_OK) + return 1; + + return 0; +} + +static int +doublebuf_pageflipping_update_screen (void) +{ + /* Swap the page numbers in the framebuffer struct. */ + int new_displayed_page =3D doublebuf_state.render_page; + doublebuf_state.render_page =3D doublebuf_state.displayed_page; + doublebuf_state.displayed_page =3D new_displayed_page; + + return doublebuf_pageflipping_commit (); +} + +static int +doublebuf_pageflipping_destroy (void) +{ + doublebuf_state.update_screen =3D 0; + doublebuf_state.destroy =3D 0; + return 0; +} + +static int +doublebuf_pageflipping_init (void) +{ + doublebuf_state.page_size =3D + framebuffer.bytes_per_scan_line * render_target->mode_info.height; + =20 + /* Get video RAM size in bytes. */ + grub_size_t vram_size =3D controller_info.total_memory << 16; + + if (2 * doublebuf_state.page_size > vram_size) + return 1; /* Not enough video memory for 2 pages. */ + + doublebuf_state.displayed_page =3D 0; + doublebuf_state.render_page =3D 1; + + doublebuf_state.update_screen =3D doublebuf_pageflipping_update_screen; + doublebuf_state.destroy =3D doublebuf_pageflipping_destroy; + + /* Set the framebuffer memory data pointer and display the right page. */ + if (doublebuf_pageflipping_commit () !=3D GRUB_ERR_NONE) + return 1; /* Unable to set the display start. */ + + framebuffer.render_target.mode_info.mode_type + |=3D GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED; + return 0; +} + +static int +doublebuf_blit_update_screen (void) +{ + grub_memcpy (framebuffer.ptr, + doublebuf_state.offscreen_buffer,=20 + doublebuf_state.page_size); + return 0; +} + +static int +doublebuf_blit_destroy (void) +{ + grub_free (doublebuf_state.offscreen_buffer); + doublebuf_state.offscreen_buffer =3D 0; + + doublebuf_state.update_screen =3D 0; + doublebuf_state.destroy =3D 0; + return 0; +} + +static int +doublebuf_blit_init (void) +{ + doublebuf_state.page_size =3D + framebuffer.bytes_per_scan_line * render_target->mode_info.height; + + doublebuf_state.offscreen_buffer =3D (grub_uint8_t *) + grub_malloc (doublebuf_state.page_size); + if (doublebuf_state.offscreen_buffer =3D=3D 0) + return 1; /* Error. */ + + framebuffer.render_target.data =3D doublebuf_state.offscreen_buffer; + doublebuf_state.update_screen =3D doublebuf_blit_update_screen; + doublebuf_state.destroy =3D doublebuf_blit_destroy; + + framebuffer.render_target.mode_info.mode_type + |=3D GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED; + return 0; +} + +static int +doublebuf_null_update_screen (void) +{ + return 0; +} + +static int +doublebuf_null_destroy (void) +{ + doublebuf_state.update_screen =3D 0; + doublebuf_state.destroy =3D 0; + return 0; +} + +static int +doublebuf_null_init (void) +{ + framebuffer.render_target.data =3D framebuffer.ptr; + doublebuf_state.update_screen =3D doublebuf_null_update_screen; + doublebuf_state.destroy =3D doublebuf_null_destroy; + + framebuffer.render_target.mode_info.mode_type + &=3D ~GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED; + return 0; +} + +/* Select the best double buffering mode available. */ +static void +double_buffering_init (void) +{ + if (doublebuf_state.destroy) + doublebuf_state.destroy(); + + if (framebuffer.is_double_buffered) + { + if (doublebuf_pageflipping_init () =3D=3D 0) + return; + + if (doublebuf_blit_init () =3D=3D 0) + return; + } + + /* Fall back to no double buffering. */ + doublebuf_null_init (); +} + static grub_err_t grub_video_vbe_get_info (struct grub_video_mode_info *mode_info) { @@ -1475,7 +1661,10 @@ static grub_err_t grub_video_vbe_swap_buffers (void) { - /* TODO: Implement buffer swapping. */ + if (doublebuf_state.update_screen () !=3D 0) + return grub_error (GRUB_ERR_INVALID_COMMAND, + "Double buffer update failed"); + return GRUB_ERR_NONE; } =20 @@ -1574,17 +1763,13 @@ static grub_err_t grub_video_vbe_set_active_render_target (struct grub_video_render_target *= target) { - if (target =3D=3D GRUB_VIDEO_RENDER_TARGET_FRONT_BUFFER) + if (target =3D=3D GRUB_VIDEO_RENDER_TARGET_DISPLAY) { render_target =3D &framebuffer.render_target; =20 return GRUB_ERR_NONE; } =20 - if (target =3D=3D GRUB_VIDEO_RENDER_TARGET_BACK_BUFFER) - return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, - "double buffering not implemented yet."); - if (! target->data) return grub_error (GRUB_ERR_BAD_ARGUMENT, "invalid render target given."); --MP_/GJ8HTpPRlXAP5VqtFbwynbV-- --Sig_/nrMENW07vs4KfPu.wmdROvh Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjoRfMACgkQokx8fzcGbYfxgwCdHVX9WAKRtqmSZ3LfBe5kk4W9 9hgAn07Z2Dxzy0xnptBbkoCDw56VMXnj =J8pq -----END PGP SIGNATURE----- --Sig_/nrMENW07vs4KfPu.wmdROvh-- From MAILER-DAEMON Sun Oct 05 00:48:08 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmLXM-0007Hr-9m for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 00:48:08 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmLXI-0007Hm-Tu for grub-devel@gnu.org; Sun, 05 Oct 2008 00:48:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmLXG-0007Ha-2v for grub-devel@gnu.org; Sun, 05 Oct 2008 00:48:03 -0400 Received: from [199.232.76.173] (port=47574 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmLXF-0007HQ-VA for grub-devel@gnu.org; Sun, 05 Oct 2008 00:48:02 -0400 Received: from gateway12.websitewelcome.com ([67.18.68.6]:43044) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KmLXF-0004h6-Cq for grub-devel@gnu.org; Sun, 05 Oct 2008 00:48:02 -0400 Received: (qmail 26719 invoked from network); 5 Oct 2008 04:57:18 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway12.websitewelcome.com with SMTP; 5 Oct 2008 04:57:18 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:47154 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KmLX4-0001Jn-9i for grub-devel@gnu.org; Sat, 04 Oct 2008 23:47:50 -0500 Date: Sat, 4 Oct 2008 21:46:40 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081004214640.5ab21f53@gibibit.com> In-Reply-To: <20080901092753.3918cf73@gamma.lan> References: <20080901092753.3918cf73@gamma.lan> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/xR5Sh3OVu2Z6XagzDVqwjrN"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: [PATCH] GSoC #10 new font engine (vs r1885) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 04:48:05 -0000 --Sig_/xR5Sh3OVu2Z6XagzDVqwjrN Content-Type: multipart/mixed; boundary="MP_/yGNypotXh4x=ITpmchIzMwg" --MP_/yGNypotXh4x=ITpmchIzMwg Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Clean patch against SVN revision 1885. Regards, Colin --MP_/yGNypotXh4x=ITpmchIzMwg Content-Type: text/x-patch; name=10_font-engine_r1885.patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=10_font-engine_r1885.patch =3D=3D=3D modified file 'commands/videotest.c' --- commands/videotest.c 2007-07-21 22:32:33 +0000 +++ commands/videotest.c 2008-10-05 04:30:04 +0000 @@ -44,7 +44,8 @@ unsigned int width; unsigned int height; int i; - struct grub_font_glyph glyph; + grub_font_t font; + struct grub_font_glyph *glyph; struct grub_video_render_target *text_layer; grub_video_color_t palette[16]; =20 @@ -65,8 +66,12 @@ color =3D grub_video_map_rgb (0, 255, 255); grub_video_fill_rect (color, 100, 100, 100, 100); =20 - grub_font_get_glyph ('*', &glyph); =20 - grub_video_blit_glyph (&glyph, color, 200 ,0); + font =3D grub_font_get ("Helvetica Bold 14"); + if (! font) + return grub_error (GRUB_ERR_BAD_FONT, "No font loaded."); + + glyph =3D grub_font_get_glyph (font, '*'); =20 + grub_video_blit_glyph (glyph, color, 200 ,0); =20 grub_video_set_viewport (x + 150, y + 150, width - 150 * 2, height - 150 * 2); @@ -77,18 +82,18 @@ =20 color =3D grub_video_map_rgb (255, 255, 255); =20 - grub_font_get_glyph ('A', &glyph); - grub_video_blit_glyph (&glyph, color, 16, 16); - grub_font_get_glyph ('B', &glyph); - grub_video_blit_glyph (&glyph, color, 16 * 2, 16); + glyph =3D grub_font_get_glyph (font, 'A'); + grub_video_blit_glyph (glyph, color, 16, 16); + glyph =3D grub_font_get_glyph (font, 'B'); + grub_video_blit_glyph (glyph, color, 16 * 2, 16); =20 - grub_font_get_glyph ('*', &glyph); + glyph =3D grub_font_get_glyph (font, '*'); =20 for (i =3D 0; i < 16; i++) { color =3D grub_video_map_color (i); palette[i] =3D color; - grub_video_blit_glyph (&glyph, color, 16 + i * 16, 32); + grub_video_blit_glyph (glyph, color, 16 + i * 16, 32); } =20 grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); =3D=3D=3D modified file 'conf/common.rmk' --- conf/common.rmk 2008-09-29 13:57:05 +0000 +++ conf/common.rmk 2008-10-05 04:30:04 +0000 @@ -364,7 +364,7 @@ help_mod_LDFLAGS =3D $(COMMON_LDFLAGS) =20 # For font.mod. -font_mod_SOURCES =3D font/manager.c +font_mod_SOURCES =3D font/font_cmd.c font/font.c font/loader.c font_mod_CFLAGS =3D $(COMMON_CFLAGS) font_mod_LDFLAGS =3D $(COMMON_LDFLAGS) =20 =3D=3D=3D modified file 'conf/sparc64-ieee1275.rmk' --- conf/sparc64-ieee1275.rmk 2008-09-08 12:52:30 +0000 +++ conf/sparc64-ieee1275.rmk 2008-10-05 04:30:04 +0000 @@ -196,7 +196,7 @@ cat_mod_LDFLAGS =3D $(COMMON_LDFLAGS) =20 # For font.mod. -font_mod_SOURCES =3D font/manager.c +font_mod_SOURCES =3D font/font_cmd.c font/font.c font/loader.c font_mod_CFLAGS =3D $(COMMON_CFLAGS) font_mod_LDFLAGS =3D $(COMMON_LDFLAGS) =20 =3D=3D=3D added file 'font/font.c' --- font/font.c 1970-01-01 00:00:00 +0000 +++ font/font.c 2008-10-05 04:30:04 +0000 @@ -0,0 +1,92 @@ +/* font.c - Font functions. */ +/* + * GRUB -- GRand Unified Bootloader + * Copyright (C) 2008 Free Software Foundation, Inc. + * + * GRUB is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * GRUB is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with GRUB. If not, see . + */ + +#include +#include +#include +#include +#include +#include +#include + +grub_font_t +grub_font_get (const char *font_name) +{ + struct font_node *node; + + for (node =3D grub_font_list; node; node =3D node->next) + { + grub_font_t font =3D node->value; + if (grub_strcmp (font->name, font_name) =3D=3D 0) + return font; + } + + /* If no font by that name is found, return the first font in the list + * as a fallback. */ + return grub_font_list->value; +} + +const char * +grub_font_get_name (grub_font_t font) +{ + return font->name; +} + +int +grub_font_get_max_char_width (grub_font_t font) +{ + return font->max_char_width; +} + +int +grub_font_get_max_char_height (grub_font_t font) +{ + return font->max_char_height; +} + +int +grub_font_get_ascent (grub_font_t font) +{ + return font->ascent; +} + +int +grub_font_get_descent (grub_font_t font) +{ + return font->descent; +} + +int +grub_font_get_string_width (grub_font_t font, const char *str) +{ + int i; + int width; + struct grub_font_glyph *glyph; + grub_size_t len; + + len =3D grub_strlen (str); + + for (i =3D 0, width =3D 0; i < len; i++) + { + glyph =3D grub_font_get_glyph (font, str[i]); + width +=3D glyph->device_width; + } + + return width; +} =3D=3D=3D added file 'font/font_cmd.c' --- font/font_cmd.c 1970-01-01 00:00:00 +0000 +++ font/font_cmd.c 2008-10-05 04:30:04 +0000 @@ -0,0 +1,75 @@ +/* font_cmd.c - Font command definition. */ +/* + * GRUB -- GRand Unified Bootloader + * Copyright (C) 2003,2005,2006,2007 Free Software Foundation, Inc. + * + * GRUB is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * GRUB is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with GRUB. If not, see . + */ + +#include +#include + +static grub_err_t +loadfont_command (struct grub_arg_list *state __attribute__ ((unused)), + int argc, + char **args) +{ + if (argc =3D=3D 0) + return grub_error (GRUB_ERR_BAD_ARGUMENT, "no font specified"); + + while (argc--) + if (grub_font_load (*args++) !=3D 0) + return GRUB_ERR_BAD_FONT; + + return GRUB_ERR_NONE; +} + +static grub_err_t +lsfonts_command (struct grub_arg_list *state __attribute__ ((unused)), + int argc __attribute__ ((unused)), + char **args __attribute__ ((unused))) +{ + struct font_node *node; + + grub_printf ("Loaded fonts:\n"); + for (node =3D grub_font_list; node; node =3D node->next) + { + grub_font_t font =3D node->value; + grub_printf ("%s\n", font->name); + } + + return GRUB_ERR_NONE; +} + +GRUB_MOD_INIT(font_manager) +{ + grub_font_loader_init (); + + grub_register_command ("loadfont", loadfont_command, GRUB_COMMAND_FLAG_B= OTH, + "loadfont FILE...", + "Specify one or more font files to load.", 0); + + grub_register_command ("lsfonts", lsfonts_command, GRUB_COMMAND_FLAG_BOT= H, + "lsfonts", + "List the loaded fonts.", 0); +} + +GRUB_MOD_FINI(font_manager) +{ + /* Should this free fonts, unknown_glyph, etc.? Freeing fonts could=20 + * be a Bad Thing if there are still references to any of them. */ + + grub_unregister_command ("loadfont"); +} + =3D=3D=3D added file 'font/loader.c' --- font/loader.c 1970-01-01 00:00:00 +0000 +++ font/loader.c 2008-10-05 04:30:04 +0000 @@ -0,0 +1,689 @@ +/* loader.c - Functions to handle loading fonts and glyphs from files. */ +/* + * GRUB -- GRand Unified Bootloader + * Copyright (C) 2003,2005,2006,2007,2008 Free Software Foundation, Inc. + * + * GRUB is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * GRUB is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with GRUB. If not, see . + */ + +#include +#include +#include +#include +#include +#include + +/* Definition of font registry. */ +struct font_node *grub_font_list; + +static int register_font (grub_font_t font); +static void free_font (grub_font_t font); +static void remove_font (grub_font_t font); + +struct font_file_section +{ + grub_file_t file; /* The file this section is in. */ + char name[4]; /* FOURCC name of the section. */ + grub_uint32_t length; /* Length of the section contents. */ + int eof; /* Set by open_section() on EOF. */ +}; + +/* Font file format constants. */ +static const char pff2_magic[4] =3D { 'P', 'F', 'F', '2' }; +static const char section_names_file[4] =3D { 'F', 'I', 'L', 'E' }; +static const char section_names_font_name[4] =3D { 'N', 'A', 'M', 'E' }; +static const char section_names_max_char_width[4] =3D { 'M', 'A', 'X', 'W'= }; +static const char section_names_max_char_height[4] =3D { 'M', 'A', 'X', 'H= ' }; +static const char section_names_ascent[4] =3D { 'A', 'S', 'C', 'E' }; +static const char section_names_descent[4] =3D { 'D', 'E', 'S', 'C' }; +static const char section_names_char_index[4] =3D { 'C', 'H', 'I', 'X' }; +static const char section_names_data[4] =3D { 'D', 'A', 'T', 'A' }; + +/* Replace unknown glyphs with a rounded question mark. */ +static grub_uint8_t unknown_glyph_bitmap[] =3D +{ + /* 76543210 */ + 0x7C, /* ooooo */ + 0x82, /* o o */ + 0xBA, /* o ooo o */ + 0xAA, /* o o o o */ + 0xAA, /* o o o o */ + 0x8A, /* o o o */ + 0x9A, /* o oo o */ + 0x92, /* o o o */ + 0x92, /* o o o */ + 0x92, /* o o o */ + 0x92, /* o o o */ + 0x82, /* o o */ + 0x92, /* o o o */ + 0x82, /* o o */ + 0x7C, /* ooooo */ + 0x00 /* */ +}; + +static struct grub_font_glyph *unknown_glyph; + +void +grub_font_loader_init (void) +{ + unknown_glyph =3D grub_malloc(sizeof(struct grub_font_glyph) + + sizeof(unknown_glyph_bitmap)); + if (! unknown_glyph) + return; + + unknown_glyph->width =3D 8; + unknown_glyph->height =3D 16; + unknown_glyph->offset_x =3D 0; + unknown_glyph->offset_y =3D 0; + unknown_glyph->device_width =3D 8; + grub_memcpy(unknown_glyph->bitmap, + unknown_glyph_bitmap, sizeof(unknown_glyph_bitmap)); +} + +/* + Open the next section in the file. + + On success, the section name is stored in section->name and the length = in + section->length, and 0 is returned. On failure, 1 is returned and + grub_errno is set approriately with an error message. + + If 1 is returned due to being at the end of the file, then section->eof= is + set to 1; otherwise, section->eof is set to 0. + */ +static int +open_section (grub_file_t file, struct font_file_section *section) +{ + grub_ssize_t retval; + grub_uint32_t raw_length; + + section->file =3D file; + section->eof =3D 0; + + /* Read the FOURCC section name. */ + retval =3D grub_file_read (file, section->name, 4); + if (retval >=3D 0 && retval < 4) + { + section->eof =3D 1; + return 1; /* EOF encountered. */ + } + else if (retval < 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font format error: can't read section name"); + return 1; /* Read error. */ + } + + /* Read the big-endian 32-bit section length. */ + retval =3D grub_file_read (file, (char *) &raw_length, 4); + if (retval >=3D 0 && retval < 4) + { + section->eof =3D 1; + return 1; /* EOF encountered. */ + } + else if (retval < 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font format error: can't read section length"); + return 1; /* Read error. */ + } + + /* Convert byte-order and store in *length. */ + section->length =3D grub_be_to_cpu32 (raw_length); + + return 0; +} + +/* Size in bytes of each character index (CHIX section) + entry in the font file. */ +#define FONT_CHAR_INDEX_ENTRY_SIZE (4 + 1 + 4) + +/* + Load the character index (CHIX) section contents from the font file. T= his + presumes that the position of FILE is positioned immediately after the + section length for the CHIX section (i.e., at the start of the section + contents). Returns 0 upon success, nonzero for failure (in which case + grub_errno is set appropriately). + */ +static int +load_font_index (grub_file_t file, grub_uint32_t sect_length, struct + grub_font *font) +{ + unsigned i; + +#if FONT_DEBUG >=3D 2 + grub_printf("load_font_index(sect_length=3D%d)\n", sect_length); +#endif + + /* Sanity check: ensure section length is divisible by the entry size. = */ + if (sect_length % FONT_CHAR_INDEX_ENTRY_SIZE !=3D 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font file format error: character index length %d " + "is not a multiple of the entry size %d", + sect_length, FONT_CHAR_INDEX_ENTRY_SIZE); + return 1; /* Invalid index section length. */ + } + + /* Calculate the number of characters. */ + font->num_chars =3D sect_length / FONT_CHAR_INDEX_ENTRY_SIZE; + + /* Allocate the character index array. */ + font->char_index =3D grub_malloc (font->num_chars + * sizeof (struct char_index_entry)); + if (!font->char_index) + return 1; /* Error allocating memory. */ + +#if FONT_DEBUG >=3D 2 + grub_printf("num_chars=3D%d)\n", font->num_chars); +#endif + + /* Load the character index data from the file. */ + for (i =3D 0; i < font->num_chars; i++) + { + struct char_index_entry *entry =3D &font->char_index[i]; + + /* Read code point value; convert to native byte order. */ + if (grub_file_read (file, (char *) &entry->code, 4) !=3D 4) + return 1; + entry->code =3D grub_be_to_cpu32 (entry->code); + + /* Read storage flags byte. */ + if (grub_file_read (file, (char *) &entry->storage_flags, 1) !=3D 1) + return 1; + + /* Read glyph data offset; convert to native byte order. */ + if (grub_file_read (file, (char *) &entry->offset, 4) !=3D 4) + return 1; + entry->offset =3D grub_be_to_cpu32 (entry->offset); + + /* No glyph loaded. Will be loaded on demand and cached thereafter.= */ + entry->glyph =3D 0; + +#if FONT_DEBUG >=3D 5 + if (i < 10) /* Print the 1st 10 characters. */ + grub_printf("c=3D%d o=3D%d\n", entry->code, entry->offset); +#endif + } + + return 0; /* Index loaded OK. */ +} + +/* + Read the contents of the specified section as a string, which is + allocated on the heap. Returns 0 if there is an error. + */ +static char * +read_section_as_string (struct font_file_section *section) +{ + char *str; + grub_ssize_t ret; + + str =3D grub_malloc (section->length + 1); + if (!str) + return 0; + + ret =3D grub_file_read (section->file, str, section->length); + if (ret < 0 || ret !=3D (grub_ssize_t) section->length) + { + grub_free (str); + return 0; + } + + str[section->length] =3D '\0'; + return str; +} + +/* + Read the contents of the current section as a 16-bit integer value, + which is stored into *VALUE. Returns 0 upon success, nonzero upon fail= ure. + */ +static int +read_section_as_short (struct font_file_section *section, grub_int16_t *va= lue) +{ + grub_uint16_t raw_value; + + if (section->length !=3D 2) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font file format error: section %c%c%c%c length " + "is %d but should be 2", + section->name[0], section->name[1], + section->name[2], section->name[3], + section->length); + return 1; /* An error occurred. */ + } + if (grub_file_read (section->file, (char *) &raw_value, 2) !=3D 2) + return 1; /* An error occurred. */ + + *value =3D grub_be_to_cpu16 (raw_value); + return 0; /* Successfully read the value. */ +} + +/* + Load a font and add it to the beginning of the global font list. + Returns 0 upon success, nonzero upon failure. + */ +int +grub_font_load (const char *filename) +{ + grub_file_t file =3D 0; + struct font_file_section section; + char magic[4]; + grub_font_t font =3D 0; + +#if FONT_DEBUG >=3D 1 + grub_printf("add_font(%s)\n", filename); +#endif + + file =3D grub_buffile_open (filename, 1024); + if (!file) + goto fail; + +#if FONT_DEBUG >=3D 3 + grub_printf("file opened\n"); +#endif + + /* Read the FILE section. It indicates the file format. */ + if (open_section (file, §ion) !=3D 0) + goto fail; + +#if FONT_DEBUG >=3D 3 + grub_printf("opened FILE section\n"); +#endif + if (grub_memcmp (section.name, section_names_file, 4) !=3D 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font file format error: 1st section must be FILE"); + goto fail; + } + +#if FONT_DEBUG >=3D 3 + grub_printf("section name ok\n"); +#endif + if (section.length !=3D 4) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font file format error (file type ID length is %d " + "but should be 4)", section.length); + goto fail; + } + +#if FONT_DEBUG >=3D 3 + grub_printf("section length ok\n"); +#endif + /* Check the file format type code. */ + if (grub_file_read (file, magic, 4) !=3D 4) + goto fail; + +#if FONT_DEBUG >=3D 3 + grub_printf("read magic ok\n"); +#endif + + if (grub_memcmp (magic, pff2_magic, 4) !=3D 0) + { + grub_error (GRUB_ERR_BAD_FONT, "Invalid font magic %x %x %x %x", + magic[0], magic[1], magic[2], magic[3]); + goto fail; + } + +#if FONT_DEBUG >=3D 3 + grub_printf("compare magic ok\n"); +#endif + + /* Allocate the font object. */ + font =3D (grub_font_t) grub_malloc (sizeof (struct grub_font)); + if (!font) + goto fail; + + font->file =3D file; + font->name =3D 0; + font->ascent =3D 0; + font->descent =3D 0; + font->max_char_width =3D 0; + font->max_char_height =3D 0; + font->num_chars =3D 0; + font->char_index =3D 0; + +#if FONT_DEBUG >=3D 3 + grub_printf("allocate font ok; loading font info\n"); +#endif + + /* Load the font information. */ + while (1) + { + if (open_section (file, §ion) !=3D 0) + { + if (section.eof) + break; /* Done reading the font file. */ + else + goto fail; + } + +#if FONT_DEBUG >=3D 2 + grub_printf("opened section %c%c%c%c ok\n", + section.name[0], section.name[1], + section.name[2], section.name[3]); +#endif + + if (grub_memcmp (section.name, section_names_font_name, 4) =3D=3D 0) + { + font->name =3D read_section_as_string (§ion); + if (!font->name) + goto fail; + } + else if (grub_memcmp (section.name, section_names_max_char_width, 4)= =3D=3D 0) + { + if (read_section_as_short (§ion, &font->max_char_width) !=3D= 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_max_char_height, 4= ) =3D=3D 0) + { + if (read_section_as_short (§ion, &font->max_char_height) != =3D 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_ascent, 4) =3D=3D = 0) + { + if (read_section_as_short (§ion, &font->ascent) !=3D 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_descent, 4) =3D=3D= 0) + { + if (read_section_as_short (§ion, &font->descent) !=3D 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_char_index, 4) =3D= =3D 0) + { + /* Load the font index. */ + if (load_font_index (file, section.length, font) !=3D 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_data, 4) =3D=3D 0) + { + /* When the DATA section marker is reached, we stop reading. */ + break; + } + else + { + /* Unhandled section type, simply skip past it. */ +#if FONT_DEBUG >=3D 3 + grub_printf("Unhandled section type, skipping.\n"); +#endif + grub_off_t section_end =3D grub_file_tell (file) + section.lengt= h; + if ((int) grub_file_seek (file, section_end) =3D=3D -1) + goto fail; + } + } + + if (!font->name) + { + grub_printf ("Note: Font has no name.\n"); + font->name =3D grub_strdup ("Unknown"); + } + +#if FONT_DEBUG >=3D 1 + grub_printf ("Loaded font `%s'.\n" + "Ascent=3D%d Descent=3D%d MaxW=3D%d MaxH=3D%d Number of cha= racters=3D%d.\n", + font->name, + font->ascent, font->descent, + font->max_char_width, font->max_char_height, + font->num_chars); +#endif + + if (font->max_char_width =3D=3D 0 + || font->max_char_height =3D=3D 0 + || font->num_chars =3D=3D 0 + || font->char_index =3D=3D 0 + || font->ascent =3D=3D 0 + || font->descent =3D=3D 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Invalid font file: missing some required data."); + goto fail; + } + + /* Add the font to the global font registry. */ + if (register_font (font) !=3D 0) + goto fail; + + return 0; /* Font loaded ok. */ + +fail: + free_font (font); + return 1; /* Failed to load font. */ +} + +/* + Read a 16-bit big-endian integer from FILE, convert it to native byte + order, and store it in *VALUE. + Returns 0 on success, 1 on failure. + */ +static int +read_be_uint16 (grub_file_t file, grub_uint16_t * value) +{ + if (grub_file_read (file, (char *) value, 2) !=3D 2) + return 1; + *value =3D grub_be_to_cpu16 (*value); + return 0; +} + +static int +read_be_int16 (grub_file_t file, grub_int16_t * value) +{ + /* For the signed integer version, use the same code as for unsigned. */ + return read_be_uint16 (file, (grub_uint16_t *) value); +} + +/* + Return a pointer to the character index entry for the glyph correspondi= ng to + the codepoint CODE in the font FONT. If not found, return zero. + */ +static struct char_index_entry * +find_glyph (const grub_font_t font, grub_uint32_t code) +{ + grub_uint32_t i; + grub_uint32_t len =3D font->num_chars; + struct char_index_entry *table =3D font->char_index; + + /* Do a linear search. */ + for (i =3D 0; i < len; i++) + { + if (table[i].code =3D=3D code) + return &table[i]; + } + + return 0; /* No entry found for code point CODE. */ +} + +static struct grub_font_glyph * +grub_font_get_glyph_internal (grub_font_t font, grub_uint32_t code) +{ + struct char_index_entry *index_entry; + + index_entry =3D find_glyph (font, code); + if (index_entry) + { + struct grub_font_glyph *glyph =3D 0; + grub_uint16_t width; + grub_uint16_t height; + grub_int16_t xoff; + grub_int16_t yoff; + grub_int16_t dwidth; + int len; + + if (index_entry->glyph) + return index_entry->glyph; /* Return cached glyph. */ + + /* Make sure we can find glyphs for error messages. Push active + error message to error stack and reset error message. */ + grub_error_push (); + + grub_file_seek (font->file, index_entry->offset); + + /* Read the glyph width, height, and baseline. */ + if (read_be_uint16(font->file, &width) !=3D 0 + || read_be_uint16(font->file, &height) !=3D 0 + || read_be_int16(font->file, &xoff) !=3D 0 + || read_be_int16(font->file, &yoff) !=3D 0 + || read_be_int16(font->file, &dwidth) !=3D 0) + { + remove_font (font); + return 0; + } + + len =3D (width * height + 7) / 8; + glyph =3D grub_malloc (sizeof (struct grub_font_glyph) + len); + if (! glyph) + { + remove_font (font); + return 0; + } + + glyph->font =3D font; + glyph->width =3D width; + glyph->height =3D height; + glyph->offset_x =3D xoff; + glyph->offset_y =3D yoff; + glyph->device_width =3D dwidth; + + /* Don't try to read empty bitmaps (e.g., space characters). */ + if (len !=3D 0) + { + if (grub_file_read (font->file, (char *) glyph->bitmap, len) != =3D len) + { + remove_font (font); + return 0; + } + } + + /* Restore old error message. */ + grub_error_pop (); + + /* Cache the glyph. */ + index_entry->glyph =3D glyph; + + return glyph; /* Glyph loaded ok. */ + } + + return 0; +} + +/* Get the glyph for FONT corresponding to the Unicode code point CODE. + Returns a pointer to an glyph indicating there is no glyph available + if CODE does not exist in the font. The glyphs are cached once loaded.= */ +struct grub_font_glyph * +grub_font_get_glyph (grub_font_t font, grub_uint32_t code) +{ + struct grub_font_glyph *glyph; + glyph =3D grub_font_get_glyph_internal (font, code); + if (glyph =3D=3D 0) + glyph =3D unknown_glyph; + return glyph; +} + +/* Get a glyph corresponding to the codepoint CODE. If no glyph is availa= ble + for CODE in the available fonts, then a glyph representing an unknown + character is returned. This function never returns NULL. + The returned glyph is owned by the font manager and should not be freed + by the caller. The glyphs are cached. */ +struct grub_font_glyph * +grub_font_get_glyph_any (grub_uint32_t code) +{ + struct font_node *node; + /* Keep track of next node, in case there's an I/O error in + grub_font_get_glyph() and the font is removed from the list. */ + struct font_node *next; + + for (node =3D grub_font_list; node; node =3D next) + { + grub_font_t font; + struct grub_font_glyph *glyph; + + font =3D node->value; + next =3D node->next; + + glyph =3D grub_font_get_glyph_internal (font, code); + if (glyph) + return glyph; + } + + /* Uggh... Glyph was not found in any font. */ + return unknown_glyph; /* Failed to load glyph. */ +} + +/* + Free the memory used by a font. + This should not be called if the font has been made available to + users (once it is added to the global font list), since there would + be the possibility of a dangling pointer. + */ +static void +free_font (grub_font_t font) +{ + if (font) + { + if (font->file) + grub_file_close (font->file); + if (font->name) + grub_free (font->name); + if (font->char_index) + grub_free (font->char_index); + grub_free (font); + } +} + +/* + Add FONT to the global font registry. + Returns 0 upon success, nonzero on failure (the font was not registered= ). + */ +static int +register_font (grub_font_t font) +{ + struct font_node *node =3D 0; + + node =3D grub_malloc (sizeof (struct font_node)); + if (!node) + return 1; /* Error. */ + + node->value =3D font; + node->next =3D grub_font_list; + grub_font_list =3D node; + + return 0; /* Success. */ +} + +/* + Remove the font from the global font list. We don't actually free the + font's memory since users could be holding references to the font. + */ +static void +remove_font (grub_font_t font) +{ + struct font_node **nextp, *cur; + + for (nextp =3D &grub_font_list, cur =3D *nextp; + cur; + nextp =3D &cur->next, cur =3D cur->next) + { + if (cur->value =3D=3D font) + { + *nextp =3D cur->next; + + /* Free the node, but not the font itself. */ + grub_free (cur); + + return; + } + } +} + =3D=3D=3D removed file 'font/manager.c' --- font/manager.c 2008-08-01 03:06:55 +0000 +++ font/manager.c 1970-01-01 00:00:00 +0000 @@ -1,283 +0,0 @@ -/* - * GRUB -- GRand Unified Bootloader - * Copyright (C) 2003,2005,2006,2007 Free Software Foundation, Inc. - * - * GRUB is free software: you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation, either version 3 of the License, or - * (at your option) any later version. - * - * GRUB is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with GRUB. If not, see . - */ - -#include -#include -#include -#include -#include -#include -#include -#include - -struct entry -{ - grub_uint32_t code; - grub_uint32_t offset; -}; - -struct font -{ - struct font *next; - grub_file_t file; - grub_uint32_t num; - struct entry table[0]; -}; - -static struct font *font_list; - -/* Fill unknown glyph's with rounded question mark. */ -static grub_uint8_t unknown_glyph[16] =3D -{ /* 76543210 */ - 0x7C, /* ooooo */ - 0x82, /* o o */ - 0xBA, /* o ooo o */ - 0xAA, /* o o o o */ - 0xAA, /* o o o o */ - 0x8A, /* o o o */ - 0x9A, /* o oo o */ - 0x92, /* o o o */ - 0x92, /* o o o */ - 0x92, /* o o o */ - 0x92, /* o o o */ - 0x82, /* o o */ - 0x92, /* o o o */ - 0x82, /* o o */ - 0x7C, /* ooooo */ - 0x00 /* */ -}; - -static int -add_font (const char *filename) -{ - grub_file_t file =3D 0; - char magic[4]; - grub_uint32_t num, i; - struct font *font =3D 0; - - file =3D grub_buffile_open (filename, 0); - if (! file) - goto fail; - - if (grub_file_read (file, magic, 4) !=3D 4) - goto fail; - - if (grub_memcmp (magic, GRUB_FONT_MAGIC, 4) !=3D 0) - { - grub_error (GRUB_ERR_BAD_FONT, "invalid font magic"); - goto fail; - } - - if (grub_file_read (file, (char *) &num, 4) !=3D 4) - goto fail; - - num =3D grub_le_to_cpu32 (num); - font =3D (struct font *) grub_malloc (sizeof (struct font) - + sizeof (struct entry) * num); - if (! font) - goto fail; - - font->file =3D file; - font->num =3D num; - - for (i =3D 0; i < num; i++) - { - grub_uint32_t code, offset; - =20 - if (grub_file_read (file, (char *) &code, 4) !=3D 4) - goto fail; - - if (grub_file_read (file, (char *) &offset, 4) !=3D 4) - goto fail; - - font->table[i].code =3D grub_le_to_cpu32 (code); - font->table[i].offset =3D grub_le_to_cpu32 (offset); - } - - font->next =3D font_list; - font_list =3D font; - - return 1; - - fail: - if (font) - grub_free (font); - - if (file) - grub_file_close (file); - - return 0; -} - -static void -remove_font (struct font *font) -{ - struct font **p, *q; - - for (p =3D &font_list, q =3D *p; q; p =3D &(q->next), q =3D q->next) - if (q =3D=3D font) - { - *p =3D q->next; -=09 - grub_file_close (font->file); - grub_free (font); -=09 - break; - } -} - -/* Return the offset of the glyph corresponding to the codepoint CODE - in the font FONT. If no found, return zero. */ -static grub_uint32_t -find_glyph (const struct font *font, grub_uint32_t code) -{ - grub_uint32_t start =3D 0; - grub_uint32_t end =3D font->num - 1; - const struct entry *table =3D font->table; - =20 - /* This shouldn't happen. */ - if (font->num =3D=3D 0) - return 0; - - /* Do a binary search. */ - while (start <=3D end) - { - grub_uint32_t i =3D (start + end) / 2; - - if (table[i].code < code) - start =3D i + 1; - else if (table[i].code > code) - end =3D i - 1; - else - return table[i].offset; - } - - return 0; -} - -/* Set the glyph to something stupid. */ -static void -fill_with_default_glyph (grub_font_glyph_t glyph) -{ - unsigned i; - - /* Use pre-defined pattern to fill unknown glyphs. */ - for (i =3D 0; i < 16; i++) - glyph->bitmap[i] =3D unknown_glyph[i]; - - glyph->char_width =3D 1; - glyph->width =3D glyph->char_width * 8; - glyph->height =3D 16; - glyph->baseline =3D (16 * 3) / 4; -} - -/* Get a glyph corresponding to the codepoint CODE. Always fill glyph - information with something, even if no glyph is found. */ -int -grub_font_get_glyph (grub_uint32_t code, - grub_font_glyph_t glyph) -{ - struct font *font; - grub_uint8_t bitmap[32]; - - /* FIXME: It is necessary to cache glyphs! */ - =20 - restart: - for (font =3D font_list; font; font =3D font->next) - { - grub_uint32_t offset; - - offset =3D find_glyph (font, code); - if (offset) - { - grub_uint32_t w; - int len; - - /* Make sure we can find glyphs for error messages. Push active - error message to error stack and reset error message. */ - grub_error_push (); - =20 - grub_file_seek (font->file, offset); - if ((len =3D grub_file_read (font->file, (char *) &w, sizeof (w))) - !=3D sizeof (w)) - { - remove_font (font); - goto restart; - } - - w =3D grub_le_to_cpu32 (w); - if (w !=3D 1 && w !=3D 2) - { - /* grub_error (GRUB_ERR_BAD_FONT, "invalid width"); */ - remove_font (font); - goto restart; - } - - if (grub_file_read (font->file, (char *) bitmap, w * 16) - !=3D (grub_ssize_t) w * 16) - { - remove_font (font); - goto restart; - } - - /* Fill glyph with information. */ =20 - grub_memcpy (glyph->bitmap, bitmap, w * 16); - =20 - glyph->char_width =3D w; - glyph->width =3D glyph->char_width * 8; - glyph->height =3D 16; - glyph->baseline =3D (16 * 3) / 4; - =20 - /* Restore old error message. */ - grub_error_pop (); - =20 - return 1; - } - } - - /* Uggh... No font was found. */ - fill_with_default_glyph (glyph); - return 0; -} - -static grub_err_t -font_command (struct grub_arg_list *state __attribute__ ((unused)), - int argc __attribute__ ((unused)), - char **args __attribute__ ((unused))) -{ - if (argc =3D=3D 0) - return grub_error (GRUB_ERR_BAD_ARGUMENT, "no font specified"); - - while (argc--) - if (! add_font (*args++)) - return 1; - - return 0; -} - -GRUB_MOD_INIT(font_manager) -{ - grub_register_command ("font", font_command, GRUB_COMMAND_FLAG_BOTH, - "font FILE...", - "Specify one or more font files to display.", 0); -} - -GRUB_MOD_FINI(font_manager) -{ - grub_unregister_command ("font"); -} =3D=3D=3D modified file 'include/grub/font.h' --- include/grub/font.h 2007-07-21 22:32:33 +0000 +++ include/grub/font.h 2008-10-05 04:30:04 +0000 @@ -1,6 +1,6 @@ /* * GRUB -- GRand Unified Bootloader - * Copyright (C) 2003,2007 Free Software Foundation, Inc. + * Copyright (C) 2003,2007,2008 Free Software Foundation, Inc. * * GRUB is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -21,33 +21,85 @@ =20 #include =20 -#define GRUB_FONT_MAGIC "PPF\x7f" +/* Forward declaration of opaque structure grub_font. + * Users only pass struct grub_font pointers to the font module functions, + * and do not have knowledge of the structure contents. */ +struct grub_font; + +/* Font type used to access font functions. */ +typedef struct grub_font *grub_font_t; + =20 struct grub_font_glyph { - /* Glyph width in pixels. */ - grub_uint8_t width; - =20 - /* Glyph height in pixels. */ - grub_uint8_t height; - =20 - /* Glyph width in characters. */ - grub_uint8_t char_width; - =20 - /* Glyph baseline position in pixels (from up). */ - grub_uint8_t baseline; - =20 - /* Glyph bitmap data array of bytes in ((width + 7) / 8) * height. - Bitmap is formulated by height scanlines, each scanline having - width number of pixels. Pixels are coded as bits, value 1 meaning - of opaque pixel and 0 is transparent. If width does not fit byte - boundary, it will be padded with 0 to make it fit. */ - grub_uint8_t bitmap[32]; + /* Reference to the font this glyph belongs to. */ + grub_font_t font; + + /* Glyph bitmap width in pixels. */ + grub_uint16_t width; + + /* Glyph bitmap height in pixels. */ + grub_uint16_t height; + + /* Glyph bitmap x offset in pixels. Add to screen coordinate. */ + grub_int16_t offset_x; + + /* Glyph bitmap y offset in pixels. Subtract from screen coordinate. */ + grub_int16_t offset_y; + + /* Number of pixels to advance to start the next character. */ + grub_uint16_t device_width; + + /* Row-major order, packed bits (no padding; rows can break within a byt= e). + * The length of the array is (width * height + 7) / 8. Within a + * byte, the most significant bit is the first (leftmost/uppermost) pixe= l. + * Pixels are coded as bits, value 1 meaning of opaque pixel and 0 is + * transparent. If the length of the array does not fit byte boundary, it + * will be padded with 0 bits to make it fit. */ + grub_uint8_t bitmap[0]; }; =20 -typedef struct grub_font_glyph *grub_font_glyph_t; - -int grub_font_get_glyph (grub_uint32_t code, - grub_font_glyph_t glyph); + +/****** font/font.c ******/ + +/* Get the font that has the specified name. Font names are in the form + * "Family Name Bold Italic 14", where Bold and Italic are optional. + * If no font matches the name specified, the most recently loaded font + * is returned as a fallback. */ +grub_font_t grub_font_get (const char *font_name); + +const char *grub_font_get_name (grub_font_t font); + +int grub_font_get_max_char_width (grub_font_t font); + +int grub_font_get_max_char_height (grub_font_t font); + +int grub_font_get_ascent (grub_font_t font); + +int grub_font_get_descent (grub_font_t font); + +int grub_font_get_string_width (grub_font_t font, const char *str); + + +/****** font/loader.c ******/ + +/* + * Load a font and add it to the beginning of the global font list. + * Returns: 0 upon success; nonzero upon failure. + */ +int grub_font_load (const char *filename); + +/* Get the glyph for FONT corresponding to the Unicode code point CODE. + * Returns a pointer to an glyph indicating there is no glyph available + * if CODE does not exist in the font. The glyphs are cached once loaded.= */ +struct grub_font_glyph *grub_font_get_glyph (grub_font_t font, + grub_uint32_t code); + +/* Get a glyph corresponding to the codepoint CODE. If no glyph is availa= ble + * for CODE in the available fonts, then a glyph representing an unknown + * character is returned. This function never returns NULL. + * The returned glyph is owned by the font manager and should not be freed + * by the caller. The glyphs are cached. */ +struct grub_font_glyph *grub_font_get_glyph_any (grub_uint32_t code); =20 #endif /* ! GRUB_FONT_HEADER */ =3D=3D=3D added file 'include/grub/font_internal.h' --- include/grub/font_internal.h 1970-01-01 00:00:00 +0000 +++ include/grub/font_internal.h 2008-10-05 04:30:04 +0000 @@ -0,0 +1,71 @@ +/* font_internal.h - Font declarations for use internally by the font modu= le. + * Users of the font module should not include this header. */ +/* + * GRUB -- GRand Unified Bootloader + * Copyright (C) 2003,2005,2006,2007,2008 Free Software Foundation, Inc. + * + * GRUB is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * GRUB is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with GRUB. If not, see . + */ + +#ifndef GRUB_FONT_INTERNAL_HEADER +#define GRUB_FONT_INTERNAL_HEADER 1 + +#include +#include +#include +#include +#include +#include +#include + +#define FONT_DEBUG 0 + +struct char_index_entry +{ + grub_uint32_t code; + grub_uint8_t storage_flags; + grub_uint32_t offset; + struct grub_font_glyph *glyph; /* Glyph if loaded, or null. */ +}; + +struct grub_font +{ + char *name; + grub_file_t file; + short max_char_width; + short max_char_height; + short ascent; + short descent; + grub_uint32_t num_chars; + struct char_index_entry *char_index; +}; + +struct font_node +{ + struct font_node *next; + struct grub_font *value; +}; + +extern struct font_node *grub_font_list; + + +/****** loader.c ******/ + +/* Initialize the font loader module. */ +void +grub_font_loader_init (void); + + +#endif /* ! GRUB_FONT_INTERNAL_HEADER */ + =3D=3D=3D modified file 'include/grub/video.h' --- include/grub/video.h 2008-10-05 04:28:39 +0000 +++ include/grub/video.h 2008-10-05 04:30:04 +0000 @@ -21,6 +21,7 @@ =20 #include #include +#include =20 /* Video color in hardware dependent format. Users should not assume any specific coding format. */ @@ -31,17 +32,17 @@ struct grub_video_render_target; =20 /* Forward declarations for used data structures. */ -struct grub_font_glyph; struct grub_video_bitmap; =20 /* Defines used to describe video mode or rendering target. */ -#define GRUB_VIDEO_MODE_TYPE_ALPHA 0x00000008 -#define GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED 0x00000004 +#define GRUB_VIDEO_MODE_TYPE_ALPHA 0x00000020 +#define GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED 0x00000010 +#define GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP 0x00000004 #define GRUB_VIDEO_MODE_TYPE_INDEX_COLOR 0x00000002 #define GRUB_VIDEO_MODE_TYPE_RGB 0x00000001 =20 /* Defines used to mask flags. */ -#define GRUB_VIDEO_MODE_TYPE_COLOR_MASK 0x00000003 +#define GRUB_VIDEO_MODE_TYPE_COLOR_MASK 0x0000000F =20 /* Defines used to specify requested bit depth. */ #define GRUB_VIDEO_MODE_TYPE_DEPTH_MASK 0x0000ff00 @@ -72,7 +73,9 @@ GRUB_VIDEO_BLIT_FORMAT_BGR_565, =20 /* When needed, decode color or just use value as is. */ - GRUB_VIDEO_BLIT_FORMAT_INDEXCOLOR + GRUB_VIDEO_BLIT_FORMAT_INDEXCOLOR, + /* Two color bitmap; bits packed: rows are not padded to byte boundary= . */ + GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED }; =20 /* Define blitting operators. */ @@ -135,6 +138,18 @@ /* What is location of reserved color bits. In Index Color mode, this is 0. */ unsigned int reserved_field_pos; + + /* For 1-bit bitmaps, the background color. Used for bits =3D 0. */ + grub_uint8_t bg_red; + grub_uint8_t bg_green; + grub_uint8_t bg_blue; + grub_uint8_t bg_alpha; + + /* For 1-bit bitmaps, the foreground color. Used for bits =3D 1. */ + grub_uint8_t fg_red; + grub_uint8_t fg_green; + grub_uint8_t fg_blue; + grub_uint8_t fg_alpha; }; =20 struct grub_video_palette_data @@ -189,7 +204,12 @@ unsigned int width, unsigned int height); =20 grub_err_t (*blit_glyph) (struct grub_font_glyph *glyph, - grub_video_color_t color, int x, int y); + grub_video_color_t color,=20 + int left_x, int baseline_y); + + grub_err_t (*draw_string) (const char *str, grub_font_t font,=20 + grub_video_color_t color,=20 + int left_x, int baseline_y); =20 grub_err_t (*blit_bitmap) (struct grub_video_bitmap *bitmap, enum grub_video_blit_operators oper, @@ -261,7 +281,12 @@ unsigned int width, unsigned int height); =20 grub_err_t grub_video_blit_glyph (struct grub_font_glyph *glyph, - grub_video_color_t color, int x, int y); + grub_video_color_t color,=20 + int left_x, int baseline_y); + +grub_err_t grub_video_draw_string (const char *str, grub_font_t font,=20 + grub_video_color_t color,=20 + int left_x, int baseline_y); =20 grub_err_t grub_video_blit_bitmap (struct grub_video_bitmap *bitmap, enum grub_video_blit_operators oper, =3D=3D=3D modified file 'term/gfxterm.c' --- term/gfxterm.c 2008-08-31 03:08:13 +0000 +++ term/gfxterm.c 2008-10-05 04:30:04 +0000 @@ -35,9 +35,6 @@ #define DEFAULT_VIDEO_HEIGHT 480 #define DEFAULT_VIDEO_FLAGS 0 =20 -#define DEFAULT_CHAR_WIDTH 8 -#define DEFAULT_CHAR_HEIGHT 16 - #define DEFAULT_BORDER_WIDTH 10 =20 #define DEFAULT_STANDARD_COLOR 0x07 @@ -91,6 +88,9 @@ unsigned int cursor_y; int cursor_state; =20 + /* Font settings. */ + grub_font_t font; + /* Terminal color settings. */ grub_uint8_t standard_color_setting; grub_uint8_t normal_color_setting; @@ -169,18 +169,25 @@ =20 static grub_err_t grub_virtual_screen_setup (unsigned int x, unsigned int y, - unsigned int width, unsigned int height) + unsigned int width, unsigned int height, + const char *font_name) { /* Free old virtual screen. */ grub_virtual_screen_free (); =20 /* Initialize with default data. */ + virtual_screen.font =3D grub_font_get (font_name); + if (!virtual_screen.font) + return grub_error (GRUB_ERR_BAD_FONT, + "No font loaded."); virtual_screen.width =3D width; virtual_screen.height =3D height; virtual_screen.offset_x =3D x; virtual_screen.offset_y =3D y; - virtual_screen.char_width =3D DEFAULT_CHAR_WIDTH; - virtual_screen.char_height =3D DEFAULT_CHAR_HEIGHT; + virtual_screen.char_width =3D=20 + grub_font_get_max_char_width (virtual_screen.font); + virtual_screen.char_height =3D=20 + grub_font_get_max_char_height (virtual_screen.font); virtual_screen.cursor_x =3D 0; virtual_screen.cursor_y =3D 0; virtual_screen.cursor_state =3D 1; @@ -226,6 +233,7 @@ static grub_err_t grub_gfxterm_init (void) { + char *font_name; char *modevar; int width =3D DEFAULT_VIDEO_WIDTH; int height =3D DEFAULT_VIDEO_HEIGHT; @@ -233,6 +241,11 @@ int flags =3D DEFAULT_VIDEO_FLAGS; grub_video_color_t color; =20 + /* Select the font to use. */ + font_name =3D grub_env_get ("gfxterm_font"); + if (!font_name) + font_name =3D ""; /* Allow fallback to any font. */ + /* Parse gfxmode environment variable if set. */ modevar =3D grub_env_get ("gfxmode"); if (modevar) @@ -472,7 +485,7 @@ =20 /* Create virtual screen. */ if (grub_virtual_screen_setup (DEFAULT_BORDER_WIDTH, DEFAULT_BORDER_WIDT= H, - width, height) !=3D GRUB_ERR_NONE) + width, height, font_name) !=3D GRUB_ERR_N= ONE) { grub_video_restore (); return grub_errno; @@ -658,11 +671,12 @@ write_char (void) { struct grub_colored_char *p; - struct grub_font_glyph glyph; + struct grub_font_glyph *glyph; grub_video_color_t color; grub_video_color_t bgcolor; unsigned int x; unsigned int y; + int ascent; =20 /* Find out active character. */ p =3D (virtual_screen.text_buffer @@ -672,7 +686,8 @@ p -=3D p->index; =20 /* Get glyph for character. */ - grub_font_get_glyph (p->code, &glyph); + glyph =3D grub_font_get_glyph (virtual_screen.font, p->code); + ascent =3D grub_font_get_ascent (virtual_screen.font); =20 color =3D p->fg_color; bgcolor =3D p->bg_color; @@ -682,13 +697,13 @@ =20 /* Render glyph to text layer. */ grub_video_set_active_render_target (text_layer); - grub_video_fill_rect (bgcolor, x, y, glyph.width, glyph.height); - grub_video_blit_glyph (&glyph, color, x, y); + grub_video_fill_rect (bgcolor, x, y, glyph->width, glyph->height); + grub_video_blit_glyph (glyph, color, x, y + ascent); grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); =20 /* Mark character to be drawn. */ dirty_region_add (virtual_screen.offset_x + x, virtual_screen.offset_y += y, - glyph.width, glyph.height); + glyph->width, glyph->height); } =20 static void @@ -702,7 +717,8 @@ =20 /* Determine cursor properties and position on text layer. */ x =3D virtual_screen.cursor_x * virtual_screen.char_width; - y =3D ((virtual_screen.cursor_y + 1) * virtual_screen.char_height) - 3; = =20 + y =3D (virtual_screen.cursor_y * virtual_screen.char_height =20 + + grub_font_get_ascent (virtual_screen.font)); width =3D virtual_screen.char_width; height =3D 2; =20 @@ -819,14 +835,18 @@ } else { - struct grub_font_glyph glyph; + struct grub_font_glyph *glyph; struct grub_colored_char *p; + unsigned char_width; =20 /* Get properties of the character. */ =20 - grub_font_get_glyph (c, &glyph); + glyph =3D grub_font_get_glyph (virtual_screen.font, c); + + /* TODO Fix wide characters. Bi-width font support? */ + char_width =3D 1; =20 /* If we are about to exceed line length, wrap to next line. */ - if (virtual_screen.cursor_x + glyph.char_width > virtual_screen.colu= mns) + if (virtual_screen.cursor_x + char_width > virtual_screen.columns) grub_putchar ('\n'); =20 /* Find position on virtual screen, and fill information. */ @@ -836,18 +856,18 @@ p->code =3D c; p->fg_color =3D virtual_screen.fg_color; p->bg_color =3D virtual_screen.bg_color; - p->width =3D glyph.char_width - 1; + p->width =3D char_width - 1; p->index =3D 0; =20 /* If we have large glyph, add fixup info. */ - if (glyph.char_width > 1) + if (char_width > 1) { unsigned i; =20 - for (i =3D 1; i < glyph.char_width; i++) + for (i =3D 1; i < char_width; i++) { p[i].code =3D ' '; - p[i].width =3D glyph.char_width - 1; + p[i].width =3D char_width - 1; p[i].index =3D i; } } @@ -856,7 +876,7 @@ write_char (); =20 /* Make sure we scroll screen when needed and wrap line correctly. = */ - virtual_screen.cursor_x +=3D glyph.char_width; + virtual_screen.cursor_x +=3D char_width; if (virtual_screen.cursor_x >=3D virtual_screen.columns) { virtual_screen.cursor_x =3D 0; @@ -876,11 +896,16 @@ static grub_ssize_t grub_gfxterm_getcharwidth (grub_uint32_t c) { - struct grub_font_glyph glyph; - - grub_font_get_glyph (c, &glyph); - - return glyph.char_width; +#if 0 + struct grub_font_glyph *glyph; + + glyph =3D grub_font_get_glyph (c); + + return glyph->char_width; +#else + (void) c; /* Prevent warning. */ + return 1; /* TODO Fix wide characters. */ +#endif } =20 static grub_uint16_t =3D=3D=3D modified file 'term/i386/pc/vesafb.c' --- term/i386/pc/vesafb.c 2007-12-30 08:52:06 +0000 +++ term/i386/pc/vesafb.c 2008-10-05 04:30:04 +0000 @@ -250,10 +250,11 @@ break; =20 default: - return grub_font_get_glyph (code, bitmap, width); + return grub_font_get_glyph_any (code, bitmap, width); } } =20 + /* TODO This is wrong for the new font module. Should it be fixed? */ if (bitmap) grub_memcpy (bitmap, vga_font + code * virtual_screen.char_height, =3D=3D=3D modified file 'term/i386/pc/vga.c' --- term/i386/pc/vga.c 2008-01-21 15:48:27 +0000 +++ term/i386/pc/vga.c 2008-10-05 04:30:04 +0000 @@ -65,6 +65,7 @@ static struct colored_char text_buf[TEXT_WIDTH * TEXT_HEIGHT]; static unsigned char saved_map_mask; static int page =3D 0; +static grub_font_t font =3D 0; =20 #define SEQUENCER_ADDR_PORT 0x3C4 #define SEQUENCER_DATA_PORT 0x3C5 @@ -161,6 +162,9 @@ saved_map_mask =3D get_map_mask (); set_map_mask (0x0f); set_start_address (PAGE_OFFSET (page)); + font =3D grub_font_get (""); /* Choose any font, for now. */ + if (!font) + return grub_error (GRUB_ERR_BAD_FONT, "No font loaded."); =20 return GRUB_ERR_NONE; } @@ -185,7 +189,7 @@ write_char (void) { struct colored_char *p =3D text_buf + xpos + ypos * TEXT_WIDTH; - struct grub_font_glyph glyph; + struct grub_font_glyph *glyph; unsigned char *mem_base; unsigned plane; =20 @@ -194,7 +198,7 @@ p -=3D p->index; =20 /* Get glyph for character. */ - grub_font_get_glyph (p->code, &glyph); + glyph =3D grub_font_get_glyph (font, p->code); =20 for (plane =3D 0x01; plane <=3D 0x08; plane <<=3D 1) { @@ -208,19 +212,23 @@ y < CHAR_HEIGHT; y++, mem +=3D TEXT_WIDTH) { + /* TODO Re-implement glyph drawing for vga module. */ +#if 0 unsigned i; =20 - for (i =3D 0; i < glyph.char_width && offset < 32; i++) + unsigned char_width =3D 1; /* TODO Figure out wide characters. = */ + for (i =3D 0; i < char_width && offset < 32; i++) { unsigned char fg_mask, bg_mask; =20 - fg_mask =3D (p->fg_color & plane) ? glyph.bitmap[offset] : 0; - bg_mask =3D (p->bg_color & plane) ? ~(glyph.bitmap[offset]) : 0; + fg_mask =3D (p->fg_color & plane) ? glyph->bitmap[offset] : 0; + bg_mask =3D (p->bg_color & plane) ? ~(glyph->bitmap[offset]) : 0; offset++; =20 if (check_vga_mem (mem + i)) mem[i] =3D (fg_mask | bg_mask); } +#endif /* 0 */=20 } } =20 @@ -320,36 +328,37 @@ } else { - struct grub_font_glyph glyph; + struct grub_font_glyph *glyph; struct colored_char *p; + unsigned char_width =3D 1; =20 - grub_font_get_glyph(c, &glyph); + glyph =3D grub_font_get_glyph(font, c); =20 - if (xpos + glyph.char_width > TEXT_WIDTH) + if (xpos + char_width > TEXT_WIDTH) grub_putchar ('\n'); =20 p =3D text_buf + xpos + ypos * TEXT_WIDTH; p->code =3D c; p->fg_color =3D fg_color; p->bg_color =3D bg_color; - p->width =3D glyph.char_width - 1; + p->width =3D char_width - 1; p->index =3D 0; =20 - if (glyph.char_width > 1) + if (char_width > 1) { unsigned i; =20 - for (i =3D 1; i < glyph.char_width; i++) + for (i =3D 1; i < char_width; i++) { p[i].code =3D ' '; - p[i].width =3D glyph.char_width - 1; + p[i].width =3D char_width - 1; p[i].index =3D i; } } =20 write_char (); =20 - xpos +=3D glyph.char_width; + xpos +=3D char_width; if (xpos >=3D TEXT_WIDTH) { xpos =3D 0; @@ -381,11 +390,16 @@ static grub_ssize_t grub_vga_getcharwidth (grub_uint32_t c) { +#if 0 struct grub_font_glyph glyph; =20 - grub_font_get_glyph (c, &glyph); + glyph =3D grub_font_get_glyph (c); =20 return glyph.char_width; +#else + (void) c; /* Prevent warning. */ + return 1; /* TODO Fix wide characters? */ +#endif } =20 static grub_uint16_t =3D=3D=3D modified file 'video/i386/pc/vbe.c' --- video/i386/pc/vbe.c 2008-10-03 15:25:34 +0000 +++ video/i386/pc/vbe.c 2008-10-05 04:30:04 +0000 @@ -896,6 +896,16 @@ =20 return minindex; } + else if ((render_target->mode_info.mode_type=20 + & GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP) !=3D 0) + { + if (red =3D=3D render_target->mode_info.fg_red + && green =3D=3D render_target->mode_info.fg_green + && blue =3D=3D render_target->mode_info.fg_blue) + return 1; + else + return 0; + } else { grub_uint32_t value; @@ -926,6 +936,17 @@ /* No alpha available in index color modes, just use same value as in only RGB modes. */ return grub_video_vbe_map_rgb (red, green, blue); + else if ((render_target->mode_info.mode_type=20 + & GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP) !=3D 0) + { + if (red =3D=3D render_target->mode_info.fg_red + && green =3D=3D render_target->mode_info.fg_green + && blue =3D=3D render_target->mode_info.fg_blue + && alpha =3D=3D render_target->mode_info.fg_alpha) + return 1; + else + return 0; + } else { grub_uint32_t value; @@ -988,6 +1009,24 @@ *alpha =3D framebuffer.palette[color].a; return; } + else if ((mode_info->mode_type + & GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP) !=3D 0) + { + if (color & 1) + { + *red =3D mode_info->fg_red; + *green =3D mode_info->fg_green; + *blue =3D mode_info->fg_blue; + *alpha =3D mode_info->fg_alpha; + } + else + { + *red =3D mode_info->bg_red; + *green =3D mode_info->bg_green; + *blue =3D mode_info->bg_blue; + *alpha =3D mode_info->bg_alpha; + } + } else { grub_uint32_t tmp; @@ -1111,76 +1150,6 @@ return GRUB_ERR_NONE; } =20 -// TODO: Remove this method and replace with bitmap based glyphs -static grub_err_t -grub_video_vbe_blit_glyph (struct grub_font_glyph * glyph, - grub_video_color_t color, int x, int y) -{ - struct grub_video_i386_vbeblit_info target; - unsigned int width; - unsigned int charwidth; - unsigned int height; - unsigned int i; - unsigned int j; - unsigned int x_offset =3D 0; - unsigned int y_offset =3D 0; - - /* Make sure there is something to do. */ - if (x >=3D (int)render_target->viewport.width) - return GRUB_ERR_NONE; - - if (y >=3D (int)render_target->viewport.height) - return GRUB_ERR_NONE; - - /* Calculate glyph dimensions. */ - width =3D ((glyph->width + 7) / 8) * 8; - charwidth =3D width; - height =3D glyph->height; - - if (x + (int)width < 0) - return GRUB_ERR_NONE; - - if (y + (int)height < 0) - return GRUB_ERR_NONE; - - /* Do not allow drawing out of viewport. */ - if (x < 0) - { - width +=3D x; - x_offset =3D (unsigned int)-x; - x =3D 0; - } - if (y < 0) - { - height +=3D y; - y_offset =3D (unsigned int)-y; - y =3D 0; - } - - if ((x + width) > render_target->viewport.width) - width =3D render_target->viewport.width - x; - if ((y + height) > render_target->viewport.height) - height =3D render_target->viewport.height - y; - - /* Add viewport offset. */ - x +=3D render_target->viewport.x; - y +=3D render_target->viewport.y; - - /* Use vbeblit_info to encapsulate rendering. */ - target.mode_info =3D &render_target->mode_info; - target.data =3D render_target->data; - - /* Draw glyph. */ - for (j =3D 0; j < height; j++) - for (i =3D 0; i < width; i++) - if ((glyph->bitmap[((i + x_offset) / 8) - + (j + y_offset) * (charwidth / 8)] - & (1 << ((charwidth - (i + x_offset) - 1) % 8)))) - set_pixel (&target, x+i, y+j, color); - - return GRUB_ERR_NONE; -} - /* NOTE: This function assumes that given coordinates are within bounds of handled data. */ static void @@ -1474,6 +1443,77 @@ return GRUB_ERR_NONE; } =20 +/*=20 + * Draw the specified glyph at (x, y). The y coordinate designates the + * baseline of the character, while the x coordinate designates the left + * side location of the character.=20 + */ +static grub_err_t +grub_video_vbe_blit_glyph (struct grub_font_glyph *glyph, + grub_video_color_t color,=20 + int left_x, int baseline_y) +{ + struct grub_video_bitmap glyph_bitmap; + + /* Don't try to draw empty glyphs (U+0020, etc.). */ + if (glyph->width =3D=3D 0 || glyph->height =3D=3D 0) + return GRUB_ERR_NONE; + + glyph_bitmap.mode_info.width =3D glyph->width; + glyph_bitmap.mode_info.height =3D glyph->height; + glyph_bitmap.mode_info.mode_type =3D=20 + (1 << GRUB_VIDEO_MODE_TYPE_DEPTH_POS) + | GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP; + glyph_bitmap.mode_info.blit_format =3D GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKE= D; + glyph_bitmap.mode_info.bpp =3D 1; + glyph_bitmap.mode_info.bytes_per_pixel =3D 0; /* Really 1 bit per pixel= . */ + glyph_bitmap.mode_info.pitch =3D glyph->width; /* Packed densely as bits= . */ + glyph_bitmap.mode_info.number_of_colors =3D 2; + glyph_bitmap.mode_info.bg_red =3D 0; + glyph_bitmap.mode_info.bg_green =3D 0; + glyph_bitmap.mode_info.bg_blue =3D 0; + glyph_bitmap.mode_info.bg_alpha =3D 0; + grub_video_vbe_unmap_color(color,=20 + &glyph_bitmap.mode_info.fg_red, + &glyph_bitmap.mode_info.fg_green, + &glyph_bitmap.mode_info.fg_blue, + &glyph_bitmap.mode_info.fg_alpha); + glyph_bitmap.data =3D glyph->bitmap; + + int bitmap_left =3D left_x + glyph->offset_x; + int bitmap_bottom =3D baseline_y - glyph->offset_y; + int bitmap_top =3D bitmap_bottom - glyph->height; + + return grub_video_vbe_blit_bitmap (&glyph_bitmap, GRUB_VIDEO_BLIT_BLEND, + bitmap_left, bitmap_top, + 0, 0, + glyph->width, glyph->height); +} + +static grub_err_t +grub_video_vbe_draw_string (const char *str, grub_font_t font,=20 + grub_video_color_t color,=20 + int left_x, int baseline_y) +{ + grub_size_t len; + grub_size_t i; + int x; + struct grub_font_glyph *glyph; + + len =3D grub_strlen (str); + x =3D left_x; + for (i =3D 0; i < len; i++) + { + glyph =3D grub_font_get_glyph (font, str[i]); + if (grub_video_vbe_blit_glyph (glyph, color, x, baseline_y)=20 + !=3D GRUB_ERR_NONE) + return grub_errno; + x +=3D glyph->device_width; + } + + return GRUB_ERR_NONE; +} + static grub_err_t grub_video_vbe_blit_render_target (struct grub_video_render_target *source, enum grub_video_blit_operators oper, @@ -1805,6 +1845,7 @@ .unmap_color =3D grub_video_vbe_unmap_color, .fill_rect =3D grub_video_vbe_fill_rect, .blit_glyph =3D grub_video_vbe_blit_glyph, + .draw_string =3D grub_video_vbe_draw_string, .blit_bitmap =3D grub_video_vbe_blit_bitmap, .blit_render_target =3D grub_video_vbe_blit_render_target, .scroll =3D grub_video_vbe_scroll, =3D=3D=3D modified file 'video/i386/pc/vbeutil.c' --- video/i386/pc/vbeutil.c 2007-07-21 22:32:33 +0000 +++ video/i386/pc/vbeutil.c 2008-10-05 04:30:04 +0000 @@ -52,6 +52,11 @@ + y * source->mode_info->pitch + x; break; + + /* case 1: */ + /* For 1-bit bitmaps, addressing needs to be done at the bit level + * and it doesn't make sense, in general, to ask for a pointer + * to a particular pixel's data. */ } =20 return ptr; @@ -86,6 +91,17 @@ color =3D *(grub_uint8_t *)get_data_ptr (source, x, y); break; =20 + case 1: + if (source->mode_info->blit_format =3D=3D GRUB_VIDEO_BLIT_FORMAT_1BI= T_PACKED) + { + int bit_index =3D y * source->mode_info->width + x; + grub_uint8_t *ptr =3D (grub_uint8_t *)source->data + + bit_index / 8; + int bit_pos =3D 7 - bit_index % 8; + color =3D (*ptr >> bit_pos) & 0x01; + } + break; + default: break; } @@ -143,6 +159,17 @@ } break; =20 + case 1: + if (source->mode_info->blit_format =3D=3D GRUB_VIDEO_BLIT_FORMAT_1BI= T_PACKED) + { + int bit_index =3D y * source->mode_info->width + x; + grub_uint8_t *ptr =3D (grub_uint8_t *)source->data + + bit_index / 8; + int bit_pos =3D 7 - bit_index % 8; + *ptr =3D (*ptr & ~(1 << bit_pos)) | ((color & 0x01) << bit_pos); + } + break; + default: break; } =3D=3D=3D modified file 'video/video.c' --- video/video.c 2008-10-03 15:25:34 +0000 +++ video/video.c 2008-10-05 04:30:04 +0000 @@ -339,12 +339,27 @@ /* Blit glyph to screen using specified color. */ grub_err_t grub_video_blit_glyph (struct grub_font_glyph *glyph, - grub_video_color_t color, int x, int y) -{ - if (! grub_video_adapter_active) - return grub_error (GRUB_ERR_BAD_DEVICE, "No video mode activated"); - - return grub_video_adapter_active->blit_glyph (glyph, color, x, y); + grub_video_color_t color,=20 + int left_x, int baseline_y) +{ + if (! grub_video_adapter_active) + return grub_error (GRUB_ERR_BAD_DEVICE, "No video mode activated"); + + return grub_video_adapter_active->blit_glyph (glyph, color, + left_x, baseline_y); +} + +/* Draw string to screen using specified color and font. */ +grub_err_t +grub_video_draw_string (const char *str, grub_font_t font,=20 + grub_video_color_t color,=20 + int left_x, int baseline_y) +{ + if (! grub_video_adapter_active) + return grub_error (GRUB_ERR_BAD_DEVICE, "No video mode activated"); + + return grub_video_adapter_active->draw_string (str, font, color,=20 + left_x, baseline_y); } =20 /* Blit bitmap to screen. */ --MP_/yGNypotXh4x=ITpmchIzMwg-- --Sig_/xR5Sh3OVu2Z6XagzDVqwjrN Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjoRrMACgkQokx8fzcGbYf9iQCfazP5CSTABphFOQWlUfvxLc75 lc8An2tL+xTo9S45U4y90nlWPfo+ySU4 =g4d9 -----END PGP SIGNATURE----- --Sig_/xR5Sh3OVu2Z6XagzDVqwjrN-- From MAILER-DAEMON Sun Oct 05 04:49:59 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmPJO-0002H7-U2 for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 04:49:58 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmPJM-0002GR-K0 for grub-devel@gnu.org; Sun, 05 Oct 2008 04:49:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmPJL-0002G6-Os for grub-devel@gnu.org; Sun, 05 Oct 2008 04:49:56 -0400 Received: from [199.232.76.173] (port=53740 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmPJL-0002G3-KZ for grub-devel@gnu.org; Sun, 05 Oct 2008 04:49:55 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:34169 helo=kirsi2.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmPJK-0006zL-VM for grub-devel@gnu.org; Sun, 05 Oct 2008 04:49:55 -0400 Received: from [127.0.0.1] (84.248.105.254) by kirsi2.inet.fi (8.5.014) id 48DA300B0091009F for grub-devel@gnu.org; Sun, 5 Oct 2008 11:49:49 +0300 Message-ID: <48E87FB9.8070603@nic.fi> Date: Sun, 05 Oct 2008 11:50:01 +0300 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <20080901092753.3918cf73@gamma.lan> <20081004214640.5ab21f53@gibibit.com> In-Reply-To: <20081004214640.5ab21f53@gibibit.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #10 new font engine (vs r1885) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 08:49:56 -0000 Colin D Bennett wrote: > Clean patch against SVN revision 1885. >=20 > Regards, > Colin Thanks for the re-base. Here are some comments about the patch. Check the commenting of multi line comments. > +int > +grub_font_get_string_width (grub_font_t font, const char *str) > +{ > + int i; > + int width; > + struct grub_font_glyph *glyph; > + grub_size_t len; > + > + len =3D grub_strlen (str); > + > + for (i =3D 0, width =3D 0; i < len; i++) > + { > + glyph =3D grub_font_get_glyph (font, str[i]); > + width +=3D glyph->device_width; > + } > + > + return width; > +} I do not see this being utf-8 compatible eg. it breaks our Unicode displaying support. See how grub_putchar() handles this. There is also the same problem in grub_video_vbe_draw_string(). > =3D=3D=3D modified file 'conf/sparc64-ieee1275.rmk' > --- conf/sparc64-ieee1275.rmk 2008-09-08 12:52:30 +0000 > +++ conf/sparc64-ieee1275.rmk 2008-10-05 04:30:04 +0000 As font code is common code. There is no need to modify sparc64 specific makefile. You have correctly modified common.rmk so that is enough. If sparc64 support should be moved to use common.rmk like any other arch. Let it rot. > =3D=3D=3D added file 'font/loader.c' > --- font/loader.c 1970-01-01 00:00:00 +0000 > +++ font/loader.c 2008-10-05 04:30:04 +0000 > +/* > + Read a 16-bit big-endian integer from FILE, convert it to native by= te > + order, and store it in *VALUE. > + Returns 0 on success, 1 on failure. > + */ > +static int > +read_be_uint16 (grub_file_t file, grub_uint16_t * value) Are you fan of bigendian or why did you choose that :) ? > +struct grub_font_glyph * > +grub_font_get_glyph (grub_font_t font, grub_uint32_t code) I would propose to but all public API's to one file. > =3D=3D=3D modified file 'include/grub/video.h' > --- include/grub/video.h 2008-10-05 04:28:39 +0000 > +++ include/grub/video.h 2008-10-05 04:30:04 +0000 Now that you have moved glyph rendering out from specialized glyph rendering to bitmap rendering I would propose that no font rendering code resides in Video API. I think this is a good move. I would move that to font.mod (or perhaps to graphical terminal?). We can adapt other graphical terminals to use video API to render stuff. It just takes a bit time. But I think this time is as good as any to start that process. Lets have another look at it after those modifications :) Thanks, Vesa J=E4=E4skel=E4inen From MAILER-DAEMON Sun Oct 05 04:52:02 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmPLO-0003Ai-Hb for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 04:52:02 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmPLM-00038u-5C for grub-devel@gnu.org; Sun, 05 Oct 2008 04:52:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmPLK-00037d-BZ for grub-devel@gnu.org; Sun, 05 Oct 2008 04:51:59 -0400 Received: from [199.232.76.173] (port=54641 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmPLK-00037M-76 for grub-devel@gnu.org; Sun, 05 Oct 2008 04:51:58 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:55449 helo=jenni1.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmPLJ-0007vg-D9 for grub-devel@gnu.org; Sun, 05 Oct 2008 04:51:57 -0400 Received: from [127.0.0.1] (84.248.105.254) by jenni1.inet.fi (8.5.014) id 48DA2BD7009198D4 for grub-devel@gnu.org; Sun, 5 Oct 2008 11:51:56 +0300 Message-ID: <48E88038.6090201@nic.fi> Date: Sun, 05 Oct 2008 11:52:08 +0300 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <20080830235833.3b29b3c2@gamma.lan> <20081004214328.57e8f709@gibibit.com> In-Reply-To: <20081004214328.57e8f709@gibibit.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #07 VBE double buffering (vs r1885) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 08:52:00 -0000 Colin D Bennett wrote: > Clean patch against trunk SVN revision 1885. >=20 > Regards, > Colin Thanks for the re-base. In your opinion how should rendering of double buffered screen be different from single buffered? Eg. who is responsible to handle those differences? Thanks, Vesa J=E4=E4skel=E4inen From MAILER-DAEMON Sun Oct 05 06:07:27 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmQWN-0007QP-Hx for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 06:07:27 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmQWL-0007Ps-Pn for grub-devel@gnu.org; Sun, 05 Oct 2008 06:07:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmQWI-0007Oi-IG for grub-devel@gnu.org; Sun, 05 Oct 2008 06:07:25 -0400 Received: from [199.232.76.173] (port=58369 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmQWI-0007Oa-Cy for grub-devel@gnu.org; Sun, 05 Oct 2008 06:07:22 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:59641 helo=kirsi2.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmQWH-0004Vz-Qx for grub-devel@gnu.org; Sun, 05 Oct 2008 06:07:22 -0400 Received: from [127.0.0.1] (84.248.105.254) by kirsi2.inet.fi (8.5.014) id 48DA300B0091E68C for grub-devel@gnu.org; Sun, 5 Oct 2008 13:07:20 +0300 Message-ID: <48E891E4.1000507@nic.fi> Date: Sun, 05 Oct 2008 13:07:32 +0300 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <20080830235254.7cc5ad80@gamma.lan> In-Reply-To: <20080830235254.7cc5ad80@gamma.lan> X-Enigmail-Version: 0.95.7 Content-Type: multipart/mixed; boundary="------------000008020205020506020800" X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #05 Menu entry class attribute X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 10:07:26 -0000 This is a multi-part message in MIME format. --------------000008020205020506020800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Colin D Bennett wrote: > This patch adds support for a 'class' attribute on menu entries. It is > somewhat of a kludge, however since currently you just append > "|class=this,that" to the menu entry title to specify the classes. > > Classes are used to provide a simple and flexible way for the best > available icon to be used in a graphical menu, but there are other > possible uses for them as well. The idea originates from the CSS > (cascading style sheets) and HTML 'class' concept. Here is the patch snipped for using menuentry --class foo "title" { }. Please try it out and see if it fits. --------------000008020205020506020800 Content-Type: text/plain; name="grub2-menuarguments.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="grub2-menuarguments.patch" Index: normal/parser.y =================================================================== --- normal/parser.y (revision 1885) +++ normal/parser.y (working copy) @@ -204,7 +204,7 @@ ; /* A menu entry. Carefully save the memory that is allocated. */ -menuentry: "menuentry" argument +menuentry: "menuentry" arguments { grub_script_lexer_ref (state->lexerstate); } newlines '{' Index: normal/main.c =================================================================== --- normal/main.c (revision 1885) +++ normal/main.c (working copy) @@ -148,13 +148,15 @@ } grub_err_t -grub_normal_menu_addentry (const char *title, struct grub_script *script, +grub_normal_menu_addentry (int argc, char **args, struct grub_script *script, const char *sourcecode) { - const char *menutitle; + const char *menutitle = 0; const char *menusourcecode; grub_menu_t menu; grub_menu_entry_t *last; + int failed = 0; + int i; menu = grub_env_get_data_slot("menu"); if (! menu) @@ -166,10 +168,59 @@ if (! menusourcecode) return grub_errno; - menutitle = grub_strdup (title); - if (! menutitle) + /* Parse menu arguments. */ + for (i = 0; i < argc; i++) { - grub_free ((void *) menusourcecode); + /* Capture arguments. */ + if (grub_strncmp ("--", args[i], 2) == 0) + { + char *arg = &args[i][2]; + char *value = 0; + + /* Handle menu class. */ + if (grub_strcmp(arg, "class") == 0) + { + i++; + value = args[i]; + continue; + } + else + { + /* Handle invalid argument. */ + failed = 1; + grub_error (GRUB_ERR_MENU, "invalid argument for menuentry: %s", args[i]); + break; + } + + } + + /* Capture title. */ + if (! menutitle) + { + menutitle = grub_strdup (args[i]); + } + else + { + failed = 1; + grub_error (GRUB_ERR_MENU, "too many titles for menuentry: %s", args[i]); + break; + } + } + + /* Validate arguments. */ + if ((! failed) && (! menutitle)) + { + grub_error (GRUB_ERR_MENU, "menuentry is missing title"); + failed = 1; + } + + /* If argument parsing failed, free any allocated resources. */ + if (failed) + { + grub_free ((void *)menutitle); + grub_free ((void *)menusourcecode); + + /* Here we assume that grub_error has been used to specify failure details. */ return grub_errno; } Index: normal/script.c =================================================================== --- normal/script.c (revision 1885) +++ normal/script.c (working copy) @@ -206,7 +206,7 @@ The options for this entry are passed in OPTIONS. */ struct grub_script_cmd * grub_script_create_cmdmenu (struct grub_parser_param *state, - struct grub_script_arg *title, + struct grub_script_arglist *arglist, char *sourcecode, int options) { @@ -232,9 +232,9 @@ cmd->cmd.next = 0; /* XXX: Check if this memory is properly freed. */ cmd->sourcecode = sourcecode; - cmd->title = title; + cmd->arglist = arglist; cmd->options = options; - + return (struct grub_script_cmd *) cmd; } Index: normal/execute.c =================================================================== --- normal/execute.c (revision 1885) +++ normal/execute.c (working copy) @@ -216,16 +216,33 @@ grub_script_execute_menuentry (struct grub_script_cmd *cmd) { struct grub_script_cmd_menuentry *cmd_menuentry; - char *title; + struct grub_script_arglist *arglist; struct grub_script *script; + char **args = 0; + int argcount = 0; + int i = 0; cmd_menuentry = (struct grub_script_cmd_menuentry *) cmd; - /* The title can contain variables, parse them and generate a string - from it. */ - title = grub_script_execute_argument_to_string (cmd_menuentry->title); - if (! title) - return grub_errno; + if (cmd_menuentry->arglist) + { + argcount = cmd_menuentry->arglist->argcount; + + /* Create argv from the arguments. */ + args = grub_malloc (sizeof (char *) * argcount); + + if (! args) + { + return grub_errno; + } + + for (arglist = cmd_menuentry->arglist; arglist; arglist = arglist->next) + { + char *str; + str = grub_script_execute_argument_to_string (arglist->arg); + args[i++] = str; + } + } /* Parse the menu entry *again*. */ script = grub_script_parse ((char *) cmd_menuentry->sourcecode, 0); @@ -230,15 +247,19 @@ /* Parse the menu entry *again*. */ script = grub_script_parse ((char *) cmd_menuentry->sourcecode, 0); - if (! script) + /* Add new menu entry. */ + if (script) { - grub_free (title); - return grub_errno; + grub_normal_menu_addentry (argcount, args, + script, cmd_menuentry->sourcecode); } - /* XXX: When this fails, the memory should be freed? */ - return grub_normal_menu_addentry (title, script, - cmd_menuentry->sourcecode); + /* Free arguments. */ + for (i = 0; i < argcount; i++) + grub_free (args[i]); + grub_free (args); + + return grub_errno; } Index: include/grub/script.h =================================================================== --- include/grub/script.h (revision 1885) +++ include/grub/script.h (working copy) @@ -113,8 +113,8 @@ { struct grub_script_cmd cmd; - /* The title of the menu entry. */ - struct grub_script_arg *title; + /* The arguments for this menu entry. */ + struct grub_script_arglist *arglist; /* The sourcecode the entry will be generated from. */ const char *sourcecode; @@ -204,7 +204,7 @@ struct grub_script_cmd * grub_script_create_cmdmenu (struct grub_parser_param *state, - struct grub_script_arg *title, + struct grub_script_arglist *arglist, char *sourcecode, int options); Index: include/grub/normal.h =================================================================== --- include/grub/normal.h (revision 1885) +++ include/grub/normal.h (working copy) @@ -152,7 +152,7 @@ char *grub_normal_do_completion (char *buf, int *restore, void (*hook) (const char *item, grub_completion_type_t type, int count)); grub_err_t grub_normal_print_device_info (const char *name); -grub_err_t grub_normal_menu_addentry (const char *title, +grub_err_t grub_normal_menu_addentry (int argc, char **args, struct grub_script *script, const char *sourcecode); char *grub_env_write_color_normal (struct grub_env_var *var, const char *val); --------------000008020205020506020800-- From MAILER-DAEMON Sun Oct 05 06:52:25 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmRDt-0003wT-Hb for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 06:52:25 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmRDr-0003w2-Ea for grub-devel@gnu.org; Sun, 05 Oct 2008 06:52:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmRDp-0003vC-Ep for grub-devel@gnu.org; Sun, 05 Oct 2008 06:52:22 -0400 Received: from [199.232.76.173] (port=44564 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmRDp-0003v5-8b for grub-devel@gnu.org; Sun, 05 Oct 2008 06:52:21 -0400 Received: from aybabtu.com ([69.60.117.155]:52923) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KmRDp-0005vq-4h for grub-devel@gnu.org; Sun, 05 Oct 2008 06:52:21 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KmR07-00045X-Ea for grub-devel@gnu.org; Sun, 05 Oct 2008 12:38:11 +0200 Received: from rmh by thorin with local (Exim 4.63) (envelope-from ) id 1KmRBn-0003mR-W0 for grub-devel@gnu.org; Sun, 05 Oct 2008 12:50:16 +0200 Date: Sun, 5 Oct 2008 12:50:15 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20081005105015.GA5541@thorin> References: <20080828111405.GD8224@gagh.ehv.newtec.eu> <1219922711.4598.49.camel@fz.local> <20080829090019.GA6721@gagh.ehv.newtec.eu> <87wshzhkh7.fsf@xs4all.nl> <1220476513.21922.7.camel@fz.local> <20080909130351.GB6969@gagh.ehv.newtec.eu> <20080923082929.GA7205@gagh.ehv.newtec.eu> <1222160281.4118.1.camel@fz.local> <20080924094517.GA6973@thorin> <20080930123436.GA8865@gagh.ehv.newtec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080930123436.GA8865@gagh.ehv.newtec.eu> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.13 (2006-08-11) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: grub 1.96 svn 20080813 and circular lvm2 metadata X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 10:52:23 -0000 On Tue, Sep 30, 2008 at 02:34:36PM +0200, Hans Lambermont wrote: > Robert Millan wrote on 20080924: > > > On Tue, Sep 23, 2008 at 10:58:01AM +0200, Felix Zielcke wrote: > >> Am Dienstag, den 23.09.2008, 10:29 +0200 schrieb Hans Lambermont: > >>> The new patch was sent to the list 2 weeks ago. > >>> (See http://lists.gnu.org/archive/html/grub-devel/2008-09/msg00210.html ) > >>> Is there anything else that is needed ? > >> For me personally it looks fine, but it would be good if Marco has a > >> look over it and unfornatunately he doestn't have much free time now. > > So let's put him in CC. > > My email address I put in the changelog proposal will stop working soon, so > here's a new one that'll last longer : > > This is intended for the Changelog : > > 2008-09-09 Hans Lambermont > > * disk/lvm.c (grub_lvm_scan_device): Allocate buffer space for the > circular metadata worst case scenario. If the metadata is circular > then copy the wrap in place. > * include/grub/lvm.h: Add GRUB_LVM_MDA_HEADER_SIZE, from the LVM2 > project lib/format_text/layout.h > Circular metadata bug found and patch debugged by > Jan Derk Gerlings > > The address of Jan Derk will stop working too, I'll send an new one as > soon as I have it. Hi, I checked this in, but ommitted Jan's address, since it will stop working as you said. Thanks! -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." From MAILER-DAEMON Sun Oct 05 06:58:26 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmRJi-0006vq-3U for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 06:58:26 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmRJg-0006uM-M2 for grub-devel@gnu.org; Sun, 05 Oct 2008 06:58:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmRJd-0006sO-2Q for grub-devel@gnu.org; Sun, 05 Oct 2008 06:58:21 -0400 Received: from [199.232.76.173] (port=56912 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmRJc-0006sE-Jr for grub-devel@gnu.org; Sun, 05 Oct 2008 06:58:20 -0400 Received: from aybabtu.com ([69.60.117.155]:51265) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KmRJc-0008Nk-A8 for grub-devel@gnu.org; Sun, 05 Oct 2008 06:58:20 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KmR65-000469-9u for grub-devel@gnu.org; Sun, 05 Oct 2008 12:44:22 +0200 Received: from rmh by thorin with local (Exim 4.63) (envelope-from ) id 1KmRHi-0003pE-Aa for grub-devel@gnu.org; Sun, 05 Oct 2008 12:56:22 +0200 Date: Sun, 5 Oct 2008 12:56:22 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20081005105622.GB5541@thorin> References: <20080928200814.GA20816@thorin> <460f92b70809290131g5f1ffb7rc1bb32589ea971a8@mail.gmail.com> <20080929150739.GC12979@thorin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.13 (2006-08-11) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: strange iso9660 bug X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 10:58:25 -0000 On Tue, Sep 30, 2008 at 01:15:21AM +0800, Bean wrote: > > Hi, > > Rockridge is supported in iso9660. However, the image file has three > namespaces, iso9660, joliet and rockridge. Currently, the priority is: > > joliet > rockridge > iso9660 > > So only files in joliet is showed. > > It's possible to change priority, but what if we need to access files > in the other namespace ? Perhaps we can control it with variables, for > example: disable_joliet, disable_rockridge, etc. Sounds fine to me. But I'd also change the default priorities so that they match with those in isoinfo, linux, grub legacy, etc. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." From MAILER-DAEMON Sun Oct 05 07:07:52 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmRSq-0006Ka-LP for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 07:07:52 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmRSp-0006Jz-6o for grub-devel@gnu.org; Sun, 05 Oct 2008 07:07:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmRSn-0006JK-KJ for grub-devel@gnu.org; Sun, 05 Oct 2008 07:07:50 -0400 Received: from [199.232.76.173] (port=58081 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmRSn-0006JF-Gt for grub-devel@gnu.org; Sun, 05 Oct 2008 07:07:49 -0400 Received: from aybabtu.com ([69.60.117.155]:46378) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KmRSn-0003ez-EC for grub-devel@gnu.org; Sun, 05 Oct 2008 07:07:49 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KmRFH-00046Y-1N for grub-devel@gnu.org; Sun, 05 Oct 2008 12:53:51 +0200 Received: from rmh by thorin with local (Exim 4.63) (envelope-from ) id 1KmRQy-0003tn-Df for grub-devel@gnu.org; Sun, 05 Oct 2008 13:05:56 +0200 Date: Sun, 5 Oct 2008 13:05:56 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20081005110556.GC5541@thorin> References: <20080928215812.GC5259@pina.cat> <48E11DF2.3050804@nic.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <48E11DF2.3050804@nic.fi> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.13 (2006-08-11) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [RFC] Different keyborad layouts X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 11:07:51 -0000 On Mon, Sep 29, 2008 at 09:26:58PM +0300, Vesa Jääskeläinen wrote: > > Remember that in some keyboard you need to press combos in order to > generate some character. Like in Finnish keyboard you press alt-gr + e > in order to generate euro sign (or alt-gr + 5). Also there are > multi-keypress sequences like in order to make '^' this sign you have to > press ctrl + '^' button and when released then press space. If you > happen to press in example 'a' after ctrl + '^' key you get 'â'. And I > do not think this is the only keyboard with this feature. Also there is > those dec input sequences like alt+number sequence. In example alt > (pressed) + '6', '5' you get 'A'. Do we really want to support all keys (and therefore all minor keyboard variants) out there, or just those needed for metacharacters like '/' and such? > I do not like the idea of using variable for this as it will most likely > require loading of keymap definition form disk. So I would prefer something: > > insmod keymap > keymap /boot/grub/keyboard/fi Seems fine to me. Note, however, that with the information currently exported by e.g. at_keyboard.c it isn't possible to tell when special combinations like "alt-gr + 5" were pressed. There's quite a bit of pending rework for the input/output split (handlers?) and USB keyboards (multiple input sources). Perhaps it'd be better to address this when the fundamentals have been laid out? Btw, what happened to the handlers patch? I thought it was about to be merged. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." From MAILER-DAEMON Sun Oct 05 07:09:58 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmRUs-0007Di-2S for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 07:09:58 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmRUp-0007Cb-0l for grub-devel@gnu.org; Sun, 05 Oct 2008 07:09:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmRUo-0007C9-AN for grub-devel@gnu.org; Sun, 05 Oct 2008 07:09:54 -0400 Received: from [199.232.76.173] (port=58175 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmRUo-0007C4-2x for grub-devel@gnu.org; Sun, 05 Oct 2008 07:09:54 -0400 Received: from aybabtu.com ([69.60.117.155]:46379) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KmRUo-0004dt-2i for grub-devel@gnu.org; Sun, 05 Oct 2008 07:09:54 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KmRHH-00046f-Lp for grub-devel@gnu.org; Sun, 05 Oct 2008 12:55:56 +0200 Received: from rmh by thorin with local (Exim 4.63) (envelope-from ) id 1KmRSr-0003uz-9B for grub-devel@gnu.org; Sun, 05 Oct 2008 13:07:53 +0200 Date: Sun, 5 Oct 2008 13:07:53 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20081005110753.GD5541@thorin> References: <200809232051.22749.bakshi12@gmail.com> <48D916F7.10001@nic.fi> <48E12720.3030806@nic.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <48E12720.3030806@nic.fi> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.13 (2006-08-11) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: grub2 summer code theme in debian? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 11:09:55 -0000 On Mon, Sep 29, 2008 at 10:06:08PM +0300, Vesa Jääskeläinen wrote: > > Our second GSoC project for USB needs a bit more testing and perhaps > some cleanups (Marco & Robert any comments?). Marco seems to be busy atm; anyway, the biggest blocker I see right now is that the proposal for handlers (which implicitly includes terminal input & output split) is stuck. Ah and I don't have much time lately either :-( -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." From MAILER-DAEMON Sun Oct 05 07:40:23 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmRyI-0004I9-SP for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 07:40:22 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmRyH-0004HK-2d for grub-devel@gnu.org; Sun, 05 Oct 2008 07:40:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmRyF-0004GV-Dl for grub-devel@gnu.org; Sun, 05 Oct 2008 07:40:20 -0400 Received: from [199.232.76.173] (port=46293 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmRyF-0004GP-7Y for grub-devel@gnu.org; Sun, 05 Oct 2008 07:40:19 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:45795 helo=jenni2.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmRyF-00027U-3T for grub-devel@gnu.org; Sun, 05 Oct 2008 07:40:19 -0400 Received: from [127.0.0.1] (84.248.105.254) by jenni2.inet.fi (8.5.014) id 48DA2F0A0092D579 for grub-devel@gnu.org; Sun, 5 Oct 2008 14:40:17 +0300 Message-ID: <48E8A7AD.6070302@nic.fi> Date: Sun, 05 Oct 2008 14:40:29 +0300 From: =?UTF-8?B?VmVzYSBKw6TDpHNrZWzDpGluZW4=?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <20080928215812.GC5259@pina.cat> <48E11DF2.3050804@nic.fi> <20081005110556.GC5541@thorin> In-Reply-To: <20081005110556.GC5541@thorin> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [RFC] Different keyborad layouts X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 11:40:21 -0000 Robert Millan wrote: > Btw, what happened to the handlers patch? I thought it was about to be merged. Handlers has nothing to do with this :) That is still pending before we get more discussion about that :) Anyway... what you are after is multiple terminal inputs and outputs support. From MAILER-DAEMON Sun Oct 05 07:46:39 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmS4N-0006Xp-M4 for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 07:46:39 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmS4L-0006XH-9a for grub-devel@gnu.org; Sun, 05 Oct 2008 07:46:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmS4K-0006WU-Gv for grub-devel@gnu.org; Sun, 05 Oct 2008 07:46:36 -0400 Received: from [199.232.76.173] (port=36197 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmS4K-0006WO-Bp for grub-devel@gnu.org; Sun, 05 Oct 2008 07:46:36 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:39540 helo=kirsi1.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmS4K-0004yW-3b for grub-devel@gnu.org; Sun, 05 Oct 2008 07:46:36 -0400 Received: from [127.0.0.1] (84.248.105.254) by kirsi1.inet.fi (8.5.014) id 48DA2F890092B9B0 for grub-devel@gnu.org; Sun, 5 Oct 2008 14:46:35 +0300 Message-ID: <48E8A927.1000000@nic.fi> Date: Sun, 05 Oct 2008 14:46:47 +0300 From: =?UTF-8?B?VmVzYSBKw6TDpHNrZWzDpGluZW4=?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <20080928215812.GC5259@pina.cat> <48E11DF2.3050804@nic.fi> <20081005110556.GC5541@thorin> In-Reply-To: <20081005110556.GC5541@thorin> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: Quoted-Printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [RFC] Different keyborad layouts X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 11:46:37 -0000 Robert Millan wrote: > On Mon, Sep 29, 2008 at 09:26:58PM +0300, Vesa J=C3=A4=C3=A4skel=C3=A4i= nen wrote: >> Remember that in some keyboard you need to press combos in order to >> generate some character. Like in Finnish keyboard you press alt-gr + e >> in order to generate euro sign (or alt-gr + 5). Also there are >> multi-keypress sequences like in order to make '^' this sign you have = to >> press ctrl + '^' button and when released then press space. If you >> happen to press in example 'a' after ctrl + '^' key you get '=C3=A2'. = And I >> do not think this is the only keyboard with this feature. Also there i= s >> those dec input sequences like alt+number sequence. In example alt >> (pressed) + '6', '5' you get 'A'. >=20 > Do we really want to support all keys (and therefore all minor keyboard > variants) out there, or just those needed for metacharacters like '/' a= nd > such? Probably not. But anyway... I would like simple combos to be handled nicely. Like shift+7 (forward slash). And then if you have some weird keyboard you should be able to generate unicode key based on some easy way and to handle capslock + shift to make lowercase and uppercase characters. >> I do not like the idea of using variable for this as it will most like= ly >> require loading of keymap definition form disk. So I would prefer some= thing: >> >> insmod keymap >> keymap /boot/grub/keyboard/fi >=20 > Seems fine to me. Note, however, that with the information currently e= xported > by e.g. at_keyboard.c it isn't possible to tell when special combinatio= ns like > "alt-gr + 5" were pressed. We need to uniform keyboard handling in way that USB and AT and bios keyboards get handled in same path. Now the next issue is if we have like two usb keyboards. How it should work in grub's case is that both is listened for input. From MAILER-DAEMON Sun Oct 05 12:17:32 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmWIW-0003Yg-B1 for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 12:17:32 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmWIU-0003Wf-2s for grub-devel@gnu.org; Sun, 05 Oct 2008 12:17:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmWIT-0003WM-BI for grub-devel@gnu.org; Sun, 05 Oct 2008 12:17:29 -0400 Received: from [199.232.76.173] (port=40552 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmWIT-0003WJ-7Y for grub-devel@gnu.org; Sun, 05 Oct 2008 12:17:29 -0400 Received: from gateway02.websitewelcome.com ([74.52.222.226]:43298) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KmWIT-0004a2-2I for grub-devel@gnu.org; Sun, 05 Oct 2008 12:17:29 -0400 Received: (qmail 11747 invoked from network); 5 Oct 2008 16:33:42 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway02.websitewelcome.com with SMTP; 5 Oct 2008 16:33:42 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:54969 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KmWIP-00049k-B3 for grub-devel@gnu.org; Sun, 05 Oct 2008 11:17:25 -0500 Date: Sun, 5 Oct 2008 09:16:59 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081005091659.78e70113@gibibit.com> In-Reply-To: <48E88038.6090201@nic.fi> References: <20080830235833.3b29b3c2@gamma.lan> <20081004214328.57e8f709@gibibit.com> <48E88038.6090201@nic.fi> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/Q.El0upi1lh16uOfEZn/Mvs"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #07 VBE double buffering (vs r1885) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 16:17:30 -0000 --Sig_/Q.El0upi1lh16uOfEZn/Mvs Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 05 Oct 2008 11:52:08 +0300 Vesa J____skel__inen wrote: > Colin D Bennett wrote: > > Clean patch against trunk SVN revision 1885. > >=20 > > Regards, > > Colin >=20 > Thanks for the re-base. >=20 > In your opinion how should rendering of double buffered screen be > different from single buffered? >=20 > Eg. who is responsible to handle those differences? >=20 > Thanks, > Vesa J__skel_inen Generally, the client code should (IMO) do the following, which will work for both a double-buffered and a non-double-buffered video mode: (by 'client', I mean the code that is using the video API) // Render the graphical elements to the back buffer. grub_video_fill_rect (...); grub_video_draw_string (...); grub_video_blit_bitmap (...); // Make the back buffer contents visible. grub_video_swap_buffers (); // NOP in single buffered mode For double buffered mode, this properly renders the graphics using double buffering. For non double buffered mode, the "back buffer" and the "front buffer" are one and the same, and the 'swap_buffers' operation does nothing. I think the main difference between rendering to a single buffered versus a double buffered screen is the fact that when rendering using single buffering, the client code can update only the changed parts of the screen, but for double buffering it must update the whole screen. In single buffered mode, you can incrementally modify the video memory contents based on the last rendered frame. However, in double buffered mode the last rendered frame might not be in the back buffer after calling swap_buffers, depending on the double buffering strategy selected at runtime: 1. when page flipping is in use, the back buffer will contain the contents of the screen before the *prior* call to swap_buffers. 2. when the back buffer is in main memory (the blit strategy), the back buffer will actually retain its contents after swap_buffers, since the buffers cannot actually be swapped (thus perhaps the 'swap_buffers' name is not the most accurate description of the essence of this function, but it gets the general message across). In the gfxmenu code, I decided that, at least to start with, to always render complete frames on the screen. In this way, the code functions properly whether or not double buffering is in use, and it is kept simple. This worked well for the menu screen, and has good performance in my tests even on my 1 GHz VIA C3 machine. I figure that it's more important to get it working properly, and then optimize the performance later where it might be needed. The main current performance problem lies in the way that the gfxterm works when embedded in the double buffered gfxmenu screen. It is causing a full screen redraw every time a character or a string is changed on the terminal. I've thought about this a lot in the past and I don't have a simple answer, though I have a lot of ideas (switch to single buffering temporarily (--), pre-render a bitmap of the rest of the screen (-), coalesce updates to the gfxterm (++), ...). Regards, Colin --Sig_/Q.El0upi1lh16uOfEZn/Mvs Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjo6H8ACgkQokx8fzcGbYcVhgCfXXQ+QW4wUdud5FAWTQsZtFy8 9BYAoJNpvhv5zaHk1W/DMmjdjmpOb6yO =VkUY -----END PGP SIGNATURE----- --Sig_/Q.El0upi1lh16uOfEZn/Mvs-- From MAILER-DAEMON Sun Oct 05 15:17:49 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmZ6z-0008K9-Iq for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 15:17:49 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmZ6x-0008I7-4v for grub-devel@gnu.org; Sun, 05 Oct 2008 15:17:47 -0400 Received: from [199.232.76.173] (port=44466 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmZ6v-0008Hb-Md for grub-devel@gnu.org; Sun, 05 Oct 2008 15:17:45 -0400 Received: from smtp.aircanopy.net ([66.160.208.25]:43492) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KmZ6v-0002kI-Cx for grub-devel@gnu.org; Sun, 05 Oct 2008 15:17:45 -0400 X-ASG-Debug-ID: 1223234262-2c0b00190000-Td4drV X-Barracuda-URL: http://66.160.208.25:8000/cgi-bin/mark.cgi Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net (Spam Firewall) with ESMTP id A01A88774BA for ; Sun, 5 Oct 2008 14:17:42 -0500 (CDT) Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net with ESMTP id 9VL1jbM87gXidNEf for ; Sun, 05 Oct 2008 14:17:42 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by aczmr1.aircanopy.net (Postfix) with ESMTP id 8C5301D9FA for ; Sun, 5 Oct 2008 14:17:42 -0500 (CDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -1.609 Received: from aczmr1.aircanopy.net ([127.0.0.1]) by localhost (aczmr1.aircanopy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQoiZ22mPvaT for ; Sun, 5 Oct 2008 14:17:42 -0500 (CDT) Received: from aczmb1.aircanopy.net (aczmb1.aircanopy.net [66.160.208.170]) by aczmr1.aircanopy.net (Postfix) with ESMTP id 3405E18258 for ; Sun, 5 Oct 2008 14:17:42 -0500 (CDT) Date: Sun, 5 Oct 2008 14:17:42 -0500 (CDT) From: Andy Goth To: The development of GRUB 2 Message-ID: <1454803125.39941223234262084.JavaMail.root@aczmb1> In-Reply-To: <1745824252.39921223234235570.JavaMail.root@aczmb1> X-ASG-Orig-Subj: Re: [PATCH] GSoC #07 VBE double buffering (vs r1885) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [66.160.219.98] X-Mailer: Zimbra 5.0.8_GA_2462.SLES10_64 (ZimbraWebClient - FF2.0 (Linux)/5.0.8_GA_2462.SLES10_64) X-Barracuda-Connect: aczmr1.aircanopy.net[66.160.208.172] X-Barracuda-Start-Time: 1223234262 X-Barracuda-Virus-Scanned: by Aircanopy Spam Firewall at aircanopy.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.7322 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Subject: Re: [PATCH] GSoC #07 VBE double buffering (vs r1885) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 19:17:47 -0000 "Colin D Bennett" wrote: > However, in double buffered mode the last rendered frame might > not be in the back buffer after calling swap_buffers, depending > on the double buffering strategy selected at runtime: > > 1. page flipping is in use > 2. back buffer is in main memory With a little bookkeeping you can avoid having to redraw the whole screen. Here are some strategies: (double buffering with page flipping and drawing to main memory) Draw to a buffer in main memory. Maintain a list of changed regions. This is your list of dirty rectangles. After completing a frame, blit the dirty rectangles to the page that's about to get flipped into view. Age all dirty rectangles by one frame, and remove all dirty rectangles that were previously aged. If the dirty rectangle list gets too long, just blit the whole screen. Clever algorithms can combine dirty rectangles to save memory. (double buffering with page flipping without drawing to main memory) Draw to the back buffer, and maintain a dirty rectangle list. Immediately after vertical retrace start, flip pages, and blit the dirty rectangles to the new back buffer from the (now being displayed) old back buffer. Empty the dirty rectangle list. (double buffering without page flipping) Draw to a buffer in main memory, and maintain a dirty rectangle list. During vertical retrace, blit the dirty rectangles to VRAM. Empty the dirty rectangle list. (single buffering with minimal shearing) Draw to VRAM. Wait for the start of vertical retrace before drawing. Hopefully all drawing can complete before the monitor gets repainted. (single buffering) Draw to VRAM. Disclaimer: I don't actually know what you're trying to do (plain text, drop shadows, animation, 3D graphics... no clue), so the stuff I suggest might be overkill. Nevertheless, I hope it is helpful. -- Andy Goth | http://andy.junkdrome.org/ unununium@{aircanopy.net,openverse.com} From MAILER-DAEMON Sun Oct 05 15:47:58 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmZaA-0004ab-85 for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 15:47:58 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmZa9-0004ZM-06 for grub-devel@gnu.org; Sun, 05 Oct 2008 15:47:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmZa8-0004YK-7K for grub-devel@gnu.org; Sun, 05 Oct 2008 15:47:56 -0400 Received: from [199.232.76.173] (port=58305 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmZa7-0004YC-Pq for grub-devel@gnu.org; Sun, 05 Oct 2008 15:47:55 -0400 Received: from gateway01.websitewelcome.com ([69.41.242.19]:34126) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KmZa7-0000Cm-6t for grub-devel@gnu.org; Sun, 05 Oct 2008 15:47:55 -0400 Received: (qmail 22151 invoked from network); 5 Oct 2008 20:05:16 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway01.websitewelcome.com with SMTP; 5 Oct 2008 20:05:16 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:52374 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KmZa1-0001FP-7a for grub-devel@gnu.org; Sun, 05 Oct 2008 14:47:49 -0500 Date: Sun, 5 Oct 2008 12:47:23 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081005124723.56912905@gibibit.com> In-Reply-To: <1454803125.39941223234262084.JavaMail.root@aczmb1> References: <1745824252.39921223234235570.JavaMail.root@aczmb1> <1454803125.39941223234262084.JavaMail.root@aczmb1> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/sVsrw+k=nZorAg+u1vdIrFl"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #07 VBE double buffering (vs r1885) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 19:47:57 -0000 --Sig_/sVsrw+k=nZorAg+u1vdIrFl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 5 Oct 2008 14:17:42 -0500 (CDT) Andy Goth wrote: > "Colin D Bennett" wrote: > > However, in double buffered mode the last rendered frame might=20 > > not be in the back buffer after calling swap_buffers, depending=20 > > on the double buffering strategy selected at runtime: > >=20 > > 1. page flipping is in use > > 2. back buffer is in main memory >=20 > With a little bookkeeping you can avoid having to redraw the whole > screen. Here are some strategies: >=20 > (double buffering with page flipping and drawing to main memory) >=20 > Draw to a buffer in main memory. Maintain a list of changed > regions. This is your list of dirty rectangles. After completing a > frame, blit the dirty rectangles to the page that's about to get > flipped into view. Age all dirty rectangles by one frame, and remove > all dirty rectangles that were previously aged. If the dirty > rectangle list gets too long, just blit the whole screen. Clever > algorithms can combine dirty rectangles to save memory. >=20 > (double buffering with page flipping without drawing to main memory) >=20 > Draw to the back buffer, and maintain a dirty rectangle list. > Immediately after vertical retrace start, flip pages, and blit the > dirty rectangles to the new back buffer from the (now being > displayed) old back buffer. Empty the dirty rectangle list. >=20 > (double buffering without page flipping) >=20 > Draw to a buffer in main memory, and maintain a dirty rectangle > list. During vertical retrace, blit the dirty rectangles to VRAM. > Empty the dirty rectangle list. >=20 > (single buffering with minimal shearing) >=20 > Draw to VRAM. Wait for the start of vertical retrace before > drawing. Hopefully all drawing can complete before the monitor gets > repainted. >=20 > (single buffering) >=20 > Draw to VRAM. >=20 > Disclaimer: I don't actually know what you're trying to do (plain > text, drop shadows, animation, 3D graphics... no clue), so the stuff > I suggest might be overkill. Nevertheless, I hope it is helpful. Thanks for the ideas. Also, I know it is possible to write code that is optimal for each case, my plan is to avoid complicated dirty-region repaint strategies at first. ("First make it work, then make it rock.") After everything is working, then we can profile and do performance optimization. After everything is functioning and performance bottlenecks are identified, then we can perhaps use some techniques like you suggest. Thanks, Colin --Sig_/sVsrw+k=nZorAg+u1vdIrFl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjpGdAACgkQokx8fzcGbYdmvACgldYKypvL4yTOY1yfoe+mPJwX bc0An3QWMtQ9wtRwq3KMZ+1c1kUnm4lm =Pxac -----END PGP SIGNATURE----- --Sig_/sVsrw+k=nZorAg+u1vdIrFl-- From MAILER-DAEMON Sun Oct 05 15:57:26 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmZjJ-0008NU-TI for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 15:57:25 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmZjH-0008NF-VR for grub-devel@gnu.org; Sun, 05 Oct 2008 15:57:24 -0400 Received: from [199.232.76.173] (port=32910 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmZjH-0008Mz-Hw for grub-devel@gnu.org; Sun, 05 Oct 2008 15:57:23 -0400 Received: from smtp.aircanopy.net ([66.160.208.25]:44525) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KmZjG-0004Jn-UC for grub-devel@gnu.org; Sun, 05 Oct 2008 15:57:23 -0400 X-ASG-Debug-ID: 1223236640-31b002870000-Td4drV X-Barracuda-URL: http://66.160.208.25:8000/cgi-bin/mark.cgi Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net (Spam Firewall) with ESMTP id 21F4E8775BC for ; Sun, 5 Oct 2008 14:57:21 -0500 (CDT) Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net with ESMTP id AdVs78E3nZFII18G for ; Sun, 05 Oct 2008 14:57:20 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by aczmr1.aircanopy.net (Postfix) with ESMTP id 8B1F51D9FA for ; Sun, 5 Oct 2008 14:57:20 -0500 (CDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.339 Received: from aczmr1.aircanopy.net ([127.0.0.1]) by localhost (aczmr1.aircanopy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QxC7ESuuVZT for ; Sun, 5 Oct 2008 14:57:20 -0500 (CDT) Received: from aczmb1.aircanopy.net (aczmb1.aircanopy.net [66.160.208.170]) by aczmr1.aircanopy.net (Postfix) with ESMTP id 1CD3318258 for ; Sun, 5 Oct 2008 14:57:20 -0500 (CDT) Date: Sun, 5 Oct 2008 14:57:20 -0500 (CDT) From: Andy Goth To: The development of GRUB 2 Message-ID: <777113540.40311223236640078.JavaMail.root@aczmb1> In-Reply-To: <20081005124723.56912905@gibibit.com> X-ASG-Orig-Subj: Re: [PATCH] GSoC #07 VBE double buffering (vs r1885) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [66.160.219.98] X-Mailer: Zimbra 5.0.8_GA_2462.SLES10_64 (ZimbraWebClient - FF2.0 (Linux)/5.0.8_GA_2462.SLES10_64) X-Barracuda-Connect: aczmr1.aircanopy.net[66.160.208.172] X-Barracuda-Start-Time: 1223236641 X-Barracuda-Virus-Scanned: by Aircanopy Spam Firewall at aircanopy.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.7323 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Subject: Re: [PATCH] GSoC #07 VBE double buffering (vs r1885) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 19:57:24 -0000 "Colin D Bennett" wrote: > First make it work, then make it rock. I certainly do appreciate that, but... > my plan is to avoid complicated dirty-region repaint strategies > at first. Requiring full-screen repaints is an architectural design that might need rework to undo later. Or might not, depending on how you implement it. The interim approach you choose now should be informed by foresight. Full-screen repaint approach that will require rework later: - One function draws everything in sequence. It gets called every frame. Full-screen repaint approach that will be easy to integrate into a partial update scheme: - A separate function exists for drawing each logical unit of the screen. - Every frame, one function calls all the separate functions in sequence. Or something like that. -- Andy Goth | http://andy.junkdrome.org/ unununium@{aircanopy.net,openverse.com} From MAILER-DAEMON Mon Oct 06 15:02:50 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmvM2-0003hk-5c for mharc-grub-devel@gnu.org; Mon, 06 Oct 2008 15:02:50 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmvM0-0003gK-H3 for grub-devel@gnu.org; Mon, 06 Oct 2008 15:02:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmvLz-0003g8-TQ for grub-devel@gnu.org; Mon, 06 Oct 2008 15:02:48 -0400 Received: from [199.232.76.173] (port=47479 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmvLz-0003g5-QC for grub-devel@gnu.org; Mon, 06 Oct 2008 15:02:47 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:55386 helo=jenni2.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmvLz-00047U-3j for grub-devel@gnu.org; Mon, 06 Oct 2008 15:02:47 -0400 Received: from [127.0.0.1] (84.248.105.254) by jenni2.inet.fi (8.5.014) id 48DA2F0A00A82D57 for grub-devel@gnu.org; Mon, 6 Oct 2008 22:02:46 +0300 Message-ID: <48EA60D6.7060708@nic.fi> Date: Mon, 06 Oct 2008 22:02:46 +0300 From: =?UTF-8?B?VmVzYSBKw6TDpHNrZWzDpGluZW4=?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <777113540.40311223236640078.JavaMail.root@aczmb1> In-Reply-To: <777113540.40311223236640078.JavaMail.root@aczmb1> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: Quoted-Printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #07 VBE double buffering (vs r1885) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2008 19:02:48 -0000 Andy Goth wrote: > "Colin D Bennett" wrote: >> First make it work, then make it rock. >=20 > I certainly do appreciate that, but... >=20 >> my plan is to avoid complicated dirty-region repaint strategies=20 >> at first. >=20 > Requiring full-screen repaints is an architectural design that might ne= ed rework to undo later. Or might not, depending on how you implement it= . The interim approach you choose now should be informed by foresight. >=20 > Full-screen repaint approach that will require rework later: >=20 > - One function draws everything in sequence. It gets called every fram= e. >=20 > Full-screen repaint approach that will be easy to integrate into a part= ial update scheme: >=20 > - A separate function exists for drawing each logical unit of the scree= n. > - Every frame, one function calls all the separate functions in sequenc= e. >=20 > Or something like that. Hi, I would like to thank Andy for his comments on the topic. I do share the same concern about designing double buffering to work properly without making hasty implementation first. We can use non-buffered solution as a first stage "hasty implementation" and design good enough solution to handle double buffering well. Dirty rectangles for every buffer (two in double buffer case) might be the best approach here. I think there is some kind of dirty rectangle implementation on gfxterm so that could be used as a base for this work. After that it could be improved to increase performance but the main point being that there has to be proper framework to make it work properl= y. Usually the slowest step is to transfer image data from main memory to video memory (and usually the slowest is to read from video memory to main memory and then save it back to video memory). If we can optimize memory copies between video and main memories we are on good track to solve speed problem. Thanks, Vesa J=C3=A4=C3=A4skel=C3=A4inen From MAILER-DAEMON Mon Oct 06 15:08:27 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmvRT-00078n-4G for mharc-grub-devel@gnu.org; Mon, 06 Oct 2008 15:08:27 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmvRR-00078W-DP for grub-devel@gnu.org; Mon, 06 Oct 2008 15:08:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmvRQ-000783-RR for grub-devel@gnu.org; Mon, 06 Oct 2008 15:08:25 -0400 Received: from [199.232.76.173] (port=43335 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmvRQ-00077t-Np for grub-devel@gnu.org; Mon, 06 Oct 2008 15:08:24 -0400 Received: from lax-green-bigip-5.dreamhost.com ([208.113.200.5]:39454 helo=blingymail-a1.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmvRQ-0005QS-Eh for grub-devel@gnu.org; Mon, 06 Oct 2008 15:08:24 -0400 Received: from jidanni1.jidanni.org (122-127-37-131.dynamic.hinet.net [122.127.37.131]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by blingymail-a1.g.dreamhost.com (Postfix) with ESMTP id 7E7F55CFA0 for ; Mon, 6 Oct 2008 12:08:21 -0700 (PDT) To: grub-devel@gnu.org From: jidanni@jidanni.org Date: Tue, 07 Oct 2008 03:08:16 +0800 Message-ID: <87zllho82n.fsf@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) Subject: say how to get out of grub-emu X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2008 19:08:25 -0000 On the grub-emu man page please mention the only way to get back out of grub-emu is to use its "reboot" command, adding that it will return you to the shell and not really reboot. By the way, is the bug address on the man pages updated to grub-devel@gnu.org? Not on Debian's grub2 stuff. From MAILER-DAEMON Mon Oct 06 15:10:32 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmvTU-00006c-CI for mharc-grub-devel@gnu.org; Mon, 06 Oct 2008 15:10:32 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmvTS-000050-O0 for grub-devel@gnu.org; Mon, 06 Oct 2008 15:10:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmvTQ-0008Vd-V8 for grub-devel@gnu.org; Mon, 06 Oct 2008 15:10:30 -0400 Received: from [199.232.76.173] (port=43391 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmvTQ-0008VT-OE for grub-devel@gnu.org; Mon, 06 Oct 2008 15:10:28 -0400 Received: from lax-green-bigip-5.dreamhost.com ([208.113.200.5]:58104 helo=blingymail-a3.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmvTQ-0005pC-DW for grub-devel@gnu.org; Mon, 06 Oct 2008 15:10:28 -0400 Received: from jidanni1.jidanni.org (122-127-37-131.dynamic.hinet.net [122.127.37.131]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by blingymail-a3.g.dreamhost.com (Postfix) with ESMTP id 2355114D73D for ; Mon, 6 Oct 2008 12:10:27 -0700 (PDT) To: grub-devel@gnu.org From: jidanni@jidanni.org Date: Tue, 07 Oct 2008 03:10:22 +0800 Message-ID: <87y711o7z5.fsf@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) Subject: too many commands, "help" output rolls of screen X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2008 19:10:31 -0000 The top two lines of grub> help output will roll off the standard sized console. Please remove some commands so there aren't so many that they roll off the screen. Actually just please use more columns on some of the help lines. (Yes, TAB reveals the missing commands.) P.S., What if I forget my password and I cannot login to my machine? The best I can do is grub> cat (hd0,1)/etc/passwd How can I edit it to zero out the :x: field? Could you supply ed(1) in the commands perhaps? [This message was sent to the wrong list due to the wrong address on man pages. Now reposting to grub-devel.] From MAILER-DAEMON Mon Oct 06 15:31:18 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kmvna-0008O8-BL for mharc-grub-devel@gnu.org; Mon, 06 Oct 2008 15:31:18 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmvnY-0008Ne-Px for grub-devel@gnu.org; Mon, 06 Oct 2008 15:31:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmvnX-0008N8-JY for grub-devel@gnu.org; Mon, 06 Oct 2008 15:31:16 -0400 Received: from [199.232.76.173] (port=33073 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmvnX-0008Mv-D5 for grub-devel@gnu.org; Mon, 06 Oct 2008 15:31:15 -0400 Received: from c60.cesmail.net ([216.154.195.49]:13586) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1KmvnX-0005Fj-4Y for grub-devel@gnu.org; Mon, 06 Oct 2008 15:31:15 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 06 Oct 2008 15:31:14 -0400 Received: from [192.168.0.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id 9C619618FDE for ; Mon, 6 Oct 2008 15:31:14 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: <87zllho82n.fsf@jidanni.org> References: <87zllho82n.fsf@jidanni.org> Content-Type: text/plain Date: Mon, 06 Oct 2008 15:31:12 -0400 Message-Id: <1223321472.24000.6.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: say how to get out of grub-emu X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2008 19:31:17 -0000 On Tue, 2008-10-07 at 03:08 +0800, jidanni@jidanni.org wrote: > On the grub-emu man page please mention the only way to get back out > of grub-emu is to use its "reboot" command, adding that it will return > you to the shell and not really reboot. It's not true. The "exit" command in the rescue mode would exit as well. I believe it's the case where the code should be fixed, not the documentation. We need to have the "exit" command in normal mode (it already exists in the rescue mode) in grub-emu and on architectures where it's possible to exit from the bootloader and return control back to the firmware. I also think that the "reboot" command in grub-emu should restart grub-emu. That would be a better emulation of the "reboot" command than exiting. -- Regards, Pavel Roskin From MAILER-DAEMON Mon Oct 06 18:01:06 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kmy8Y-0005uz-5Q for mharc-grub-devel@gnu.org; Mon, 06 Oct 2008 18:01:06 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kmy8W-0005ut-3L for grub-devel@gnu.org; Mon, 06 Oct 2008 18:01:04 -0400 Received: from [199.232.76.173] (port=43499 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kmy8U-0005ui-KU for grub-devel@gnu.org; Mon, 06 Oct 2008 18:01:02 -0400 Received: from smtp.aircanopy.net ([66.160.208.25]:60870) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kmy8U-0006S8-7X for grub-devel@gnu.org; Mon, 06 Oct 2008 18:01:02 -0400 X-ASG-Debug-ID: 1223330459-649000e50000-Td4drV X-Barracuda-URL: http://66.160.208.25:8000/cgi-bin/mark.cgi Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net (Spam Firewall) with ESMTP id 55154717B72 for ; Mon, 6 Oct 2008 17:00:59 -0500 (CDT) Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net with ESMTP id 2dR6OwEGFogn17i6 for ; Mon, 06 Oct 2008 17:00:59 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by aczmr1.aircanopy.net (Postfix) with ESMTP id 32A0A1DA5B for ; Mon, 6 Oct 2008 17:00:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -1.57 Received: from aczmr1.aircanopy.net ([127.0.0.1]) by localhost (aczmr1.aircanopy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBOBGJeranyi for ; Mon, 6 Oct 2008 17:00:58 -0500 (CDT) Received: from aczmb1.aircanopy.net (aczmb1.aircanopy.net [66.160.208.170]) by aczmr1.aircanopy.net (Postfix) with ESMTP id DD0BE1D24F for ; Mon, 6 Oct 2008 17:00:58 -0500 (CDT) Date: Mon, 6 Oct 2008 17:00:58 -0500 (CDT) From: Andy Goth To: The development of GRUB 2 Message-ID: <1920677820.63551223330458704.JavaMail.root@aczmb1> In-Reply-To: <87y711o7z5.fsf@jidanni.org> X-ASG-Orig-Subj: Re: too many commands, "help" output rolls of screen MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [68.208.133.49] X-Mailer: Zimbra 5.0.8_GA_2462.SLES10_64 (zclient/5.0.8_GA_2462.SLES10_64) X-Barracuda-Connect: aczmr1.aircanopy.net[66.160.208.172] X-Barracuda-Start-Time: 1223330459 X-Barracuda-Virus-Scanned: by Aircanopy Spam Firewall at aircanopy.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.7420 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Subject: Re: too many commands, "help" output rolls of screen X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2008 22:01:04 -0000 jidanni@jidanni.org wrote: > The top two lines of > grub> help > output will roll off the standard sized console. Please remove some > commands so there aren't so many that they roll off the screen. You should be able to remove testing commands (like "hello" and "play") from the build. At the moment I don't have the ability to research how. I recently found a related problem that I'll post more information on after doing some research. It's the opposite issue: scrolling doesn't always happen when I want it to. > P.S., What if I forget my password and I cannot login to my machine? Presuming Linux, you can add "init=/bin/sh" to the kernel command line. This will give you a shell without asking for a password. From this shell you can edit your password file. I sometimes use this trick to give myself an account. :^) Seriously, if you don't password-protect your GRUB or LILO prompt (or anything else that edits the kernel command line), your system is open to anyone who has access to the keyboard. Then again, unless you take extraordinary measures, your system is open to anyone with a screwdriver and physical access to the machine. Warning 1: If support for your keyboard isn't compiled into the kernel, you won't be able to type, since the init scripts (which would load modules and do other configuration) will be bypassed. I suggest using a PS/2 keyboard in this case. Warning 2: You won't have job control, so Ctrl-C and so on won't work. Issue a command that takes a long time to complete, and you will have to wait. Issue a command that never completes, and you will have to reboot. I suggest running screen so as to give yourself a workaround. Warning 3: The root filesystem might be mounted read-only. Test this by using touch to create a file, then use ls to see if the file was created. If not, type "mount" to get a listing of filesystems, then remount / with the device name taken from mount's output and the -oremount,rw option. Or add "rw" to the kernel command line, removing "ro" if it is present. Warning 4: Initrd scripts might change everything. > Could you supply ed(1) in the commands perhaps? I could be wrong, but I don't think grub was, is, or ever will be meant to modify filesystems. Oh wait, I think it can be configured to remember the selected menu item as a new default, but I don't know how that's implemented. -- Andy Goth | http://andy.junkdrome.org/ unununium@{aircanopy.net,openverse.com} From MAILER-DAEMON Tue Oct 07 13:36:51 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KnGUM-0006tO-SI for mharc-grub-devel@gnu.org; Tue, 07 Oct 2008 13:36:50 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnGUK-0006tF-Pg for grub-devel@gnu.org; Tue, 07 Oct 2008 13:36:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnGUJ-0006sn-6F for grub-devel@gnu.org; Tue, 07 Oct 2008 13:36:48 -0400 Received: from [199.232.76.173] (port=55047 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnGUJ-0006sk-16 for grub-devel@gnu.org; Tue, 07 Oct 2008 13:36:47 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]:59099) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnGUI-0004UV-2W for grub-devel@gnu.org; Tue, 07 Oct 2008 13:36:46 -0400 Received: from fz (e180004062.adsl.alicedsl.de [85.180.4.62]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1KnGU62Jdq-00059m; Tue, 07 Oct 2008 19:36:34 +0200 Message-ID: From: "Felix Zielcke" To: "The development of GRUB 2" References: <20080801144818.GA17609@thorin> <873aloixfu.fsf@xs4all.nl> <20080801153934.GA20000@thorin> Date: Tue, 7 Oct 2008 19:36:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-Provags-ID: V01U2FsdGVkX1/VPsAFREx//ptQT83GJ2e8RuzOK9VzLhPTe/S y2+G4R0sVbG1iZYrn5aZl02auLQ6U3rBsrmwhdonn6G8uc8Jt6 9xhFIqaCxacJkcy6KCCjqa6NzzCqeqk X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6? (barebone, rare!) Cc: "Yoshinori K. Okuji" Subject: Re: rename grub to grub-legacy ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2008 17:36:49 -0000 -------------------------------------------------- From: "Robert Millan" Sent: Friday, August 01, 2008 5:39 PM To: "The development of GRUB 2" Cc: "Yoshinori K. Okuji" Subject: Re: rename grub to grub-legacy ? > On Fri, Aug 01, 2008 at 05:09:41PM +0200, Marco Gerards wrote: >> Hi, >> >> Robert Millan writes: >> >> > What would you think of renaming grub to grub-legacy in SVN ? >> > >> > I think it'd help send a strong message that we consider this a legacy branch >> > and is not open for further development. >> >> This is fine for me. Can you do this assuming Okuji and other >> developers do not have strong objections? > > Adding Okuji to CC, just to make sure he reads it. Reviving this old topic. It would be nice if grub would be renamed to grub-legacy in SVN So we all wait now for Okuji or can this happen without him because there were no objections AFAICS. From MAILER-DAEMON Tue Oct 07 13:40:51 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KnGYF-0002a6-Ii for mharc-grub-devel@gnu.org; Tue, 07 Oct 2008 13:40:51 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnGYD-0002Ys-Qw for grub-devel@gnu.org; Tue, 07 Oct 2008 13:40:49 -0400 Received: from [199.232.76.173] (port=37290 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnGYD-0002Y7-AZ for grub-devel@gnu.org; Tue, 07 Oct 2008 13:40:49 -0400 Received: from smtp.aircanopy.net ([66.160.208.25]:35487) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KnGYC-0005b8-Sb for grub-devel@gnu.org; Tue, 07 Oct 2008 13:40:49 -0400 X-ASG-Debug-ID: 1223401247-13da00710000-Td4drV X-Barracuda-URL: http://66.160.208.25:8000/cgi-bin/mark.cgi Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net (Spam Firewall) with ESMTP id 656E287B746 for ; Tue, 7 Oct 2008 12:40:47 -0500 (CDT) Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net with ESMTP id 0O6B8NynBJmrBvlU for ; Tue, 07 Oct 2008 12:40:47 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by aczmr1.aircanopy.net (Postfix) with ESMTP id 550791DAAA for ; Tue, 7 Oct 2008 12:40:47 -0500 (CDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -3.784 Received: from aczmr1.aircanopy.net ([127.0.0.1]) by localhost (aczmr1.aircanopy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYWAJo2VhD-n for ; Tue, 7 Oct 2008 12:40:47 -0500 (CDT) Received: from aczmb1.aircanopy.net (aczmb1.aircanopy.net [66.160.208.170]) by aczmr1.aircanopy.net (Postfix) with ESMTP id 117861D24F for ; Tue, 7 Oct 2008 12:40:47 -0500 (CDT) Date: Tue, 7 Oct 2008 12:40:46 -0500 (CDT) From: Andy Goth To: grub-devel@gnu.org Message-ID: <1720038063.77061223401246968.JavaMail.root@aczmb1> X-ASG-Orig-Subj: No scrolling for long input lines MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [66.160.208.172] X-Mailer: Zimbra 5.0.8_GA_2462.SLES10_64 (zclient/5.0.8_GA_2462.SLES10_64) X-Barracuda-Connect: aczmr1.aircanopy.net[66.160.208.172] X-Barracuda-Start-Time: 1223401247 X-Barracuda-Virus-Scanned: by Aircanopy Spam Firewall at aircanopy.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.7492 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Subject: No scrolling for long input lines X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2008 17:40:50 -0000 (I said I would research this some more, but I haven't had a chance, and I won't get one for a couple days, so rather than wait, I am simply posting what I know.) In GRUB 1.96, typing an input line longer than the screen is wide does not cause the screen to scroll. Effectively this means once I get to the bottom of the screen, anything I type that's longer than 80 characters (less prompt) I have to type blind. Aside from not being able to see what I type, everything behaves normally. My GRUB configuration is plain vanilla. GRUB's on a FAT12 floppy read in using biosdisk, there's no grub.cfg file, and I directly type in insmod, ls, linux, initrd, boot, and all that jazz. I haven't made any modifications to the source, and I'm using the 1.96 release I found on alpha.gnu.org. I have the biosdisk and fat modules compiled into the GRUB image. -- Andy Goth | http://andy.junkdrome.org/ unununium@{aircanopy.net,openverse.com} From MAILER-DAEMON Tue Oct 07 13:48:24 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KnGfY-0005QA-Cl for mharc-grub-devel@gnu.org; Tue, 07 Oct 2008 13:48:24 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnGfX-0005Pf-7I for grub-devel@gnu.org; Tue, 07 Oct 2008 13:48:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnGfV-0005P1-AL for grub-devel@gnu.org; Tue, 07 Oct 2008 13:48:22 -0400 Received: from [199.232.76.173] (port=53250 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnGfV-0005Ox-4y for grub-devel@gnu.org; Tue, 07 Oct 2008 13:48:21 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]:56111) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnGfU-0007b8-41 for grub-devel@gnu.org; Tue, 07 Oct 2008 13:48:20 -0400 Received: from fz (e180004062.adsl.alicedsl.de [85.180.4.62]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis) id 0MKwpI-1KnGfS3spV-0007JK; Tue, 07 Oct 2008 19:48:19 +0200 Message-ID: <34BA0810962B4635BD34AFA08C8394E1@fz> From: "Felix Zielcke" To: "The development of GRUB 2" References: <1720038063.77061223401246968.JavaMail.root@aczmb1> Date: Tue, 7 Oct 2008 19:48:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-Provags-ID: V01U2FsdGVkX18CzS2g4qwTocvml47fhYNKFARMvQ2WFP3gAeI Pjo3wuhBy/5P7lH+XUlAFVYZwEf5GYav4V0YFvd625KkVNOAZz eYqZUTWRgxWECbHVEdU2/9RiXVlsdOf X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6? (barebone, rare!) Subject: Re: No scrolling for long input lines X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2008 17:48:23 -0000 -------------------------------------------------- From: "Andy Goth" Sent: Tuesday, October 07, 2008 7:40 PM To: Subject: No scrolling for long input lines > I haven't made any modifications to the source, and I'm using the 1.96 release I found on alpha.gnu.org. I have the biosdisk and > fat modules compiled into the GRUB image. Hi, it would be always better if you check with the current SVN version things that you want to report if they still apply. grub2 is actively developed and the 1.96 release is from February whereas last change on SVN is currently 2 days old. From MAILER-DAEMON Tue Oct 07 15:06:42 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KnHtK-0005Yu-JG for mharc-grub-devel@gnu.org; Tue, 07 Oct 2008 15:06:42 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnHtJ-0005YD-M8 for grub-devel@gnu.org; Tue, 07 Oct 2008 15:06:41 -0400 Received: from [199.232.76.173] (port=49121 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnHtJ-0005Xf-0R for grub-devel@gnu.org; Tue, 07 Oct 2008 15:06:41 -0400 Received: from smtp.aircanopy.net ([66.160.208.25]:39365) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KnHtI-0002zM-QF for grub-devel@gnu.org; Tue, 07 Oct 2008 15:06:40 -0400 X-ASG-Debug-ID: 1223406398-13de00f50000-Td4drV X-Barracuda-URL: http://66.160.208.25:8000/cgi-bin/mark.cgi Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net (Spam Firewall) with ESMTP id C90635F0FDD for ; Tue, 7 Oct 2008 14:06:38 -0500 (CDT) Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net with ESMTP id LuH3LRTZddnrTGi8 for ; Tue, 07 Oct 2008 14:06:38 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by aczmr1.aircanopy.net (Postfix) with ESMTP id C93AB1D6A0 for ; Tue, 7 Oct 2008 14:06:38 -0500 (CDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.406 Received: from aczmr1.aircanopy.net ([127.0.0.1]) by localhost (aczmr1.aircanopy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wV0gPJPy7y84 for ; Tue, 7 Oct 2008 14:06:34 -0500 (CDT) Received: from aczmb1.aircanopy.net (aczmb1.aircanopy.net [66.160.208.170]) by aczmr1.aircanopy.net (Postfix) with ESMTP id 529BE1D24F for ; Tue, 7 Oct 2008 14:06:34 -0500 (CDT) Date: Tue, 7 Oct 2008 14:06:34 -0500 (CDT) From: Andy Goth To: The development of GRUB 2 Message-ID: <776858368.79411223406394157.JavaMail.root@aczmb1> In-Reply-To: <34BA0810962B4635BD34AFA08C8394E1@fz> X-ASG-Orig-Subj: Re: No scrolling for long input lines MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [68.208.133.49] X-Mailer: Zimbra 5.0.8_GA_2462.SLES10_64 (zclient/5.0.8_GA_2462.SLES10_64) X-Barracuda-Connect: aczmr1.aircanopy.net[66.160.208.172] X-Barracuda-Start-Time: 1223406398 X-Barracuda-Virus-Scanned: by Aircanopy Spam Firewall at aircanopy.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.7498 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Subject: Re: No scrolling for long input lines X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2008 19:06:41 -0000 Felix Zielcke wrote: > it would be always better if you check with the current SVN version things > that you want to report if they still apply. ___________ I'll test the current SVN this Friday, or perhaps Thursday night at the earliest. Until then I'm on international business travel. -- Andy Goth | http://andy.junkdrome.org/ unununium@{aircanopy.net,openverse.com} From MAILER-DAEMON Tue Oct 07 15:24:55 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KnIAx-0004Ch-AY for mharc-grub-devel@gnu.org; Tue, 07 Oct 2008 15:24:55 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnIAv-0004C5-AV for grub-devel@gnu.org; Tue, 07 Oct 2008 15:24:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnIAt-0004BX-Eg for grub-devel@gnu.org; Tue, 07 Oct 2008 15:24:52 -0400 Received: from [199.232.76.173] (port=43469 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnIAt-0004BP-5G for grub-devel@gnu.org; Tue, 07 Oct 2008 15:24:51 -0400 Received: from ns39764.ovh.net ([91.121.25.85]:41292 helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnIAt-0007Og-1w for grub-devel@gnu.org; Tue, 07 Oct 2008 15:24:51 -0400 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id 24EC33DBE1; Tue, 7 Oct 2008 21:24:49 +0200 (CEST) From: "Yoshinori K. Okuji" Organization: enbug.org To: "Felix Zielcke" Date: Tue, 7 Oct 2008 21:24:47 +0200 User-Agent: KMail/1.9.9 References: <20080801144818.GA17609@thorin> <20080801153934.GA20000@thorin> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810072124.47987.okuji@enbug.org> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: The development of GRUB 2 Subject: Re: rename grub to grub-legacy ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2008 19:24:53 -0000 On Tuesday 07 October 2008 19:36:32 Felix Zielcke wrote: > -------------------------------------------------- > From: "Robert Millan" > Sent: Friday, August 01, 2008 5:39 PM > To: "The development of GRUB 2" > Cc: "Yoshinori K. Okuji" > Subject: Re: rename grub to grub-legacy ? > > > On Fri, Aug 01, 2008 at 05:09:41PM +0200, Marco Gerards wrote: > >> Hi, > >> > >> Robert Millan writes: > >> > What would you think of renaming grub to grub-legacy in SVN ? > >> > > >> > I think it'd help send a strong message that we consider this a legacy > >> > branch and is not open for further development. > >> > >> This is fine for me. Can you do this assuming Okuji and other > >> developers do not have strong objections? > > > > Adding Okuji to CC, just to make sure he reads it. > > Reviving this old topic. > It would be nice if grub would be renamed to grub-legacy in SVN > So we all wait now for Okuji or can this happen without him because there > were no objections AFAICS. I have no objection. Sorry for a slow response. Regards, Okuji From MAILER-DAEMON Tue Oct 07 18:31:15 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KnL5G-0006sG-VP for mharc-grub-devel@gnu.org; Tue, 07 Oct 2008 18:31:15 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnL5E-0006r3-H9 for grub-devel@gnu.org; Tue, 07 Oct 2008 18:31:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnL5C-0006qb-TB for grub-devel@gnu.org; Tue, 07 Oct 2008 18:31:12 -0400 Received: from [199.232.76.173] (port=41102 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnL5C-0006qY-Lv for grub-devel@gnu.org; Tue, 07 Oct 2008 18:31:10 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]:50929) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnL5B-0006N4-Gl for grub-devel@gnu.org; Tue, 07 Oct 2008 18:31:10 -0400 Received: from helfmeier.de (port-92-195-61-216.dynamic.qsc.de [92.195.61.216]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1KnL4v2adm-0004Af; Wed, 08 Oct 2008 00:30:58 +0200 Received: by helfmeier.de (sSMTP sendmail emulation); Wed, 08 Oct 2008 00:30:57 +0200 Date: Wed, 8 Oct 2008 00:30:57 +0200 From: Clemens Helfmeier To: grub-devel@gnu.org Message-ID: <20081007223057.GD413@helfmeier.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8P1HSweYDcXXzwPJ" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.16 (2007-06-09) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.3 X-Provags-ID: V01U2FsdGVkX18QM70GjszKgpbNiMluf+g4p5aRxoHHNwFNFwA 3pvNXYCAOckZCYTa03oG1pI//7NYyUxXb1CTDvYFQQwHTbcGXH OgjxenJqZoSXnt30pQWXQ== X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6? (barebone, rare!) Subject: Patch for different sector sizes X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2008 22:31:12 -0000 --8P1HSweYDcXXzwPJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey Guys, this seems to be a tough topic ;-) At Least i have fixed a few lines of code today, it compiles not yet in total, but i hope the task can be completed in a few more hours of work. I guess a few things will still be broken after completion, i didn't yet test anything. Maybe this is even too bad to be done? what do you think? Path Attached, please comment! bye, sumsum --8P1HSweYDcXXzwPJ Content-Type: text/x-diff; charset=unknown-8bit Content-Disposition: attachment; filename="variable_sector_size.patch" Content-Transfer-Encoding: 8bit Index: disk/lvm.c =================================================================== --- disk/lvm.c (revision 1886) +++ disk/lvm.c (working copy) @@ -185,7 +185,7 @@ read from. */ if (pv->disk) err = grub_disk_read (pv->disk, offset, 0, - size << GRUB_DISK_SECTOR_BITS, buf); + size * pv->disk->sector_size, buf); else err = grub_error (GRUB_ERR_UNKNOWN_DEVICE, "Physical volume %s not found", pv->name); Index: disk/scsi.c =================================================================== --- disk/scsi.c (revision 1886) +++ disk/scsi.c (working copy) @@ -294,7 +294,7 @@ /* SCSI blocks can be something else than 512, although GRUB wants 512 byte blocks. */ disk->total_sectors = ((scsi->size * scsi->blocksize) - << GRUB_DISK_SECTOR_BITS); + * disk->sector_size); grub_dprintf ("scsi", "capacity=%llu, blksize=%d\n", disk->total_sectors, scsi->blocksize); @@ -325,7 +325,7 @@ /* SCSI sectors are variable in size. GRUB uses 512 byte sectors. */ - sector = grub_divmod64 (sector, scsi->blocksize >> GRUB_DISK_SECTOR_BITS, + sector = grub_divmod64 (sector, scsi->blocksize / disk->sector_size, NULL); /* Depending on the type, select a read function. */ Index: disk/ata.c =================================================================== --- disk/ata.c (revision 1886) +++ disk/ata.c (working copy) @@ -77,6 +77,9 @@ GRUB_ATA_CMD_EXEC_DEV_DIAGNOSTICS = 0x90 }; +// TODO: Put the sector size into grub_ata_device +#define GRUB_ATA_SECTOR_SIZE 512 + struct grub_ata_device { /* IDE port to use. */ @@ -323,7 +326,7 @@ grub_uint16_t *info16; int ataerr = 0; - info = grub_malloc (GRUB_DISK_SECTOR_SIZE); + info = grub_malloc (GRUB_ATA_SECTOR_SIZE); if (! info) return grub_errno; @@ -343,7 +346,7 @@ } grub_ata_wait (); - if (grub_ata_pio_read (dev, info, GRUB_DISK_SECTOR_SIZE)) + if (grub_ata_pio_read (dev, info, GRUB_ATA_SECTOR_SIZE)) ataerr = grub_ata_regget (dev, GRUB_ATA_REG_ERROR); if (ataerr & 4) { Index: disk/i386/pc/biosdisk.c =================================================================== --- disk/i386/pc/biosdisk.c (revision 1886) +++ disk/i386/pc/biosdisk.c (working copy) @@ -196,8 +196,7 @@ struct grub_biosdisk_dap *dap; dap = (struct grub_biosdisk_dap *) (GRUB_MEMORY_MACHINE_SCRATCH_ADDR - + (data->sectors - << GRUB_DISK_SECTOR_BITS)); + + (data->sectors) * disk->sector_size); dap->length = sizeof (*dap); dap->reserved = 0; dap->blocks = size; @@ -305,8 +304,8 @@ return grub_errno; grub_memcpy (buf, (void *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR, - len << GRUB_DISK_SECTOR_BITS); - buf += len << GRUB_DISK_SECTOR_BITS; + len * disk->sector_size); + buf += len * disk->sector_size; sector += len; size -= len; } @@ -329,13 +328,13 @@ len = size; grub_memcpy ((void *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR, buf, - len << GRUB_DISK_SECTOR_BITS); + len * disk->sector_size); if (grub_biosdisk_rw (GRUB_BIOSDISK_WRITE, disk, sector, len, GRUB_MEMORY_MACHINE_SCRATCH_SEG)) return grub_errno; - buf += len << GRUB_DISK_SECTOR_BITS; + buf += len * disk->sector_size; sector += len; size -= len; } Index: disk/raid.c =================================================================== --- disk/raid.c (revision 1886) +++ disk/raid.c (working copy) @@ -240,6 +240,9 @@ if (read_size > size) read_size = size; + // sector size for array (must be equal for all drives, not checked) + unsigned int sector_size = 0; + for (i = 0; i < near; i++) { unsigned int k; @@ -249,13 +252,14 @@ { if (array->device[k]) { + sector_size = array->device[k]->sector_size; if (grub_errno == GRUB_ERR_READ_ERROR) grub_errno = GRUB_ERR_NONE; err = grub_disk_read (array->device[k], read_sector + j * far_ofs + b, 0, - read_size << GRUB_DISK_SECTOR_BITS, + read_size * sector_size, buf); if (! err) break; @@ -285,7 +289,7 @@ if (err) return err; - buf += read_size << GRUB_DISK_SECTOR_BITS; + buf += read_size * sector_size; size -= read_size; if (! size) break; @@ -366,7 +370,7 @@ err = grub_disk_read (array->device[disknr], read_sector + b, 0, - read_size << GRUB_DISK_SECTOR_BITS, + read_size * array->device[disknr]->sector_size, buf); if ((err) && (err != GRUB_ERR_READ_ERROR)) @@ -405,7 +409,7 @@ break; } - buf += read_size << GRUB_DISK_SECTOR_BITS; + buf += read_size * array->device[disknr]->sector_size; size -= read_size; if (! size) break; Index: disk/memdisk.c =================================================================== --- disk/memdisk.c (revision 1886) +++ disk/memdisk.c (working copy) @@ -56,7 +56,7 @@ grub_memdisk_read (grub_disk_t disk __attribute((unused)), grub_disk_addr_t sector, grub_size_t size, char *buf) { - grub_memcpy (buf, memdisk_addr + (sector << GRUB_DISK_SECTOR_BITS), size << GRUB_DISK_SECTOR_BITS); + grub_memcpy (buf, memdisk_addr + (sector * disk->sector_size), size * disk->sector_size); return 0; } @@ -64,7 +64,7 @@ grub_memdisk_write (grub_disk_t disk __attribute((unused)), grub_disk_addr_t sector, grub_size_t size, const char *buf) { - grub_memcpy (memdisk_addr + (sector << GRUB_DISK_SECTOR_BITS), buf, size << GRUB_DISK_SECTOR_BITS); + grub_memcpy (memdisk_addr + (sector * disk->sector_size), buf, size * disk->sector_size); return 0; } Index: disk/raid5_recover.c =================================================================== --- disk/raid5_recover.c (revision 1886) +++ disk/raid5_recover.c (working copy) @@ -31,7 +31,10 @@ char *buf2; int i; - size <<= GRUB_DISK_SECTOR_BITS; + if (array->device[0] == 0) + return grub_errno; + + size *= array->device[0]->sector_size; buf2 = grub_malloc (size); if (!buf2) return grub_errno; Index: disk/loopback.c =================================================================== --- disk/loopback.c (revision 1886) +++ disk/loopback.c (working copy) @@ -200,20 +200,20 @@ grub_file_t file = (grub_file_t) disk->data; grub_off_t pos; - grub_file_seek (file, sector << GRUB_DISK_SECTOR_BITS); + grub_file_seek (file, sector * disk->sector_size); - grub_file_read (file, buf, size << GRUB_DISK_SECTOR_BITS); + grub_file_read (file, buf, size * disk->sector_size); if (grub_errno) return grub_errno; /* In case there is more data read than there is available, in case of files that are not a multiple of GRUB_DISK_SECTOR_SIZE, fill the rest with zeros. */ - pos = (sector + size) << GRUB_DISK_SECTOR_BITS; + pos = (sector + size) * disk->sector_size; if (pos > file->size) { grub_size_t amount = pos - file->size; - grub_memset (buf + (size << GRUB_DISK_SECTOR_BITS) - amount, 0, amount); + grub_memset (buf + (size * disk->sector_size) - amount, 0, amount); } return 0; Index: disk/raid6_recover.c =================================================================== --- disk/raid6_recover.c (revision 1886) +++ disk/raid6_recover.c (working copy) @@ -95,7 +95,10 @@ int err[2], nerr; char *pbuf = 0, *qbuf = 0; - size <<= GRUB_DISK_SECTOR_BITS; + if (array->device[0] == 0) + goto quit; + + size *= array->device[0]->sector_size; pbuf = grub_malloc (size); if (!pbuf) goto quit; Index: kern/fs.c =================================================================== --- kern/fs.c (revision 1886) +++ kern/fs.c (working copy) @@ -198,7 +198,7 @@ goto fail; } - file->size += (blocks[i].length << GRUB_DISK_SECTOR_BITS); + file->size += (blocks[i].length * disk->sector_size); p++; } @@ -212,6 +212,23 @@ return grub_errno; } +static grub_uint32_t +grub_fs_log2 (grub_uint32_t x) +{ + grub_uint32_t i; + + if (x == 0) + return -1; + + for (i = 0; (x & 1) == 0; i++) + x >>= 1; + + if (x != 1) + return -1; + + return i; +} + static grub_ssize_t grub_fs_blocklist_read (grub_file_t file, char *buf, grub_size_t len) { @@ -219,12 +236,17 @@ grub_disk_addr_t sector; grub_off_t offset; grub_ssize_t ret = 0; + grub_disk_t disk = file->device->disk; if (len > file->size - file->offset) len = file->size - file->offset; - sector = (file->offset >> GRUB_DISK_SECTOR_BITS); - offset = (file->offset & (GRUB_DISK_SECTOR_SIZE - 1)); +// TODO: find something nice for those 64 bit divisions in here, +// for now we will use a log2 based shifting approach. + grub_uint32_t sector_shift = grub_fs_log2( disk->sector_size ); + + sector = (file->offset >> sector_shift); + offset = (file->offset & (disk->sector_size - 1)); for (p = file->data; p->length && len > 0; p++) { if (sector < p->length) @@ -232,9 +254,9 @@ grub_size_t size; size = len; - if (((size + offset + GRUB_DISK_SECTOR_SIZE - 1) - >> GRUB_DISK_SECTOR_BITS) > p->length - sector) - size = ((p->length - sector) << GRUB_DISK_SECTOR_BITS) - offset; + if (((size + offset + disk->sector_size - 1) + >> sector_shift) > p->length - sector) + size = ((p->length - sector) * disk->sector_size) - offset; if (grub_disk_read (file->device->disk, p->offset + sector, offset, size, buf) != GRUB_ERR_NONE) @@ -242,8 +264,8 @@ ret += size; len -= size; - sector -= ((size + offset) >> GRUB_DISK_SECTOR_BITS); - offset = ((size + offset) & (GRUB_DISK_SECTOR_SIZE - 1)); + sector -= ((size + offset) >> sector_shift); + offset = ((size + offset) & (disk->sector_size - 1)); } else sector -= p->length; Index: kern/rescue.c =================================================================== --- kern/rescue.c (revision 1886) +++ kern/rescue.c (working copy) @@ -129,8 +129,9 @@ static void grub_rescue_cmd_cat (int argc, char *argv[]) { +#define CHUNK_SIZE 512 grub_file_t file; - char buf[GRUB_DISK_SECTOR_SIZE]; + char buf[CHUNK_SIZE]; grub_ssize_t size; if (argc < 1) Index: kern/disk.c =================================================================== --- kern/disk.c (revision 1886) +++ kern/disk.c (working copy) @@ -148,25 +148,25 @@ } static grub_err_t -grub_disk_cache_store (unsigned long dev_id, unsigned long disk_id, +grub_disk_cache_store (unsigned long dev_id, grub_disk_t disk, grub_disk_addr_t sector, const char *data) { unsigned index; struct grub_disk_cache *cache; - grub_disk_cache_invalidate (dev_id, disk_id, sector); + grub_disk_cache_invalidate (dev_id, disk->id, sector); - index = grub_disk_cache_get_index (dev_id, disk_id, sector); + index = grub_disk_cache_get_index (dev_id, disk->id, sector); cache = grub_disk_cache_table + index; - cache->data = grub_malloc (GRUB_DISK_SECTOR_SIZE << GRUB_DISK_CACHE_BITS); + cache->data = grub_malloc ( disk->sector_size << GRUB_DISK_CACHE_BITS); if (! cache->data) return grub_errno; grub_memcpy (cache->data, data, - GRUB_DISK_SECTOR_SIZE << GRUB_DISK_CACHE_BITS); + disk->sector_size << GRUB_DISK_CACHE_BITS); cache->dev_id = dev_id; - cache->disk_id = disk_id; + cache->disk_id = disk->id; cache->sector = sector; return GRUB_ERR_NONE; @@ -330,8 +330,8 @@ grub_disk_adjust_range (grub_disk_t disk, grub_disk_addr_t *sector, grub_off_t *offset, grub_size_t size) { - *sector += *offset >> GRUB_DISK_SECTOR_BITS; - *offset &= GRUB_DISK_SECTOR_SIZE - 1; + *sector += *offset * disk->sector_size; + *offset &= disk->sector_size - 1; if (disk->partition) { @@ -342,16 +342,16 @@ len = grub_partition_get_len (disk->partition); if (*sector >= len - || len - *sector < ((*offset + size + GRUB_DISK_SECTOR_SIZE - 1) - >> GRUB_DISK_SECTOR_BITS)) + || len - *sector < ((*offset + size + disk->sector_size - 1) + * disk->sector_size)) return grub_error (GRUB_ERR_OUT_OF_RANGE, "out of partition"); *sector += start; } if (disk->total_sectors <= *sector - || ((*offset + size + GRUB_DISK_SECTOR_SIZE - 1) - >> GRUB_DISK_SECTOR_BITS) > disk->total_sectors - *sector) + || ((*offset + size + disk->sector_size - 1) + * disk->sector_size) > disk->total_sectors - *sector) return grub_error (GRUB_ERR_OUT_OF_RANGE, "out of disk"); return GRUB_ERR_NONE; @@ -380,7 +380,7 @@ real_offset = offset; /* Allocate a temporary buffer. */ - tmp_buf = grub_malloc (GRUB_DISK_SECTOR_SIZE << GRUB_DISK_CACHE_BITS); + tmp_buf = grub_malloc (disk->sector_size << GRUB_DISK_CACHE_BITS); if (! tmp_buf) return grub_errno; @@ -394,8 +394,8 @@ /* For reading bulk data. */ start_sector = sector & ~(GRUB_DISK_CACHE_SIZE - 1); - pos = (sector - start_sector) << GRUB_DISK_SECTOR_BITS; - len = ((GRUB_DISK_SECTOR_SIZE << GRUB_DISK_CACHE_BITS) + pos = (sector - start_sector) * disk->sector_size; + len = ((disk->sector_size << GRUB_DISK_CACHE_BITS) - pos - real_offset); if (len > size) len = size; @@ -421,10 +421,10 @@ grub_errno = GRUB_ERR_NONE; - num = ((size + GRUB_DISK_SECTOR_SIZE - 1) - >> GRUB_DISK_SECTOR_BITS); + num = ((size + disk->sector_size - 1) + / disk->sector_size); - p = grub_realloc (tmp_buf, num << GRUB_DISK_SECTOR_BITS); + p = grub_realloc (tmp_buf, num * disk->sector_size); if (!p) goto finish; @@ -445,11 +445,11 @@ while (size) { (disk->read_hook) (sector, real_offset, - ((size > GRUB_DISK_SECTOR_SIZE) - ? GRUB_DISK_SECTOR_SIZE + ((size > disk->sector_size) + ? disk->sector_size : size)); sector++; - size -= GRUB_DISK_SECTOR_SIZE - real_offset; + size -= disk->sector_size - real_offset; real_offset = 0; } @@ -459,7 +459,7 @@ /* Copy it and store it in the disk cache. */ grub_memcpy (buf, tmp_buf + pos + real_offset, len); - grub_disk_cache_store (disk->dev->id, disk->id, + grub_disk_cache_store (disk->dev->id, disk, start_sector, tmp_buf); } @@ -472,15 +472,15 @@ while (l) { (disk->read_hook) (s, real_offset, - ((l > GRUB_DISK_SECTOR_SIZE) - ? GRUB_DISK_SECTOR_SIZE + ((l > disk->sector_size) + ? disk->sector_size : l)); - if (l < GRUB_DISK_SECTOR_SIZE - real_offset) + if (l < disk->sector_size - real_offset) break; s++; - l -= GRUB_DISK_SECTOR_SIZE - real_offset; + l -= disk->sector_size - real_offset; real_offset = 0; } } @@ -513,16 +513,16 @@ while (size) { - if (real_offset != 0 || (size < GRUB_DISK_SECTOR_SIZE && size != 0)) + if (real_offset != 0 || (size < disk->sector_size && size != 0)) { - char tmp_buf[GRUB_DISK_SECTOR_SIZE]; + char tmp_buf[disk->sector_size]; grub_size_t len; - if (grub_disk_read (disk, sector, 0, GRUB_DISK_SECTOR_SIZE, tmp_buf) + if (grub_disk_read (disk, sector, 0, disk->sector_size, tmp_buf) != GRUB_ERR_NONE) goto finish; - len = GRUB_DISK_SECTOR_SIZE - real_offset; + len = disk->sector_size - real_offset; if (len > size) len = size; @@ -543,8 +543,8 @@ grub_size_t len; grub_size_t n; - len = size & ~(GRUB_DISK_SECTOR_SIZE - 1); - n = size >> GRUB_DISK_SECTOR_BITS; + len = size & ~(disk->sector_size - 1); + n = size / disk->sector_size; if ((disk->dev->write) (disk, sector, n, buf) != GRUB_ERR_NONE) goto finish; Index: fs/xfs.c =================================================================== --- fs/xfs.c (revision 1886) +++ fs/xfs.c (working copy) @@ -188,6 +188,23 @@ #define GRUB_XFS_NEXT_DIRENT(pos,len) \ (pos) + GRUB_XFS_ROUND_TO_DIRENT (8 + 1 + len + 2) +static int +xfs_log2 (unsigned x) +{ + int i; + + if (x == 0) + return -1; + + for (i = 0; (x & 1) == 0; i++) + x >>= 1; + + if (x != 1) + return -1; + + return i; +} + static inline int grub_xfs_inode_block (struct grub_xfs_data *data, grub_uint64_t ino) @@ -197,7 +214,7 @@ long long block; block = (inoinag >> 4) + ag * data->agsize; - block <<= (data->sblock.log2_bsize - GRUB_DISK_SECTOR_BITS); + block <<= (data->sblock.log2_bsize - data->disk->sector_size); return block; } @@ -267,8 +284,7 @@ if (grub_disk_read (node->data->disk, grub_be_to_cpu64 (keys[i - 1 + XFS_INODE_EXTENTS]) - << (node->data->sblock.log2_bsize - - GRUB_DISK_SECTOR_BITS), + << (node->data->sblock.log2_bsize) / node->data->disk->sector_size, 0, node->data->sblock.bsize, (char *) leaf)) return 0; @@ -333,8 +349,7 @@ return grub_fshelp_read_file (node->data->disk, node, read_hook, pos, len, buf, grub_xfs_read_block, grub_be_to_cpu64 (node->inode.size), - node->data->sblock.log2_bsize - - GRUB_DISK_SECTOR_BITS); + node->data->sblock.log2_bsize - xfs_log2 (node->data->disk->sector_size)); } Index: fs/afs.c =================================================================== --- fs/afs.c (revision 1886) +++ fs/afs.c (working copy) @@ -179,6 +179,23 @@ static grub_dl_t my_mod; #endif +static int +afs_log2 (unsigned x) +{ + int i; + + if (x == 0) + return -1; + + for (i = 0; (x & 1) == 0; i++) + x >>= 1; + + if (x != 1) + return -1; + + return i; +} + static grub_afs_off_t grub_afs_run_to_num (struct grub_afs_sblock *sb, struct grub_afs_blockrun *run) @@ -193,7 +210,7 @@ { return grub_disk_read (data->disk, ino * - (data->sblock.block_size >> GRUB_DISK_SECTOR_BITS), + (data->sblock.block_size / data->disk->sector_size), 0, sizeof (struct grub_afs_inode), (char *) inode); } @@ -228,7 +245,7 @@ int j; if (grub_disk_read (node->data->disk, - blk * (sb->block_size >> GRUB_DISK_SECTOR_BITS), + blk * (sb->block_size / node->data->disk->sector_size), 0, sizeof (indir), (char *) indir)) return 0; @@ -264,14 +281,14 @@ if (grub_disk_read (node->data->disk, (grub_afs_run_to_num (sb, &ds->double_indirect) + idblk) * - (sb->block_size >> GRUB_DISK_SECTOR_BITS), + (sb->block_size / node->data->disk->sector_size), 0, sizeof (indir), (char *) indir)) return 0; if (grub_disk_read (node->data->disk, (grub_afs_run_to_num (sb, &indir[idptr]) + dblk) * - (sb->block_size >> GRUB_DISK_SECTOR_BITS), + (sb->block_size / node->data->disk->sector_size), 0, sizeof (indir), (char *) indir)) return 0; @@ -293,7 +310,7 @@ U64 (&node->data->sblock, node->inode.stream.size), node->data->sblock.block_shift - - GRUB_DISK_SECTOR_BITS); + - afs_log2 (node->data->disk->sector_size)); } static int Index: fs/ntfs.c =================================================================== --- fs/ntfs.c (revision 1886) +++ fs/ntfs.c (working copy) @@ -42,10 +42,10 @@ return grub_error (GRUB_ERR_BAD_FS, "%s label not found", magic); ss = u16at (buf, 6) - 1; - if (ss * (int) data->blocksize != len * GRUB_DISK_SECTOR_SIZE) + if (ss * (int) data->blocksize != len * data->disk->sector_size) return grub_error (GRUB_ERR_BAD_FS, "Size not match", ss * (int) data->blocksize, - len * GRUB_DISK_SECTOR_SIZE); + len * data->disk->sector_size); pu = buf + u16at (buf, 4); us = u16at (pu, 0); buf -= 2; @@ -178,8 +178,8 @@ { int n; - n = ((u32at (pa, 0x30) + GRUB_DISK_SECTOR_SIZE - 1) - & (~(GRUB_DISK_SECTOR_SIZE - 1))); + n = ((u32at (pa, 0x30) + at->mft->data->disk->sector_size - 1) + & (~(at->mft->data->disk->sector_size - 1))); at->attr_cur = at->attr_end; at->edat_buf = grub_malloc (n); if (!at->edat_buf) Index: fs/fat.c =================================================================== --- fs/fat.c (revision 1886) +++ fs/fat.c (working copy) @@ -188,11 +188,12 @@ goto fail; /* Get the sizes of logical sectors and clusters. */ - data->logical_sector_bits = - fat_log2 (grub_le_to_cpu16 (bpb.bytes_per_sector)); - if (data->logical_sector_bits < GRUB_DISK_SECTOR_BITS) - goto fail; - data->logical_sector_bits -= GRUB_DISK_SECTOR_BITS; +// data->logical_sector_bits = +// fat_log2 (grub_le_to_cpu16 (bpb.bytes_per_sector)); +// if (data->logical_sector_bits < GRUB_DISK_SECTOR_BITS) +// goto fail; +// data->logical_sector_bits -= GRUB_DISK_SECTOR_BITS; + data->logical_sector_bits = fat_log2 (grub_le_to_cpu16 (bpb.bytes_per_sector / disk->sector_size) ); data->cluster_bits = fat_log2 (bpb.sectors_per_cluster); if (data->cluster_bits < 0) @@ -226,10 +227,10 @@ data->root_sector = data->fat_sector + bpb.num_fats * data->sectors_per_fat; data->num_root_sectors - = ((((grub_uint32_t) grub_le_to_cpu16 (bpb.num_root_entries) + = (((((grub_uint32_t) grub_le_to_cpu16 (bpb.num_root_entries) * GRUB_FAT_DIR_ENTRY_SIZE + grub_le_to_cpu16 (bpb.bytes_per_sector) - 1) - >> (data->logical_sector_bits + GRUB_DISK_SECTOR_BITS)) + >> (data->logical_sector_bits)) / disk->sector_size ) << (data->logical_sector_bits)); data->cluster_sector = data->root_sector + data->num_root_sectors; @@ -353,7 +354,7 @@ in clusters. */ if (data->file_cluster == ~0U) { - size = (data->num_root_sectors << GRUB_DISK_SECTOR_BITS) - offset; + size = (data->num_root_sectors * disk->sector_size) - offset; if (size > len) size = len; @@ -366,7 +367,7 @@ /* Calculate the logical cluster number and offset. */ logical_cluster_bits = (data->cluster_bits + data->logical_sector_bits - + GRUB_DISK_SECTOR_BITS); + + fat_log2 (disk->sector_size)); logical_cluster = offset >> logical_cluster_bits; offset &= (1 << logical_cluster_bits) - 1; Index: fs/iso9660.c =================================================================== --- fs/iso9660.c (revision 1886) +++ fs/iso9660.c (working copy) @@ -550,8 +550,8 @@ { if (grub_disk_read (dir->data->disk, (dir->blk << GRUB_ISO9660_LOG2_BLKSZ) - + offset / GRUB_DISK_SECTOR_SIZE, - offset % GRUB_DISK_SECTOR_SIZE, + + offset / dir->data->disk->sector_size, + offset % dir->data->disk->sector_size, sizeof (dirent), (char *) &dirent)) return 0; @@ -580,16 +580,16 @@ && grub_iso9660_susp_iterate (dir->data, (dir->blk << GRUB_ISO9660_LOG2_BLKSZ) + (sua_off - / GRUB_DISK_SECTOR_SIZE), - sua_off % GRUB_DISK_SECTOR_SIZE, + / dir->data->disk->sector_size), + sua_off % dir->data->disk->sector_size, sua_size, susp_iterate_dir)) return 0; /* Read the name. */ if (grub_disk_read (dir->data->disk, (dir->blk << GRUB_ISO9660_LOG2_BLKSZ) - + nameoffset / GRUB_DISK_SECTOR_SIZE, - nameoffset % GRUB_DISK_SECTOR_SIZE, + + nameoffset / dir->data->disk->sector_size, + nameoffset % dir->data->disk->sector_size, dirent.namelen, (char *) name)) return 0; @@ -602,8 +602,8 @@ node->size = grub_le_to_cpu32 (dirent.size); node->blk = grub_le_to_cpu32 (dirent.first_sector); node->dir_blk = ((dir->blk << GRUB_ISO9660_LOG2_BLKSZ) - + offset / GRUB_DISK_SECTOR_SIZE); - node->dir_off = offset % GRUB_DISK_SECTOR_SIZE; + + offset / dir->data->disk->sector_size); + node->dir_off = offset % dir->data->disk->sector_size; /* If the filetype was not stored using rockridge, use whatever is stored in the iso9660 filesystem. */ Index: fs/affs.c =================================================================== --- fs/affs.c (revision 1886) +++ fs/affs.c (working copy) @@ -124,7 +124,7 @@ for (links = grub_divmod64 (fileblock, data->htsize, &mod); links; links--) { grub_disk_read (data->disk, block + data->blocksize - 1, - data->blocksize * (GRUB_DISK_SECTOR_SIZE + data->blocksize * (data->disk->sector_size - GRUB_AFFS_FILE_LOCATION), sizeof (file), (char *) &file); if (grub_errno) @@ -203,7 +203,7 @@ /* No sane person uses more than 8KB for a block. At least I hope for that person because in that case this won't work. */ - rootblock = grub_malloc (GRUB_DISK_SECTOR_SIZE * 16); + rootblock = grub_malloc (disk->sector_size * 16); if (!rootblock) goto fail; @@ -211,7 +211,7 @@ /* Read the rootblock. */ grub_disk_read (disk, (disk->total_sectors >> 1) + blocksize, 0, - GRUB_DISK_SECTOR_SIZE * 16, (char *) rootblock); + disk->sector_size * 16, (char *) rootblock); if (grub_errno) goto fail; @@ -222,10 +222,10 @@ rblock->checksum = 0; for (blocksize = 0; blocksize < 8; blocksize++) { - grub_uint32_t *currblock = rootblock + GRUB_DISK_SECTOR_SIZE * blocksize; + grub_uint32_t *currblock = rootblock + disk->sector_size * blocksize; unsigned int i; - for (i = 0; i < GRUB_DISK_SECTOR_SIZE / sizeof (*currblock); i++) + for (i = 0; i < disk->sector_size / sizeof (*currblock); i++) checksum += grub_be_to_cpu32 (currblock[i]); if (checksumr == -checksum) @@ -350,7 +350,7 @@ while (next) { grub_disk_read (data->disk, next + data->blocksize - 1, - data->blocksize * GRUB_DISK_SECTOR_SIZE + data->blocksize * data->disk->sector_size - GRUB_AFFS_FILE_LOCATION, sizeof (file), (char *) &file); if (grub_errno) @@ -524,7 +524,7 @@ /* The rootblock maps quite well on a file header block, it's something we can use here. */ grub_disk_read (data->disk, disk->total_sectors >> 1, - data->blocksize * (GRUB_DISK_SECTOR_SIZE + data->blocksize * (data->disk->sector_size - GRUB_AFFS_FILE_LOCATION), sizeof (file), (char *) &file); if (grub_errno) Index: fs/fshelp.c =================================================================== --- fs/fshelp.c (revision 1886) +++ fs/fshelp.c (working copy) @@ -233,15 +233,15 @@ grub_off_t filesize, int log2blocksize) { grub_disk_addr_t i, blockcnt; - int blocksize = 1 << (log2blocksize + GRUB_DISK_SECTOR_BITS); + int blocksize = (1 << log2blocksize) * disk->sector_size; /* Adjust LEN so it we can't read past the end of the file. */ if (pos + len > filesize) len = filesize - pos; - blockcnt = ((len + pos) + blocksize - 1) >> (log2blocksize + GRUB_DISK_SECTOR_BITS); + blockcnt = (((len + pos) + blocksize - 1) >> log2blocksize) / disk->sector_size; - for (i = pos >> (log2blocksize + GRUB_DISK_SECTOR_BITS); i < blockcnt; i++) + for (i = (pos >> log2blocksize) / disk->sector_size; i < blockcnt; i++) { grub_disk_addr_t blknr; int blockoff = pos & (blocksize - 1); @@ -266,7 +266,7 @@ } /* First block. */ - if (i == (pos >> (log2blocksize + GRUB_DISK_SECTOR_BITS))) + if (i == ((pos >> log2blocksize) / disk->sector_size)) { skipfirst = blockoff; blockend -= skipfirst; Index: fs/reiserfs.c =================================================================== --- fs/reiserfs.c (revision 1886) +++ fs/reiserfs.c (working copy) @@ -509,9 +509,9 @@ do { grub_disk_read (data->disk, - block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + block_number * (block_size / data->disk->sector_size), (((grub_off_t) block_number * block_size) - & (GRUB_DISK_SECTOR_SIZE - 1)), + & (data->disk->sector_size - 1)), block_size, (char *) block_header); if (grub_errno) goto fail; @@ -659,7 +659,7 @@ block_size = grub_le_to_cpu16 (node->data->superblock.block_size); len = grub_le_to_cpu16 (found.header.item_size); - block = found.block_number * (block_size >> GRUB_DISK_SECTOR_BITS); + block = found.block_number * (block_size / node->data->disk->sector_size); offset = grub_le_to_cpu16 (found.header.item_location); symlink_buffer = grub_malloc (len + 1); @@ -686,7 +686,7 @@ data = grub_malloc (sizeof (*data)); if (! data) goto fail; - grub_disk_read (disk, REISERFS_SUPER_BLOCK_OFFSET / GRUB_DISK_SECTOR_SIZE, + grub_disk_read (disk, REISERFS_SUPER_BLOCK_OFFSET / disk->sector_size, 0, sizeof (data->superblock), (char *) &(data->superblock)); if (grub_errno) goto fail; @@ -744,9 +744,9 @@ struct grub_reiserfs_item_header *item_headers; grub_disk_read (data->disk, - block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + block_number * (block_size / data->disk->sector_size), (((grub_off_t) block_number * block_size) - & (GRUB_DISK_SECTOR_SIZE - 1)), + & (data->disk->sector_size - 1)), block_size, (char *) block_header); if (grub_errno) goto fail; @@ -838,7 +838,7 @@ { struct grub_reiserfs_stat_item_v1 entry_v1_stat; grub_disk_read (data->disk, - entry_block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + entry_block_number * (block_size / data->disk->sector_size), grub_le_to_cpu16 (entry_item->header.item_location), sizeof (entry_v1_stat), (char *) &entry_v1_stat); @@ -880,7 +880,7 @@ { struct grub_reiserfs_stat_item_v2 entry_v2_stat; grub_disk_read (data->disk, - entry_block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + entry_block_number * (block_size / data->disk->sector_size), grub_le_to_cpu16 (entry_item->header.item_location), sizeof (entry_v2_stat), (char *) &entry_v2_stat); @@ -1028,10 +1028,10 @@ { struct grub_reiserfs_stat_item_v1 entry_v1_stat; grub_disk_read (data->disk, - block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + block_number * (block_size / data->disk->sector_size), entry_location + (((grub_off_t) block_number * block_size) - & (GRUB_DISK_SECTOR_SIZE - 1)), + & (data->disk->sector_size - 1)), sizeof (entry_v1_stat), (char *) &entry_v1_stat); if (grub_errno) goto fail; @@ -1041,10 +1041,10 @@ { struct grub_reiserfs_stat_item_v2 entry_v2_stat; grub_disk_read (data->disk, - block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + block_number * (block_size / data->disk->sector_size), entry_location + (((grub_off_t) block_number * block_size) - & (GRUB_DISK_SECTOR_SIZE - 1)), + & (data->disk->sector_size - 1)), sizeof (entry_v2_stat), (char *) &entry_v2_stat); if (grub_errno) goto fail; @@ -1111,7 +1111,7 @@ switch (found.type) { case GRUB_REISERFS_DIRECT: - block = found.block_number * (block_size >> GRUB_DISK_SECTOR_BITS); + block = found.block_number * (block_size / data->disk->sector_size); grub_dprintf ("reiserfs_blocktype", "D: %u\n", (unsigned) block); if (initial_position < current_position + item_size) { @@ -1143,7 +1143,7 @@ if (! indirect_block_ptr) goto fail; grub_disk_read (found.data->disk, - found.block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + found.block_number * (block_size / found.data->disk->sector_size), grub_le_to_cpu16 (found.header.item_location), item_size, (char *) indirect_block_ptr); if (grub_errno) @@ -1155,7 +1155,7 @@ indirect_block++) { block = grub_le_to_cpu32 (indirect_block_ptr[indirect_block]) * - (block_size >> GRUB_DISK_SECTOR_BITS); + (block_size / found.data->disk->sector_size); grub_dprintf ("reiserfs_blocktype", "I: %u\n", (unsigned) block); if (current_position + block_size >= initial_position) { @@ -1334,7 +1334,7 @@ if (*label) { grub_disk_read (device->disk, - REISERFS_SUPER_BLOCK_OFFSET / GRUB_DISK_SECTOR_SIZE, + REISERFS_SUPER_BLOCK_OFFSET / device->disk->sector_size, REISERFS_LABEL_OFFSET, REISERFS_MAX_LABEL_LENGTH, *label); } Index: fs/jfs.c =================================================================== --- fs/jfs.c (revision 1886) +++ fs/jfs.c (working copy) @@ -277,8 +277,7 @@ if (grub_disk_read (data->disk, grub_le_to_cpu32 (extents[found].extent.blk2) - << (grub_le_to_cpu16 (data->sblock.log2_blksz) - - GRUB_DISK_SECTOR_BITS), 0, + << (grub_le_to_cpu16 (data->sblock.log2_blksz)) * data->disk->sector_size, 0, sizeof (tree), (char *) &tree)) return -1; @@ -309,14 +308,14 @@ /* Read in the IAG. */ if (grub_disk_read (data->disk, - iagblk << (grub_le_to_cpu16 (data->sblock.log2_blksz) - - GRUB_DISK_SECTOR_BITS), 0, + iagblk << (grub_le_to_cpu16 (data->sblock.log2_blksz)) * data->disk->sector_size, 0, sizeof (struct grub_jfs_iag), (char *) &iag)) return grub_errno; inoblk = grub_le_to_cpu32 (iag.inodes[inoext].blk2); - inoblk <<= (grub_le_to_cpu16 (data->sblock.log2_blksz) - - GRUB_DISK_SECTOR_BITS); + inoblk <<= (grub_le_to_cpu16 (data->sblock.log2_blksz)); + inoblk /= data->disk->sector_size; + inoblk += inonum; if (grub_disk_read (data->disk, inoblk, 0, @@ -412,7 +411,8 @@ } blk = grub_le_to_cpu32 (de[inode->dir.header.sorted[0]].ex.blk2); - blk <<= (grub_le_to_cpu16 (data->sblock.log2_blksz) - GRUB_DISK_SECTOR_BITS); + blk <<= (grub_le_to_cpu16 (data->sblock.log2_blksz)); + blk /= data->disk->sector_size; /* Read in the nodes until we are on the leaf node level. */ do @@ -430,8 +430,7 @@ de = (struct grub_jfs_internal_dirent *) diro->dirpage->dirent; index = diro->dirpage->sorted[diro->dirpage->header.sindex * 32]; blk = (grub_le_to_cpu32 (de[index].ex.blk2) - << (grub_le_to_cpu16 (data->sblock.log2_blksz) - - GRUB_DISK_SECTOR_BITS)); + << (grub_le_to_cpu16 (data->sblock.log2_blksz)) * data->disk->sector_size); } while (!(diro->dirpage->header.flags & GRUB_JFS_TREE_LEAF)); diro->leaf = diro->dirpage->dirent; @@ -485,8 +484,8 @@ return GRUB_ERR_OUT_OF_RANGE; next = grub_le_to_cpu64 (diro->dirpage->header.nextb); - next <<= (grub_le_to_cpu16 (diro->data->sblock.log2_blksz) - - GRUB_DISK_SECTOR_BITS); + next <<= (grub_le_to_cpu16 (diro->data->sblock.log2_blksz)); + next /= diro->data->disk->sector_size; if (grub_disk_read (diro->data->disk, next, 0, grub_le_to_cpu32 (diro->data->sblock.blksz), @@ -583,8 +582,7 @@ data->disk->read_hook = read_hook; grub_disk_read (data->disk, - blknr << (grub_le_to_cpu16 (data->sblock.log2_blksz) - - GRUB_DISK_SECTOR_BITS), + blknr << (grub_le_to_cpu16 (data->sblock.log2_blksz)) * data->disk->sector_size, skipfirst, blockend, buf); data->disk->read_hook = 0; Index: fs/minix.c =================================================================== --- fs/minix.c (revision 1886) +++ fs/minix.c (working copy) @@ -263,8 +263,8 @@ if (data->version == 1) { - block += ino / (GRUB_DISK_SECTOR_SIZE / sizeof (struct grub_minix_inode)); - int offs = (ino % (GRUB_DISK_SECTOR_SIZE + block += ino / (data->disk->sector_size / sizeof (struct grub_minix_inode)); + int offs = (ino % (data->disk->sector_size / sizeof (struct grub_minix_inode)) * sizeof (struct grub_minix_inode)); @@ -273,10 +273,10 @@ } else { - block += ino / (GRUB_DISK_SECTOR_SIZE + block += ino / (data->disk->sector_size / sizeof (struct grub_minix2_inode)); int offs = (ino - % (GRUB_DISK_SECTOR_SIZE / sizeof (struct grub_minix2_inode)) + % (data->disk->sector_size / sizeof (struct grub_minix2_inode)) * sizeof (struct grub_minix2_inode)); grub_disk_read (data->disk, block, offs, Index: fs/hfsplus.c =================================================================== --- fs/hfsplus.c (revision 1886) +++ fs/hfsplus.c (working copy) @@ -225,6 +225,23 @@ #endif +static int +hfsplus_log2 (unsigned x) +{ + int i; + + if (x == 0) + return -1; + + for (i = 0; (x & 1) == 0; i++) + x >>= 1; + + if (x != 1) + return -1; + + return i; +} + /* Return the offset of the record with the index INDEX, in the node NODE which is part of the B+ tree BTREE. */ static inline unsigned int @@ -310,7 +327,7 @@ if (blk != -1) return (blk + (node->data->embedded_offset >> (node->data->log2blksize - - GRUB_DISK_SECTOR_BITS))); + - hfsplus_log2 (node->data->disk->sector_size)))); /* For the extent overflow file, extra extents can't be found in the extent overflow file. If this happens, you found a @@ -363,7 +380,7 @@ return grub_fshelp_read_file (node->data->disk, node, read_hook, pos, len, buf, grub_hfsplus_read_block, node->size, - node->data->log2blksize - GRUB_DISK_SECTOR_BITS); + node->data->log2blksize - hfsplus_log2 (node->data->disk->sector_size)); } static struct grub_hfsplus_data * @@ -409,7 +426,7 @@ ablk_start = grub_be_to_cpu16 (volheader.hfs.first_block); data->embedded_offset = (ablk_start + extent_start - * (ablk_size >> GRUB_DISK_SECTOR_BITS)); + * (ablk_size / data->disk->sector_size)); grub_disk_read (disk, data->embedded_offset + GRUB_HFSPLUS_SBLOCK, 0, sizeof (volheader), (char *) &volheader); Index: fs/cpio.c =================================================================== --- fs/cpio.c (revision 1886) +++ fs/cpio.c (working copy) @@ -145,9 +145,9 @@ return grub_errno; data->size = grub_strtoul (hd.size, NULL, 8); - data->dofs = data->hofs + GRUB_DISK_SECTOR_SIZE; - *ofs = data->dofs + ((data->size + GRUB_DISK_SECTOR_SIZE - 1) & - ~(GRUB_DISK_SECTOR_SIZE - 1)); + data->dofs = data->hofs + data->disk->sector_size; + *ofs = data->dofs + ((data->size + data->disk->sector_size - 1) & + ~(data->disk->sector_size - 1)); } return GRUB_ERR_NONE; } Index: include/grub/ntfs.h =================================================================== --- include/grub/ntfs.h (revision 1886) +++ include/grub/ntfs.h (working copy) @@ -67,7 +67,8 @@ #define FLAG_ENCRYPTED 0x4000 #define FLAG_SPARSE 0x8000 -#define BLK_SHR GRUB_DISK_SECTOR_BITS +// TODO: This is quite bad, was GRUB_DISK_SECTOR_BITS (whch in turn was 9 for 512 Byte/Sector disks) +#define BLK_SHR 9 #define MAX_MFT (1024 >> BLK_SHR) #define MAX_IDX (16384 >> BLK_SHR) Index: include/grub/disk.h =================================================================== --- include/grub/disk.h (revision 1886) +++ include/grub/disk.h (working copy) @@ -94,6 +94,9 @@ /* The underlying disk device. */ grub_disk_dev_t dev; + /* The size of each sector. */ + grub_uint32_t sector_size; + /* The total number of sectors. */ grub_uint64_t total_sectors; @@ -126,8 +129,8 @@ #endif /* The sector size. */ -#define GRUB_DISK_SECTOR_SIZE 0x200 -#define GRUB_DISK_SECTOR_BITS 9 +#define GRUB_DISK_SECTOR_SIZE (disk->sector_size) +// #define GRUB_DISK_SECTOR_BITS 9 /* The maximum number of disk caches. */ #define GRUB_DISK_CACHE_NUM 1021 Index: commands/cat.c =================================================================== --- commands/cat.c (revision 1886) +++ commands/cat.c (working copy) @@ -31,8 +31,9 @@ int argc, char **args) { +#define GRUB_CMD_CAT_CHUNK_SIZE 512 grub_file_t file; - char buf[GRUB_DISK_SECTOR_SIZE]; + char buf[GRUB_CMD_CAT_CHUNK_SIZE]; grub_ssize_t size; int key = 0; Index: commands/blocklist.c =================================================================== --- commands/blocklist.c (revision 1886) +++ commands/blocklist.c (working copy) @@ -31,7 +31,7 @@ int argc, char **args) { grub_file_t file; - char buf[GRUB_DISK_SECTOR_SIZE]; + char *buf; unsigned long start_sector = 0; unsigned num_sectors = 0; int num_entries = 0; @@ -47,7 +47,7 @@ if (num_sectors > 0) { if (start_sector + num_sectors == sector - && offset == 0 && length == GRUB_DISK_SECTOR_SIZE) + && offset == 0 && length == file->device->disk->sector_size) { num_sectors++; return; @@ -57,7 +57,7 @@ num_sectors = 0; } - if (offset == 0 && length == GRUB_DISK_SECTOR_SIZE) + if (offset == 0 && length == file->device->disk->sector_size) { start_sector = sector; num_sectors++; @@ -90,6 +90,8 @@ return grub_error (GRUB_ERR_BAD_DEVICE, "this command is available only for disk devices."); + buf = grub_malloc (file->device->disk->sector_size); + if (file->device->disk->partition) part_start = grub_partition_get_start (file->device->disk->partition); @@ -103,6 +105,7 @@ grub_file_close (file); + grub_free (buf); return grub_errno; } Index: loader/i386/pc/linux.c =================================================================== --- loader/i386/pc/linux.c (revision 1886) +++ loader/i386/pc/linux.c (working copy) @@ -143,8 +143,8 @@ if (! setup_sects) setup_sects = GRUB_LINUX_DEFAULT_SETUP_SECTS; - real_size = setup_sects << GRUB_DISK_SECTOR_BITS; - prot_size = grub_file_size (file) - real_size - GRUB_DISK_SECTOR_SIZE; + real_size = setup_sects * file->device->disk->sector_size; + prot_size = grub_file_size (file) - real_size - file->device->disk->sector_size; grub_linux_tmp_addr = (char *) GRUB_LINUX_BZIMAGE_ADDR + prot_size; @@ -229,7 +229,7 @@ /* Put the real mode code at the temporary address. */ grub_memmove (grub_linux_tmp_addr, &lh, sizeof (lh)); - len = real_size + GRUB_DISK_SECTOR_SIZE - sizeof (lh); + len = real_size + file->device->disk->sector_size - sizeof (lh); if (grub_file_read (file, grub_linux_tmp_addr + sizeof (lh), len) != len) { grub_error (GRUB_ERR_FILE_READ_ERROR, "Couldn't read file"); @@ -240,10 +240,10 @@ || grub_le_to_cpu16 (lh.version) < 0x0200) /* Clear the heap space. */ grub_memset (grub_linux_tmp_addr - + ((setup_sects + 1) << GRUB_DISK_SECTOR_BITS), + + ((setup_sects + 1) * file->device->disk->sector_size), 0, ((GRUB_LINUX_MAX_SETUP_SECTS - setup_sects - 1) - << GRUB_DISK_SECTOR_BITS)); + * file->device->disk->sector_size)); /* Specify the boot file. */ dest = grub_stpcpy (grub_linux_tmp_addr + GRUB_LINUX_CL_OFFSET, Index: loader/i386/pc/chainloader.c =================================================================== --- loader/i386/pc/chainloader.c (revision 1886) +++ loader/i386/pc/chainloader.c (working copy) @@ -63,32 +63,9 @@ grub_dl_ref (my_mod); - file = grub_file_open (filename); - if (! file) - goto fail; - /* Read the first block. */ - if (grub_file_read (file, (char *) 0x7C00, GRUB_DISK_SECTOR_SIZE) - != GRUB_DISK_SECTOR_SIZE) - { - if (grub_errno == GRUB_ERR_NONE) - grub_error (GRUB_ERR_BAD_OS, "too small"); - - goto fail; - } - - /* Check the signature. */ - signature = *((grub_uint16_t *) (0x7C00 + GRUB_DISK_SECTOR_SIZE - 2)); - if (signature != grub_le_to_cpu16 (0xaa55) - && ! (flags & GRUB_CHAINLOADER_FORCE)) - { - grub_error (GRUB_ERR_BAD_OS, "invalid signature"); - goto fail; - } - - grub_file_close (file); - - /* Obtain the partition table from the root device. */ + /* Obtain the partition table from the root device. we have to open the + device in order to get the sector size */ dev = grub_device_open (0); if (dev) { @@ -96,6 +73,35 @@ if (disk) { + file = grub_file_open (filename); + if (! file) + { + goto fail; + grub_device_close (dev); + } + + /* Read the first block. */ + if (grub_file_read (file, (char *) 0x7C00, disk->sector_size) + != disk->sector_size) + { + if (grub_errno == GRUB_ERR_NONE) + grub_error (GRUB_ERR_BAD_OS, "too small"); + grub_device_close (dev); + goto fail; + } + + /* Check the signature. */ + signature = *((grub_uint16_t *) (0x7C00 + disk->sector_size - 2)); + if (signature != grub_le_to_cpu16 (0xaa55) + && ! (flags & GRUB_CHAINLOADER_FORCE)) + { + grub_error (GRUB_ERR_BAD_OS, "invalid signature"); + grub_device_close (dev); + goto fail; + } + + grub_file_close (file); + grub_partition_t p = disk->partition; /* In i386-pc, the id is equal to the BIOS drive number. */ Index: util/grub-probe.c =================================================================== --- util/grub-probe.c (revision 1886) +++ util/grub-probe.c (working copy) @@ -112,18 +112,26 @@ int abstraction_type; grub_device_t dev = NULL; grub_fs_t fs; + + grub_util_info ("starting probe..."); if (path == NULL) { if (! grub_util_check_block_device (device_name)) + grub_util_info ("2"); grub_util_error ("%s is not a block device.\n", device_name); } - else + else { + grub_util_info ("3"); device_name = grub_guess_root_device (path); + } + grub_util_info ("1"); if (! device_name) grub_util_error ("cannot find a device for %s.\n", path); + grub_util_info ("2"); + if (print == PRINT_DEVICE) { printf ("%s\n", device_name); @@ -165,7 +173,7 @@ grub_util_info ("opening %s", drive_name); dev = grub_device_open (drive_name); if (! dev) - grub_util_error ("%s", grub_errmsg); + grub_util_error ("grub_device_open failed: %s", grub_errmsg); if (print == PRINT_PARTMAP) { @@ -358,22 +366,32 @@ } argument = argv[optind]; + + grub_util_info ("arguments parsed."); /* Initialize the emulated biosdisk driver. */ grub_util_biosdisk_init (dev_map ? : DEFAULT_DEVICE_MAP); + + grub_util_info ("biosdisk initialized"); /* Initialize all modules. */ grub_init_all (); + grub_util_info ("all modules initialized"); + /* Do it. */ if (argument_is_device) probe (NULL, argument); else probe (argument, NULL); + + grub_util_info ("probe executed"); /* Free resources. */ grub_fini_all (); grub_util_biosdisk_fini (); + + grub_util_info ("all modules deinitialized"); free (dev_map); Index: util/i386/pc/grub-mkimage.c =================================================================== --- util/i386/pc/grub-mkimage.c (revision 1886) +++ util/i386/pc/grub-mkimage.c (working copy) @@ -129,7 +129,7 @@ #endif static void -generate_image (const char *dir, char *prefix, FILE *out, char *mods[], char *memdisk_path) +generate_image (const char *dir, char *prefix, FILE *out, char *mods[], char *memdisk_path, grub_uint32_t target_sector_size) { grub_addr_t module_addr = 0; char *kernel_img, *boot_img, *core_img; @@ -208,19 +208,19 @@ grub_util_info ("the core size is 0x%x", core_size); - num = ((core_size + GRUB_DISK_SECTOR_SIZE - 1) >> GRUB_DISK_SECTOR_BITS); + num = ((core_size + target_sector_size - 1) / target_sector_size); if (num > 0xffff) grub_util_error ("the core image is too big"); boot_path = grub_util_get_path (dir, "diskboot.img"); boot_size = grub_util_get_image_size (boot_path); - if (boot_size != GRUB_DISK_SECTOR_SIZE) + if (boot_size != target_sector_size) grub_util_error ("diskboot.img is not one sector size"); boot_img = grub_util_read_image (boot_path); /* i386 is a little endian architecture. */ - *((grub_uint16_t *) (boot_img + GRUB_DISK_SECTOR_SIZE + *((grub_uint16_t *) (boot_img + target_sector_size - GRUB_BOOT_MACHINE_LIST_SIZE + 8)) = grub_cpu_to_le16 (num); @@ -229,7 +229,7 @@ free (boot_path); module_addr = (path_list - ? (GRUB_BOOT_MACHINE_KERNEL_ADDR + GRUB_DISK_SECTOR_SIZE + ? (GRUB_BOOT_MACHINE_KERNEL_ADDR + target_sector_size + kernel_size) : 0); @@ -280,6 +280,7 @@ {"help", no_argument, 0, 'h'}, {"version", no_argument, 0, 'V'}, {"verbose", no_argument, 0, 'v'}, + {"sector-size", required_argument, 0, 's'}, {0, 0, 0, 0} }; @@ -301,6 +302,7 @@ -h, --help display this message and exit\n\ -V, --version print version information and exit\n\ -v, --verbose print verbose messages\n\ + -s, --sector-size=NR set sector size to NR bytes\n\ \n\ Report bugs to <%s>.\n\ ", GRUB_LIBDIR, DEFAULT_DIRECTORY, PACKAGE_BUGREPORT); @@ -316,6 +318,7 @@ char *prefix = NULL; char *memdisk = NULL; FILE *fp = stdout; + grub_uint32_t target_sector_size = 0; progname = "grub-mkimage"; @@ -372,6 +375,10 @@ case 'v': verbosity++; break; + + case 's': + target_sector_size = atoi (optarg); + break; default: usage (1); @@ -386,8 +393,15 @@ grub_util_error ("cannot open %s", output); } - generate_image (dir ? : GRUB_LIBDIR, prefix ? : DEFAULT_DIRECTORY, fp, argv + optind, memdisk); + if (target_sector_size == 0) + { + printf ("invalid sector size given!"); + usage (1); + } + + generate_image (dir ? : GRUB_LIBDIR, prefix ? : DEFAULT_DIRECTORY, fp, argv + optind, memdisk, target_sector_size); + fclose (fp); if (dir) Index: util/i386/pc/grub-setup.c =================================================================== --- util/i386/pc/grub-setup.c (revision 1886) +++ util/i386/pc/grub-setup.c (working copy) @@ -105,9 +105,8 @@ char *tmp_img; int i; grub_disk_addr_t first_sector; - grub_uint16_t current_segment - = GRUB_BOOT_MACHINE_KERNEL_SEG + (GRUB_DISK_SECTOR_SIZE >> 4); - grub_uint16_t last_length = GRUB_DISK_SECTOR_SIZE; + grub_uint16_t current_segment; + grub_uint16_t last_length = 0; grub_file_t file; FILE *fp; struct { grub_uint64_t start; grub_uint64_t end; } embed_region; @@ -160,7 +159,7 @@ grub_util_info ("the first sector is <%llu,%u,%u>", sector, offset, length); - if (offset != 0 || length != GRUB_DISK_SECTOR_SIZE) + if (offset != 0 || length != dest_dev->disk->sector_size) grub_util_error ("The first sector of the core file is not sector-aligned"); first_sector = sector; @@ -174,7 +173,7 @@ grub_util_info ("saving <%llu,%u,%u> with the segment 0x%x", sector, offset, length, (unsigned) current_segment); - if (offset != 0 || last_length != GRUB_DISK_SECTOR_SIZE) + if (offset != 0 || last_length != dest_dev->disk->sector_size) grub_util_error ("Non-sector-aligned data is found in the core file"); if (block != first_block @@ -193,15 +192,25 @@ } last_length = length; - current_segment += GRUB_DISK_SECTOR_SIZE >> 4; + current_segment += dest_dev->disk->sector_size >> 4; } - + + /* Open the destination device and read sector size (automagically done by grub_device_open)*/ + dest_dev = grub_device_open (dest); + if (! dest_dev) + grub_util_error ("%s", grub_errmsg); + + /* initialize sector-size dependant variables */ + last_length = dest_dev->disk->sector_size; + current_segment = GRUB_BOOT_MACHINE_KERNEL_SEG + (dest_dev->disk->sector_size >> 4); + /* Read the boot image by the OS service. */ boot_path = grub_util_get_path (dir, boot_file); boot_size = grub_util_get_image_size (boot_path); - if (boot_size != GRUB_DISK_SECTOR_SIZE) - grub_util_error ("The size of `%s' is not %d", - boot_path, GRUB_DISK_SECTOR_SIZE); + if (boot_size != dest_dev->disk->sector_size) + grub_util_error ("The size of `%s' is not %d, you should adapt the image sector size to the\ + sector size of the target block device.", + boot_path, dest_dev->disk->sector_size); boot_img = grub_util_read_image (boot_path); free (boot_path); @@ -215,23 +224,23 @@ core_path = grub_util_get_path (dir, core_file); core_size = grub_util_get_image_size (core_path); - core_sectors = ((core_size + GRUB_DISK_SECTOR_SIZE - 1) - >> GRUB_DISK_SECTOR_BITS); - if (core_size < GRUB_DISK_SECTOR_SIZE) + core_sectors = ((core_size + dest_dev->disk->sector_size - 1) + / dest_dev->disk->sector_size); + if (core_size < dest_dev->disk->sector_size) grub_util_error ("The size of `%s' is too small", core_path); - else if (core_size > 0xFFFF * GRUB_DISK_SECTOR_SIZE) + else if (core_size > 0xFFFF * dest_dev->disk->sector_size) grub_util_error ("The size of `%s' is too large", core_path); core_img = grub_util_read_image (core_path); /* Have FIRST_BLOCK to point to the first blocklist. */ first_block = (struct boot_blocklist *) (core_img - + GRUB_DISK_SECTOR_SIZE + + dest_dev->disk->sector_size - sizeof (*block)); - install_dos_part = (grub_int32_t *) (core_img + GRUB_DISK_SECTOR_SIZE + install_dos_part = (grub_int32_t *) (core_img + dest_dev->disk->sector_size + GRUB_KERNEL_MACHINE_INSTALL_DOS_PART); - install_bsd_part = (grub_int32_t *) (core_img + GRUB_DISK_SECTOR_SIZE + install_bsd_part = (grub_int32_t *) (core_img + dest_dev->disk->sector_size + GRUB_KERNEL_MACHINE_INSTALL_BSD_PART); /* Open the root device and the destination device. */ @@ -239,17 +248,13 @@ if (! root_dev) grub_util_error ("%s", grub_errmsg); - dest_dev = grub_device_open (dest); - if (! dest_dev) - grub_util_error ("%s", grub_errmsg); - grub_util_info ("setting the root device to `%s'", root); if (grub_env_set ("root", root) != GRUB_ERR_NONE) grub_util_error ("%s", grub_errmsg); /* Read the original sector from the disk. */ - tmp_img = xmalloc (GRUB_DISK_SECTOR_SIZE); - if (grub_disk_read (dest_dev->disk, 0, 0, GRUB_DISK_SECTOR_SIZE, tmp_img)) + tmp_img = xmalloc (dest_dev->disk->sector_size); + if (grub_disk_read (dest_dev->disk, 0, 0, dest_dev->disk->sector_size, tmp_img)) grub_util_error ("%s", grub_errmsg); /* Copy the possible DOS BPB. */ @@ -327,7 +332,7 @@ first_block->len = grub_cpu_to_le16 (core_sectors - 1); first_block->segment = grub_cpu_to_le16 (GRUB_BOOT_MACHINE_KERNEL_SEG - + (GRUB_DISK_SECTOR_SIZE >> 4)); + + (dest_dev->disk->sector_size >> 4)); /* Make sure that the second blocklist is a terminator. */ block = first_block - 1; @@ -346,7 +351,7 @@ *kernel_sector = grub_cpu_to_le64 (embed_region.start); /* Write the boot image onto the disk. */ - if (grub_disk_write (dest_dev->disk, 0, 0, GRUB_DISK_SECTOR_SIZE, + if (grub_disk_write (dest_dev->disk, 0, 0, dest_dev->disk->sector_size, boot_img)) grub_util_error ("%s", grub_errmsg); @@ -457,14 +462,14 @@ grub_util_error ("%s", grub_errmsg); file->read_hook = save_first_sector; - if (grub_file_read (file, tmp_img, GRUB_DISK_SECTOR_SIZE) - != GRUB_DISK_SECTOR_SIZE) + if (grub_file_read (file, tmp_img, dest_dev->disk->sector_size) + != dest_dev->disk->sector_size) grub_util_error ("Failed to read the first sector of the core image"); block = first_block; file->read_hook = save_blocklists; - if (grub_file_read (file, tmp_img, core_size - GRUB_DISK_SECTOR_SIZE) - != (grub_ssize_t) core_size - GRUB_DISK_SECTOR_SIZE) + if (grub_file_read (file, tmp_img, core_size - dest_dev->disk->sector_size) + != (grub_ssize_t) core_size - dest_dev->disk->sector_size) grub_util_error ("Failed to read the rest sectors of the core image"); grub_file_close (file); @@ -487,11 +492,11 @@ if (! fp) grub_util_error ("Cannot open `%s'", core_path); - grub_util_write_image (core_img, GRUB_DISK_SECTOR_SIZE * 2, fp); + grub_util_write_image (core_img, dest_dev->disk->sector_size * 2, fp); fclose (fp); /* Write the boot image onto the disk. */ - if (grub_disk_write (dest_dev->disk, 0, 0, GRUB_DISK_SECTOR_SIZE, boot_img)) + if (grub_disk_write (dest_dev->disk, 0, 0, dest_dev->disk->sector_size, boot_img)) grub_util_error ("%s", grub_errmsg); finish: Index: util/grub-mkdevicemap.c =================================================================== --- util/grub-mkdevicemap.c (revision 1886) +++ util/grub-mkdevicemap.c (working copy) @@ -70,6 +70,9 @@ # ifndef BLKGETSIZE # define BLKGETSIZE _IO(0x12,96) /* return device size */ # endif /* ! BLKGETSIZE */ +# ifndef BLKSSZGET +# define BLKSSZGET _IO(0x12,104)/* get block device sector size */ +#endif #endif /* __linux__ */ /* Use __FreeBSD_kernel__ instead of __FreeBSD__ for compatibility with @@ -328,7 +331,7 @@ static int check_device (const char *device) { - char buf[512]; + char *buf; FILE *fp; /* If DEVICE is empty, just return error. */ @@ -393,12 +396,20 @@ #endif /* __FreeBSD_kernel__ || __NetBSD__ || __OpenBSD__ */ /* Attempt to read the first sector. */ - if (fread (buf, 1, 512, fp) != 512) + grub_uint32_t size; + if (ioctl (fileno (fp), BLKSSZGET, &size)) { + grub_util_info ("can not get sector size for %s, assuming 512Bytes (non fatal).", device); + size = 512; + } + buf = grub_malloc( size ); + if (fread (buf, 1, size, fp) != size) + { + free (buf); fclose (fp); return 0; } - + free (buf); fclose (fp); return 1; } Index: util/hostdisk.c =================================================================== --- util/hostdisk.c (revision 1886) +++ util/hostdisk.c (working copy) @@ -64,6 +64,9 @@ # ifndef BLKGETSIZE64 # define BLKGETSIZE64 _IOR(0x12,114,size_t) /* return device size */ # endif /* ! BLKGETSIZE64 */ +# ifndef BLKSSZGET +# define BLKSSZGET _IO(0x12,104)/* get block device sector size */ +#endif # ifndef MAJOR # ifndef MINORBITS # define MINORBITS 8 @@ -170,10 +173,14 @@ size = grub_util_get_disk_size (map[drive].device); - if (size % 512) +// TODO: find correct sector size for mingw32 + grub_util_info ("compiled with mingw32, assuming 512 byte sector size!"); + disk->sector_size = 512; + + if (size % disk->sector_size) grub_util_error ("unaligned device size"); - disk->total_sectors = size >> 9; + disk->total_sectors = size / disk->sector_size; grub_util_info ("the size of %s is %llu", name, disk->total_sectors); @@ -194,6 +201,13 @@ goto fail; } + if (ioctl (fd, BLKSSZGET, &nr)) + { + close (fd); + goto fail; + } + disk->sector_size = nr; + if (ioctl (fd, BLKGETSIZE64, &nr)) { close (fd); @@ -201,12 +215,12 @@ } close (fd); - disk->total_sectors = nr / 512; + disk->total_sectors = nr / disk->sector_size; - if (nr % 512) + if (nr % disk->sector_size) grub_util_error ("unaligned device size"); - grub_util_info ("the size of %s is %llu", name, disk->total_sectors); + grub_util_info ("the size of %s is %llu with sector size %iu", name, disk->total_sectors, disk->sector_size); return GRUB_ERR_NONE; } @@ -215,15 +229,19 @@ /* In GNU/Hurd, stat() will return the right size. */ #elif !defined (__GNU__) # warning "No special routine to get the size of a block device is implemented for your OS. This is not possibly fatal." +# warning "No routine for getting sector size is implemented, assuming 512 bytes." + disk->sector_size = 512; #endif - if (stat (map[drive].device, &st) < 0) - return grub_error (GRUB_ERR_BAD_DEVICE, "cannot stat `%s'", map[drive].device); + { + if (stat (map[drive].device, &st) < 0) + return grub_error (GRUB_ERR_BAD_DEVICE, "cannot stat `%s'", map[drive].device); - disk->total_sectors = st.st_size >> GRUB_DISK_SECTOR_BITS; + disk->total_sectors = st.st_size / disk->sector_size; - grub_util_info ("the size of %s is %lu", name, disk->total_sectors); + grub_util_info ("the size of %s is %lu with sector size %iu", name, disk->total_sectors, disk->sector_size); - return GRUB_ERR_NONE; + return GRUB_ERR_NONE; + } } #ifdef __linux__ @@ -346,7 +364,7 @@ _syscall5 (int, _llseek, uint, filedes, ulong, hi, ulong, lo, loff_t *, res, uint, wh); - offset = (loff_t) sector << GRUB_DISK_SECTOR_BITS; + offset = (loff_t) sector * disk->sector_size; if (_llseek (fd, offset >> 32, offset & 0xffffffff, &result, SEEK_SET)) { grub_error (GRUB_ERR_BAD_DEVICE, "cannot seek `%s'", map[disk->id].device); @@ -356,7 +374,7 @@ } #else { - off_t offset = (off_t) sector << GRUB_DISK_SECTOR_BITS; + off_t offset = (off_t) sector * disk->sector_size; if (lseek (fd, offset, SEEK_SET) != offset) { @@ -422,6 +440,8 @@ return size; } + +/* read size number of SECTORS which each in turn is of disk->sector_size bytes */ static grub_err_t grub_util_biosdisk_read (grub_disk_t disk, grub_disk_addr_t sector, grub_size_t size, char *buf) @@ -432,27 +452,29 @@ if (fd < 0) return grub_errno; -#ifdef __linux__ - if (sector == 0 && size > 1) - { - /* Work around a bug in Linux ez remapping. Linux remaps all - sectors that are read together with the MBR in one read. It - should only remap the MBR, so we split the read in two - parts. -jochen */ - if (nread (fd, buf, GRUB_DISK_SECTOR_SIZE) != GRUB_DISK_SECTOR_SIZE) - { - grub_error (GRUB_ERR_READ_ERROR, "cannot read `%s'", map[disk->id].device); - close (fd); - return grub_errno; - } - - buf += GRUB_DISK_SECTOR_SIZE; - size--; - } -#endif /* __linux__ */ - - if (nread (fd, buf, size << GRUB_DISK_SECTOR_BITS) - != (ssize_t) (size << GRUB_DISK_SECTOR_BITS)) +//#ifdef __linux__ +// if (sector == 0 && size > 1) +// { +// /* Work around a bug in Linux ez remapping. Linux remaps all +// sectors that are read together with the MBR in one read. It +// should only remap the MBR, so we split the read in two +// parts. -jochen */ +// if (nread (fd, buf, GRUB_DISK_SECTOR_SIZE) != GRUB_DISK_SECTOR_SIZE) +// { +// grub_error (GRUB_ERR_READ_ERROR, "cannot read `%s'", map[disk->id].device); +// close (fd); +// return grub_errno; +// } +// +// buf += GRUB_DISK_SECTOR_SIZE; +// size--; +// } +//#endif /* __linux__ */ +// since we now read sectors only, we don'Ãt need no sepcial handling for MBRsize!=SectorSize +// this _must_ be done by the caller now! + + if (nread (fd, buf, size * disk->sector_size) + != (ssize_t) (size * disk->sector_size)) grub_error (GRUB_ERR_READ_ERROR, "cannot read from `%s'", map[disk->id].device); close (fd); @@ -469,8 +491,8 @@ if (fd < 0) return grub_errno; - if (nwrite (fd, buf, size << GRUB_DISK_SECTOR_BITS) - != (ssize_t) (size << GRUB_DISK_SECTOR_BITS)) + if (nwrite (fd, buf, size * disk->sector_size) + != (ssize_t) (size * disk->sector_size)) grub_error (GRUB_ERR_WRITE_ERROR, "cannot write to `%s'", map[disk->id].device); close (fd); --8P1HSweYDcXXzwPJ-- From MAILER-DAEMON Wed Oct 08 00:12:38 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KnQPd-0005zl-SR for mharc-grub-devel@gnu.org; Wed, 08 Oct 2008 00:12:37 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnQPb-0005wV-Es for grub-devel@gnu.org; Wed, 08 Oct 2008 00:12:35 -0400 Received: from [199.232.76.173] (port=42962 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnQPa-0005w4-VQ for grub-devel@gnu.org; Wed, 08 Oct 2008 00:12:35 -0400 Received: from smtp.aircanopy.net ([66.160.208.25]:33508) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KnQPa-0007qS-Hc for grub-devel@gnu.org; Wed, 08 Oct 2008 00:12:34 -0400 X-ASG-Debug-ID: 1223439152-712400040000-Td4drV X-Barracuda-URL: http://66.160.208.25:8000/cgi-bin/mark.cgi Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net (Spam Firewall) with ESMTP id 69758799130 for ; Tue, 7 Oct 2008 23:12:32 -0500 (CDT) Received: from aczmr1.aircanopy.net (aczmr1.aircanopy.net [66.160.208.172]) by smtp.aircanopy.net with ESMTP id iIMtB3iawS7EGiVM for ; Tue, 07 Oct 2008 23:12:32 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by aczmr1.aircanopy.net (Postfix) with ESMTP id 4F66C1D6A0 for ; Tue, 7 Oct 2008 23:12:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.839 Received: from aczmr1.aircanopy.net ([127.0.0.1]) by localhost (aczmr1.aircanopy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSnwYcdBZYIs for ; Tue, 7 Oct 2008 23:12:31 -0500 (CDT) Received: from aczmb1.aircanopy.net (aczmb1.aircanopy.net [66.160.208.170]) by aczmr1.aircanopy.net (Postfix) with ESMTP id DFB6718216 for ; Tue, 7 Oct 2008 23:12:31 -0500 (CDT) Date: Tue, 7 Oct 2008 23:12:31 -0500 (CDT) From: Andy Goth To: The development of GRUB 2 Message-ID: <1460730204.89441223439151710.JavaMail.root@aczmb1> In-Reply-To: <270343305.88391223432285723.JavaMail.root@aczmb1> X-ASG-Orig-Subj: Re: No scrolling for long input lines MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [66.160.219.98] X-Mailer: Zimbra 5.0.8_GA_2462.SLES10_64 (ZimbraWebClient - FF2.0 (Linux)/5.0.8_GA_2462.SLES10_64) X-Barracuda-Connect: aczmr1.aircanopy.net[66.160.208.172] X-Barracuda-Start-Time: 1223439152 X-Barracuda-Virus-Scanned: by Aircanopy Spam Firewall at aircanopy.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.7528 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Subject: Re: No scrolling for long input lines X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2008 04:12:36 -0000 "Andy Goth" wrote: > I'll test the current SVN this Friday, or perhaps Thursday night at > the earliest. Actually I did spend time tonight investigating. I needed to get the latest SVN for another reason (about which I have questions I'll ask in a few days), so I went ahead and looked into my scrolling input problem. Yup, still there. Today's SVN is affected. The problem is present when actually booting using GRUB (ordinary VGA text mode), but it all works fine in grub-emu. Wait, I take that back. In grub-emu, typing very long lines (that wrap and *cause the screen to scroll*) results in the text wrapping at column 80 instead of column 79, so that there is *not* a white space character in the rightmost column. Pressing Ctrl-U from such a line will only erase only the bottom line of text, except for the first six characters (which presumably correspond to "grub> "). Something's flaky! However, this grub-emu stuff might be unrelated to the problem I've been having with the actual boot loader. I also add that in grub-emu, the carriage doesn't return after printing an error message, so I get a stairstep effect. With such an indented prompt, issuing a command like "ls" causes output to be printed to the *left* of the prompt. Enough about grub-emu. In the actual boot loader, I noticed that the pattern seems to be: it will scroll the screen if inserting text will cause the last character to overflow the right edge of the screen. That sounds like the way it should be, right? The problem is that only currently visible characters appear to be checked for overflow. This doesn't include the character being typed or characters that previously have failed to scroll onscreen. Test cases: 1. Near the top of the screen, type a bunch of text and overflow the edge. Works fine. 2. Hold down enter until the screen starts scrolling. Works fine. 3. Type a bunch of text and overflow the edge. Fails to scroll! 4. Use the left arrow key one or two times and type text. Fails to scroll! 5. Use the left arrow key until the cursor is onscreen, and type text. Everything scrolls into view. I'd absolutely love to debug all this and provide patches, but I really don't have time right now. In fact I didn't have time to do the research I did; I should have been sleeping. :^( -- Andy Goth | http://andy.junkdrome.org/ unununium@{aircanopy.net,openverse.com} From MAILER-DAEMON Wed Oct 08 09:24:49 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KnZ21-000784-Mo for mharc-grub-devel@gnu.org; Wed, 08 Oct 2008 09:24:49 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnZ1z-00077j-Fl for grub-devel@gnu.org; Wed, 08 Oct 2008 09:24:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnZ1y-00077H-8D for grub-devel@gnu.org; Wed, 08 Oct 2008 09:24:46 -0400 Received: from [199.232.76.173] (port=55767 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnZ1y-00077E-2g for grub-devel@gnu.org; Wed, 08 Oct 2008 09:24:46 -0400 Received: from fg-out-1718.google.com ([72.14.220.159]:13702) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnZ1x-0000Al-5A for grub-devel@gnu.org; Wed, 08 Oct 2008 09:24:45 -0400 Received: by fg-out-1718.google.com with SMTP id l26so2999645fgb.30 for ; Wed, 08 Oct 2008 06:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=eljju8zdrOTuJIFTwzc4Rbd1DOPHWEgatnt0cmSIJM8=; b=Jd0Q2u9AK9Z/hd2t+eIjwNIDh6uUa/HXgU7LAJ2CoHUDmiI+ZefyeruhEYimcoxmEk 2PgV9FKKxwkRW/8NiMMav9M2cTghFNPXZN77tfzV+uGT1rG69zxoH0X3dKg8PBAdqh8F 4W2Ae2Z+rHampTxktluOZyTG9VpDCS1uYSg1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=j8ApeDdsYmwKxyd/w1LqD5CQm99KNPLIQ84ydCFhZc/Zl9YFS0Z++64rlZ8w3A0+gd 6hFQ+EMmUEiYu/AgJPpvbaHZ2rrP2Spq98YTeGgVImQcouIGLA+i1r47UExpHthv19hE eXMHKktA5okf3U5FfAKw6F7nIE1hE0wrAv2uE= Received: by 10.181.30.10 with SMTP id h10mr6098439bkj.41.1223472282243; Wed, 08 Oct 2008 06:24:42 -0700 (PDT) Received: by 10.181.15.13 with HTTP; Wed, 8 Oct 2008 06:24:42 -0700 (PDT) Message-ID: Date: Wed, 8 Oct 2008 23:24:42 +1000 From: "Cameron Braid" Sender: cbraid@gmail.com To: "The development of GRUB 2" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_87784_3789715.1223472282254" References: <264154299.32731223135767648.JavaMail.root@aczmb1> X-Google-Sender-Auth: a7ac62c7b7655b76 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: grub2 /boot on lvm on ubuntu - incorrect magic number X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2008 13:24:47 -0000 ------=_Part_87784_3789715.1223472282254 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Is this a bug in grub2 .. i.e. should I submit a bug with the grub2 bugtracker, or should I chase this up with some LVM people ? Cheers Cameron On Sun, Oct 5, 2008 at 8:59 AM, Cameron Braid wrote: > > $ sudo grub-install /dev/mapper/Ubuntu-hardy64 > > I thought that the install_device argument to grub-install had to be a > harddisk (to use the MBR) or a partition in which the grub image was > installed. And I thought that grub detects the abstraction based on what > /boot points to. > > Cameron > > > > On Sun, Oct 5, 2008 at 1:56 AM, Andy Goth wrote: > >> "Cameron Braid" wrote: >> > * root partition is a lvm device (/dev/mapper/Ubuntu-hardy64) >> > >> > beast:grub2$ sudo grub-install /dev/sdd >> >> From looking at the GRUB 1.96 sources, I get the impression that this >> command line should be: >> >> $ sudo grub-install /dev/mapper/Ubuntu-hardy64 >> >> in order for grub-probe to see the abstraction as >> GRUB_DEV_ABSTRACTION_LVM. >> >> I could be majorly wrong, and this may have changed between 1.96 and the >> version that Cameron is using, but... I'm just trying to figure out how GRUB >> works. :^) >> >> -- >> Andy Goth | http://andy.junkdrome.org/ >> unununium@{aircanopy.net,openverse.com} >> >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel >> > > ------=_Part_87784_3789715.1223472282254 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Is this a bug in grub2 .. i.e. should I submit a bug with the grub2 bugtracker, or should I chase this up with some LVM people ?

Cheers

Cameron

On Sun, Oct 5, 2008 at 8:59 AM, Cameron Braid <cameron@braid.com.au> wrote:
> $ sudo grub-install /dev/mapper/Ubuntu-hardy64

I thought that the install_device argument to grub-install had to be a harddisk (to use the MBR) or a partition in which the grub image was installed.  And I thought that grub detects the abstraction based on what /boot points to.

Cameron



On Sun, Oct 5, 2008 at 1:56 AM, Andy Goth <unununium@aircanopy.net> wrote:
"Cameron Braid" <cameron@braid.com.au> wrote:
> * root partition is a lvm device (/dev/mapper/Ubuntu-hardy64)
>
> beast:grub2$ sudo grub-install /dev/sdd

From looking at the GRUB 1.96 sources, I get the impression that this command line should be:

$ sudo grub-install /dev/mapper/Ubuntu-hardy64

in order for grub-probe to see the abstraction as GRUB_DEV_ABSTRACTION_LVM.

I could be majorly wrong, and this may have changed between 1.96 and the version that Cameron is using, but... I'm just trying to figure out how GRUB works. :^)

--
Andy Goth | http://andy.junkdrome.org/
unununium@{aircanopy.net,openverse.com}


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


------=_Part_87784_3789715.1223472282254-- From MAILER-DAEMON Wed Oct 08 12:12:04 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Knbdr-0004B2-P9 for mharc-grub-devel@gnu.org; Wed, 08 Oct 2008 12:12:03 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Knbdp-00049t-Ce for grub-devel@gnu.org; Wed, 08 Oct 2008 12:12:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Knbdm-00048U-Ho for grub-devel@gnu.org; Wed, 08 Oct 2008 12:12:00 -0400 Received: from [199.232.76.173] (port=32769 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Knbdm-00048I-9i for grub-devel@gnu.org; Wed, 08 Oct 2008 12:11:58 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:57411) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Knbdj-000314-Ob for grub-devel@gnu.org; Wed, 08 Oct 2008 12:11:57 -0400 Received: from helfmeier.de (port-92-195-87-176.dynamic.qsc.de [92.195.87.176]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1Knbdb2qNm-0005Ct; Wed, 08 Oct 2008 18:11:53 +0200 Received: by helfmeier.de (sSMTP sendmail emulation); Wed, 08 Oct 2008 18:11:45 +0200 Date: Wed, 8 Oct 2008 18:11:45 +0200 From: Clemens Helfmeier To: grub-devel@gnu.org Message-ID: <20081008161145.GA790@helfmeier.de> References: <20081007223057.GD413@helfmeier.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20081007223057.GD413@helfmeier.de> User-Agent: Mutt/1.5.16 (2007-06-09) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.3 X-Provags-ID: V01U2FsdGVkX19dw5OuEzkBt66BmEI8WG8+eAWXqNYhq+2wenu EZ1wEIv34V2xl/yCdFCQ8bcSPJpH6y10WTiGevcuLFguPYNxlr +eggd/0PQZpUeKrOaNm1w== X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: Patch for different sector sizes X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2008 16:12:01 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi everyone, i have now finished most of the sector size modifications. Still, there are a few things to be done: e.g. the file system drivers must be checked for correct handling of places, etc. (ext2 is fixed with this patch, fat works here on a 2048 device without modification, a few others should still be done). Most likely the ATA and SCSI drivers are also broken. Best would be to have someone check on that who knows the hardware here. Unfortunately i could not yet test the bootup procedure since my hardware does not detect the pendrive which i have here correctly. maybe i will have a different one with 2048bytes sector size another day. Perhaps there are volunteers who want to test this patch? IMPORTANT: the grub-mkimage tool has got a new option (--sector-size=XX) which must be given. Since this tool does not actually handle things with hard drives, it can not detect the correct sector size on it's own. Any suggestions on how to fix this? (maybe we can make it work with either sector-size or target-device supplied on command line) Bye, Clemens (sum) On Wed, Oct 08, 2008 at 12:30:57AM +0200, Clemens Helfmeier wrote: > Hey Guys, > > this seems to be a tough topic ;-) > > At Least i have fixed a few lines of code today, it compiles not yet in total, > but i hope the task can be completed in a few more hours of work. I guess a few > things will still be broken after completion, i didn't yet test anything. > > Maybe this is even too bad to be done? what do you think? > > Path Attached, please comment! > > bye, > sumsum --2oS5YaxWCcQjTEyO Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="variable_sector_size.patch" Index: disk/lvm.c =================================================================== --- disk/lvm.c (revision 1886) +++ disk/lvm.c (working copy) @@ -185,7 +185,7 @@ read from. */ if (pv->disk) err = grub_disk_read (pv->disk, offset, 0, - size << GRUB_DISK_SECTOR_BITS, buf); + size * pv->disk->sector_size, buf); else err = grub_error (GRUB_ERR_UNKNOWN_DEVICE, "Physical volume %s not found", pv->name); @@ -221,6 +221,7 @@ struct grub_lvm_vg *vg; struct grub_lvm_pv *pv; + disk = grub_disk_open (name); if (!disk) return 0; Index: disk/scsi.c =================================================================== --- disk/scsi.c (revision 1886) +++ disk/scsi.c (working copy) @@ -294,7 +294,7 @@ /* SCSI blocks can be something else than 512, although GRUB wants 512 byte blocks. */ disk->total_sectors = ((scsi->size * scsi->blocksize) - << GRUB_DISK_SECTOR_BITS); + * disk->sector_size); grub_dprintf ("scsi", "capacity=%llu, blksize=%d\n", disk->total_sectors, scsi->blocksize); @@ -325,7 +325,7 @@ /* SCSI sectors are variable in size. GRUB uses 512 byte sectors. */ - sector = grub_divmod64 (sector, scsi->blocksize >> GRUB_DISK_SECTOR_BITS, + sector = grub_divmod64 (sector, grub_divmod64(scsi->blocksize, disk->sector_size, NULL), NULL); /* Depending on the type, select a read function. */ Index: disk/ata.c =================================================================== --- disk/ata.c (revision 1886) +++ disk/ata.c (working copy) @@ -77,6 +77,9 @@ GRUB_ATA_CMD_EXEC_DEV_DIAGNOSTICS = 0x90 }; +// TODO: Put the sector size into grub_ata_device +#define GRUB_ATA_SECTOR_SIZE 512 + struct grub_ata_device { /* IDE port to use. */ @@ -323,7 +326,7 @@ grub_uint16_t *info16; int ataerr = 0; - info = grub_malloc (GRUB_DISK_SECTOR_SIZE); + info = grub_malloc (GRUB_ATA_SECTOR_SIZE); if (! info) return grub_errno; @@ -343,7 +346,7 @@ } grub_ata_wait (); - if (grub_ata_pio_read (dev, info, GRUB_DISK_SECTOR_SIZE)) + if (grub_ata_pio_read (dev, info, GRUB_ATA_SECTOR_SIZE)) ataerr = grub_ata_regget (dev, GRUB_ATA_REG_ERROR); if (ataerr & 4) { @@ -681,9 +684,9 @@ for (sect = 0; sect < batch; sect++) { if (grub_ata_pio_read (dev, buf, - GRUB_DISK_SECTOR_SIZE)) + GRUB_ATA_SECTOR_SIZE)) return grub_errno; - buf += GRUB_DISK_SECTOR_SIZE; + buf += GRUB_ATA_SECTOR_SIZE; } } else @@ -699,9 +702,9 @@ for (sect = 0; sect < batch; sect++) { if (grub_ata_pio_write (dev, buf, - GRUB_DISK_SECTOR_SIZE)) + GRUB_ATA_SECTOR_SIZE)) return grub_error (GRUB_ERR_WRITE_ERROR, "ATA write error"); - buf += GRUB_DISK_SECTOR_SIZE; + buf += GRUB_ATA_SECTOR_SIZE; } } sector += batch; @@ -723,9 +726,9 @@ for (sect = 0; sect < (size % batch); sect++) { - if (grub_ata_pio_read (dev, buf, GRUB_DISK_SECTOR_SIZE)) + if (grub_ata_pio_read (dev, buf, GRUB_ATA_SECTOR_SIZE)) return grub_errno; - buf += GRUB_DISK_SECTOR_SIZE; + buf += GRUB_ATA_SECTOR_SIZE; } } else { /* Write sectors. */ @@ -738,9 +741,9 @@ for (sect = 0; sect < (size % batch); sect++) { - if (grub_ata_pio_write (dev, buf, GRUB_DISK_SECTOR_SIZE)) + if (grub_ata_pio_write (dev, buf, GRUB_ATA_SECTOR_SIZE)) return grub_error (GRUB_ERR_WRITE_ERROR, "ATA write error"); - buf += GRUB_DISK_SECTOR_SIZE; + buf += GRUB_ATA_SECTOR_SIZE; } } Index: disk/i386/pc/biosdisk.c =================================================================== --- disk/i386/pc/biosdisk.c (revision 1886) +++ disk/i386/pc/biosdisk.c (working copy) @@ -196,8 +196,7 @@ struct grub_biosdisk_dap *dap; dap = (struct grub_biosdisk_dap *) (GRUB_MEMORY_MACHINE_SCRATCH_ADDR - + (data->sectors - << GRUB_DISK_SECTOR_BITS)); + + (data->sectors) * disk->sector_size); dap->length = sizeof (*dap); dap->reserved = 0; dap->blocks = size; @@ -305,8 +304,8 @@ return grub_errno; grub_memcpy (buf, (void *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR, - len << GRUB_DISK_SECTOR_BITS); - buf += len << GRUB_DISK_SECTOR_BITS; + len * disk->sector_size); + buf += len * disk->sector_size; sector += len; size -= len; } @@ -329,13 +328,13 @@ len = size; grub_memcpy ((void *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR, buf, - len << GRUB_DISK_SECTOR_BITS); + len * disk->sector_size); if (grub_biosdisk_rw (GRUB_BIOSDISK_WRITE, disk, sector, len, GRUB_MEMORY_MACHINE_SCRATCH_SEG)) return grub_errno; - buf += len << GRUB_DISK_SECTOR_BITS; + buf += len * disk->sector_size; sector += len; size -= len; } Index: disk/raid.c =================================================================== --- disk/raid.c (revision 1886) +++ disk/raid.c (working copy) @@ -240,6 +240,9 @@ if (read_size > size) read_size = size; + // sector size for array (must be equal for all drives, not checked) + unsigned int sector_size = 0; + for (i = 0; i < near; i++) { unsigned int k; @@ -249,13 +252,14 @@ { if (array->device[k]) { + sector_size = array->device[k]->sector_size; if (grub_errno == GRUB_ERR_READ_ERROR) grub_errno = GRUB_ERR_NONE; err = grub_disk_read (array->device[k], read_sector + j * far_ofs + b, 0, - read_size << GRUB_DISK_SECTOR_BITS, + read_size * sector_size, buf); if (! err) break; @@ -285,7 +289,7 @@ if (err) return err; - buf += read_size << GRUB_DISK_SECTOR_BITS; + buf += read_size * sector_size; size -= read_size; if (! size) break; @@ -366,7 +370,7 @@ err = grub_disk_read (array->device[disknr], read_sector + b, 0, - read_size << GRUB_DISK_SECTOR_BITS, + read_size * array->device[disknr]->sector_size, buf); if ((err) && (err != GRUB_ERR_READ_ERROR)) @@ -405,7 +409,7 @@ break; } - buf += read_size << GRUB_DISK_SECTOR_BITS; + buf += read_size * array->device[disknr]->sector_size; size -= read_size; if (! size) break; Index: disk/raid5_recover.c =================================================================== --- disk/raid5_recover.c (revision 1886) +++ disk/raid5_recover.c (working copy) @@ -31,7 +31,10 @@ char *buf2; int i; - size <<= GRUB_DISK_SECTOR_BITS; + if (array->device[0] == 0) + return grub_errno; + + size *= array->device[0]->sector_size; buf2 = grub_malloc (size); if (!buf2) return grub_errno; Index: disk/memdisk.c =================================================================== --- disk/memdisk.c (revision 1886) +++ disk/memdisk.c (working copy) @@ -25,6 +25,8 @@ #include #include +#define GRUB_MEMDISK_SECTOR_SIZE 512 + static char *memdisk_addr; static grub_off_t memdisk_size = 0; @@ -40,7 +42,9 @@ if (grub_strcmp (name, "memdisk")) return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "not a memdisk"); - disk->total_sectors = memdisk_size / GRUB_DISK_SECTOR_SIZE; + // Memdisk may have any number of bytes/sectors, just choose something here. + disk->sector_size = GRUB_MEMDISK_SECTOR_SIZE; + disk->total_sectors = grub_divmod64(memdisk_size, disk->sector_size, 0); disk->id = (unsigned long) "mdsk"; disk->has_partitions = 0; @@ -56,7 +60,7 @@ grub_memdisk_read (grub_disk_t disk __attribute((unused)), grub_disk_addr_t sector, grub_size_t size, char *buf) { - grub_memcpy (buf, memdisk_addr + (sector << GRUB_DISK_SECTOR_BITS), size << GRUB_DISK_SECTOR_BITS); + grub_memcpy (buf, memdisk_addr + (sector * disk->sector_size), size * disk->sector_size); return 0; } @@ -64,7 +68,7 @@ grub_memdisk_write (grub_disk_t disk __attribute((unused)), grub_disk_addr_t sector, grub_size_t size, const char *buf) { - grub_memcpy (memdisk_addr + (sector << GRUB_DISK_SECTOR_BITS), buf, size << GRUB_DISK_SECTOR_BITS); + grub_memcpy (memdisk_addr + (sector * disk->sector_size), buf, size * disk->sector_size); return 0; } Index: disk/raid6_recover.c =================================================================== --- disk/raid6_recover.c (revision 1886) +++ disk/raid6_recover.c (working copy) @@ -95,7 +95,10 @@ int err[2], nerr; char *pbuf = 0, *qbuf = 0; - size <<= GRUB_DISK_SECTOR_BITS; + if (array->device[0] == 0) + goto quit; + + size *= array->device[0]->sector_size; pbuf = grub_malloc (size); if (!pbuf) goto quit; Index: disk/loopback.c =================================================================== --- disk/loopback.c (revision 1886) +++ disk/loopback.c (working copy) @@ -25,6 +25,9 @@ #include #include +// any value is adequate. this affects the loopback disk +#define GRUB_LOOPBACK_SECTOR_SIZE 512 + struct grub_loopback { char *devname; @@ -174,9 +177,11 @@ if (! file) return grub_errno; + /* set size of sectors */ + disk->sector_size = GRUB_LOOPBACK_SECTOR_SIZE; /* Use the filesize for the disk size, round up to a complete sector. */ - disk->total_sectors = ((file->size + GRUB_DISK_SECTOR_SIZE - 1) - / GRUB_DISK_SECTOR_SIZE); + disk->total_sectors = grub_divmod64((file->size + disk->sector_size - 1), + disk->sector_size, NULL); disk->id = (unsigned long) dev; disk->has_partitions = dev->has_partitions; @@ -200,20 +205,20 @@ grub_file_t file = (grub_file_t) disk->data; grub_off_t pos; - grub_file_seek (file, sector << GRUB_DISK_SECTOR_BITS); + grub_file_seek (file, sector * disk->sector_size); - grub_file_read (file, buf, size << GRUB_DISK_SECTOR_BITS); + grub_file_read (file, buf, size * disk->sector_size); if (grub_errno) return grub_errno; /* In case there is more data read than there is available, in case of files that are not a multiple of GRUB_DISK_SECTOR_SIZE, fill the rest with zeros. */ - pos = (sector + size) << GRUB_DISK_SECTOR_BITS; + pos = (sector + size) * disk->sector_size; if (pos > file->size) { grub_size_t amount = pos - file->size; - grub_memset (buf + (size << GRUB_DISK_SECTOR_BITS) - amount, 0, amount); + grub_memset (buf + (size * disk->sector_size) - amount, 0, amount); } return 0; Index: kern/fs.c =================================================================== --- kern/fs.c (revision 1886) +++ kern/fs.c (working copy) @@ -198,7 +198,7 @@ goto fail; } - file->size += (blocks[i].length << GRUB_DISK_SECTOR_BITS); + file->size += (blocks[i].length * disk->sector_size); p++; } @@ -219,12 +219,12 @@ grub_disk_addr_t sector; grub_off_t offset; grub_ssize_t ret = 0; + grub_disk_t disk = file->device->disk; if (len > file->size - file->offset) len = file->size - file->offset; - sector = (file->offset >> GRUB_DISK_SECTOR_BITS); - offset = (file->offset & (GRUB_DISK_SECTOR_SIZE - 1)); + sector = grub_divmod64(file->offset, disk->sector_size, &offset); for (p = file->data; p->length && len > 0; p++) { if (sector < p->length) @@ -232,9 +232,9 @@ grub_size_t size; size = len; - if (((size + offset + GRUB_DISK_SECTOR_SIZE - 1) - >> GRUB_DISK_SECTOR_BITS) > p->length - sector) - size = ((p->length - sector) << GRUB_DISK_SECTOR_BITS) - offset; + if ((grub_divmod64(size + offset + disk->sector_size - 1, + disk->sector_size, NULL) > p->length - sector)) + size = ((p->length - sector) * disk->sector_size) - offset; if (grub_disk_read (file->device->disk, p->offset + sector, offset, size, buf) != GRUB_ERR_NONE) @@ -242,8 +242,7 @@ ret += size; len -= size; - sector -= ((size + offset) >> GRUB_DISK_SECTOR_BITS); - offset = ((size + offset) & (GRUB_DISK_SECTOR_SIZE - 1)); + sector -= grub_divmod64((size + offset), disk->sector_size, &offset); } else sector -= p->length; Index: kern/rescue.c =================================================================== --- kern/rescue.c (revision 1886) +++ kern/rescue.c (working copy) @@ -130,7 +130,7 @@ grub_rescue_cmd_cat (int argc, char *argv[]) { grub_file_t file; - char buf[GRUB_DISK_SECTOR_SIZE]; + char buf[GRUB_RESCUE_BUF_SIZE]; grub_ssize_t size; if (argc < 1) Index: kern/disk.c =================================================================== --- kern/disk.c (revision 1886) +++ kern/disk.c (working copy) @@ -148,25 +148,25 @@ } static grub_err_t -grub_disk_cache_store (unsigned long dev_id, unsigned long disk_id, +grub_disk_cache_store (unsigned long dev_id, grub_disk_t disk, grub_disk_addr_t sector, const char *data) { unsigned index; struct grub_disk_cache *cache; - grub_disk_cache_invalidate (dev_id, disk_id, sector); + grub_disk_cache_invalidate (dev_id, disk->id, sector); - index = grub_disk_cache_get_index (dev_id, disk_id, sector); + index = grub_disk_cache_get_index (dev_id, disk->id, sector); cache = grub_disk_cache_table + index; - cache->data = grub_malloc (GRUB_DISK_SECTOR_SIZE << GRUB_DISK_CACHE_BITS); + cache->data = grub_malloc ( disk->sector_size << GRUB_DISK_CACHE_BITS); if (! cache->data) return grub_errno; grub_memcpy (cache->data, data, - GRUB_DISK_SECTOR_SIZE << GRUB_DISK_CACHE_BITS); + disk->sector_size << GRUB_DISK_CACHE_BITS); cache->dev_id = dev_id; - cache->disk_id = disk_id; + cache->disk_id = disk->id; cache->sector = sector; return GRUB_ERR_NONE; @@ -330,9 +330,8 @@ grub_disk_adjust_range (grub_disk_t disk, grub_disk_addr_t *sector, grub_off_t *offset, grub_size_t size) { - *sector += *offset >> GRUB_DISK_SECTOR_BITS; - *offset &= GRUB_DISK_SECTOR_SIZE - 1; - + *sector += grub_divmod64(*offset, disk->sector_size, offset); + if (disk->partition) { grub_disk_addr_t start; @@ -342,16 +341,16 @@ len = grub_partition_get_len (disk->partition); if (*sector >= len - || len - *sector < ((*offset + size + GRUB_DISK_SECTOR_SIZE - 1) - >> GRUB_DISK_SECTOR_BITS)) + || len - *sector < (grub_divmod64(*offset + size + disk->sector_size - 1, + disk->sector_size, NULL))) return grub_error (GRUB_ERR_OUT_OF_RANGE, "out of partition"); *sector += start; } if (disk->total_sectors <= *sector - || ((*offset + size + GRUB_DISK_SECTOR_SIZE - 1) - >> GRUB_DISK_SECTOR_BITS) > disk->total_sectors - *sector) + || (grub_divmod64(*offset + size + disk->sector_size - 1, + disk->sector_size, NULL) > disk->total_sectors - *sector)) return grub_error (GRUB_ERR_OUT_OF_RANGE, "out of disk"); return GRUB_ERR_NONE; @@ -380,10 +379,11 @@ real_offset = offset; /* Allocate a temporary buffer. */ - tmp_buf = grub_malloc (GRUB_DISK_SECTOR_SIZE << GRUB_DISK_CACHE_BITS); + tmp_buf = grub_malloc (disk->sector_size << GRUB_DISK_CACHE_BITS); if (! tmp_buf) return grub_errno; + /* Until SIZE is zero... */ while (size) { @@ -394,8 +394,8 @@ /* For reading bulk data. */ start_sector = sector & ~(GRUB_DISK_CACHE_SIZE - 1); - pos = (sector - start_sector) << GRUB_DISK_SECTOR_BITS; - len = ((GRUB_DISK_SECTOR_SIZE << GRUB_DISK_CACHE_BITS) + pos = (sector - start_sector) * disk->sector_size; + len = ((disk->sector_size << GRUB_DISK_CACHE_BITS) - pos - real_offset); if (len > size) len = size; @@ -404,6 +404,7 @@ data = grub_disk_cache_fetch (disk->dev->id, disk->id, start_sector); if (data) { +// grub_util_info ("disk cache hit, pos=%ul realofs=%ul, len=%ul", pos, real_offset, len); /* Just copy it! */ grub_memcpy (buf, data + pos + real_offset, len); grub_disk_cache_unlock (disk->dev->id, disk->id, start_sector); @@ -421,10 +422,10 @@ grub_errno = GRUB_ERR_NONE; - num = ((size + GRUB_DISK_SECTOR_SIZE - 1) - >> GRUB_DISK_SECTOR_BITS); + num = grub_divmod64((size + disk->sector_size - 1), + disk->sector_size, NULL); - p = grub_realloc (tmp_buf, num << GRUB_DISK_SECTOR_BITS); + p = grub_realloc (tmp_buf, num * disk->sector_size); if (!p) goto finish; @@ -445,11 +446,11 @@ while (size) { (disk->read_hook) (sector, real_offset, - ((size > GRUB_DISK_SECTOR_SIZE) - ? GRUB_DISK_SECTOR_SIZE + ((size > disk->sector_size) + ? disk->sector_size : size)); sector++; - size -= GRUB_DISK_SECTOR_SIZE - real_offset; + size -= disk->sector_size - real_offset; real_offset = 0; } @@ -457,9 +458,11 @@ goto finish; } +// grub_util_info ("disk read ok, pos=%ul realofs=%ul, len=%ul", pos, real_offset, len); + /* Copy it and store it in the disk cache. */ grub_memcpy (buf, tmp_buf + pos + real_offset, len); - grub_disk_cache_store (disk->dev->id, disk->id, + grub_disk_cache_store (disk->dev->id, disk, start_sector, tmp_buf); } @@ -472,15 +475,15 @@ while (l) { (disk->read_hook) (s, real_offset, - ((l > GRUB_DISK_SECTOR_SIZE) - ? GRUB_DISK_SECTOR_SIZE + ((l > disk->sector_size) + ? disk->sector_size : l)); - if (l < GRUB_DISK_SECTOR_SIZE - real_offset) + if (l < disk->sector_size - real_offset) break; s++; - l -= GRUB_DISK_SECTOR_SIZE - real_offset; + l -= disk->sector_size - real_offset; real_offset = 0; } } @@ -513,16 +516,16 @@ while (size) { - if (real_offset != 0 || (size < GRUB_DISK_SECTOR_SIZE && size != 0)) + if (real_offset != 0 || (size < disk->sector_size && size != 0)) { - char tmp_buf[GRUB_DISK_SECTOR_SIZE]; + char tmp_buf[disk->sector_size]; grub_size_t len; - if (grub_disk_read (disk, sector, 0, GRUB_DISK_SECTOR_SIZE, tmp_buf) + if (grub_disk_read (disk, sector, 0, disk->sector_size, tmp_buf) != GRUB_ERR_NONE) goto finish; - len = GRUB_DISK_SECTOR_SIZE - real_offset; + len = disk->sector_size - real_offset; if (len > size) len = size; @@ -543,8 +546,8 @@ grub_size_t len; grub_size_t n; - len = size & ~(GRUB_DISK_SECTOR_SIZE - 1); - n = size >> GRUB_DISK_SECTOR_BITS; + len = size & ~(disk->sector_size - 1); + n = grub_divmod64 (size, disk->sector_size, NULL); if ((disk->dev->write) (disk, sector, n, buf) != GRUB_ERR_NONE) goto finish; Index: fs/xfs.c =================================================================== --- fs/xfs.c (revision 1886) +++ fs/xfs.c (working copy) @@ -188,6 +188,7 @@ #define GRUB_XFS_NEXT_DIRENT(pos,len) \ (pos) + GRUB_XFS_ROUND_TO_DIRENT (8 + 1 + len + 2) + static inline int grub_xfs_inode_block (struct grub_xfs_data *data, grub_uint64_t ino) @@ -197,7 +198,7 @@ long long block; block = (inoinag >> 4) + ag * data->agsize; - block <<= (data->sblock.log2_bsize - GRUB_DISK_SECTOR_BITS); + block = grub_divmod64((block << data->sblock.log2_bsize), data->disk->sector_size, NULL); return block; } @@ -266,9 +267,8 @@ } if (grub_disk_read (node->data->disk, - grub_be_to_cpu64 (keys[i - 1 + XFS_INODE_EXTENTS]) - << (node->data->sblock.log2_bsize - - GRUB_DISK_SECTOR_BITS), + grub_divmod64( grub_be_to_cpu64 (keys[i - 1 + XFS_INODE_EXTENTS]) + << (node->data->sblock.log2_bsize), node->data->disk->sector_size, NULL), 0, node->data->sblock.bsize, (char *) leaf)) return 0; @@ -330,11 +330,11 @@ unsigned offset, unsigned length), int pos, grub_size_t len, char *buf) { +// TODO: Check weather the last argument here is correct. maybe it is fixed size and not fixed sector count. return grub_fshelp_read_file (node->data->disk, node, read_hook, pos, len, buf, grub_xfs_read_block, grub_be_to_cpu64 (node->inode.size), - node->data->sblock.log2_bsize - - GRUB_DISK_SECTOR_BITS); + node->data->sblock.log2_bsize - fat_log2 (node->data->disk->sector_size)); } Index: fs/afs.c =================================================================== --- fs/afs.c (revision 1886) +++ fs/afs.c (working copy) @@ -179,6 +179,7 @@ static grub_dl_t my_mod; #endif + static grub_afs_off_t grub_afs_run_to_num (struct grub_afs_sblock *sb, struct grub_afs_blockrun *run) @@ -193,7 +194,7 @@ { return grub_disk_read (data->disk, ino * - (data->sblock.block_size >> GRUB_DISK_SECTOR_BITS), + (data->sblock.block_size / data->disk->sector_size), 0, sizeof (struct grub_afs_inode), (char *) inode); } @@ -228,7 +229,7 @@ int j; if (grub_disk_read (node->data->disk, - blk * (sb->block_size >> GRUB_DISK_SECTOR_BITS), + blk * (sb->block_size / node->data->disk->sector_size), 0, sizeof (indir), (char *) indir)) return 0; @@ -264,14 +265,14 @@ if (grub_disk_read (node->data->disk, (grub_afs_run_to_num (sb, &ds->double_indirect) + idblk) * - (sb->block_size >> GRUB_DISK_SECTOR_BITS), + (sb->block_size / node->data->disk->sector_size), 0, sizeof (indir), (char *) indir)) return 0; if (grub_disk_read (node->data->disk, (grub_afs_run_to_num (sb, &indir[idptr]) + dblk) * - (sb->block_size >> GRUB_DISK_SECTOR_BITS), + (sb->block_size / node->data->disk->sector_size), 0, sizeof (indir), (char *) indir)) return 0; @@ -288,12 +289,14 @@ unsigned offset, unsigned length), int pos, grub_size_t len, char *buf) { +// TODO: get some nice way to calculate the log here. check if afs requires this value to +// be sector oriented and not 512-byte oriented. return grub_fshelp_read_file (node->data->disk, node, read_hook, pos, len, buf, grub_afs_read_block, U64 (&node->data->sblock, node->inode.stream.size), node->data->sblock.block_shift - - GRUB_DISK_SECTOR_BITS); + - fat_log2 (node->data->disk->sector_size)); } static int Index: fs/ntfs.c =================================================================== --- fs/ntfs.c (revision 1886) +++ fs/ntfs.c (working copy) @@ -42,10 +42,10 @@ return grub_error (GRUB_ERR_BAD_FS, "%s label not found", magic); ss = u16at (buf, 6) - 1; - if (ss * (int) data->blocksize != len * GRUB_DISK_SECTOR_SIZE) + if (ss * (int) data->blocksize != len * data->disk->sector_size) return grub_error (GRUB_ERR_BAD_FS, "Size not match", ss * (int) data->blocksize, - len * GRUB_DISK_SECTOR_SIZE); + len * data->disk->sector_size); pu = buf + u16at (buf, 4); us = u16at (pu, 0); buf -= 2; @@ -178,8 +178,8 @@ { int n; - n = ((u32at (pa, 0x30) + GRUB_DISK_SECTOR_SIZE - 1) - & (~(GRUB_DISK_SECTOR_SIZE - 1))); + n = ((u32at (pa, 0x30) + at->mft->data->disk->sector_size - 1) + & (~(at->mft->data->disk->sector_size - 1))); at->attr_cur = at->attr_end; at->edat_buf = grub_malloc (n); if (!at->edat_buf) Index: fs/fat.c =================================================================== --- fs/fat.c (revision 1886) +++ fs/fat.c (working copy) @@ -188,11 +188,7 @@ goto fail; /* Get the sizes of logical sectors and clusters. */ - data->logical_sector_bits = - fat_log2 (grub_le_to_cpu16 (bpb.bytes_per_sector)); - if (data->logical_sector_bits < GRUB_DISK_SECTOR_BITS) - goto fail; - data->logical_sector_bits -= GRUB_DISK_SECTOR_BITS; + data->logical_sector_bits = fat_log2 (grub_le_to_cpu16 (bpb.bytes_per_sector / disk->sector_size) ); data->cluster_bits = fat_log2 (bpb.sectors_per_cluster); if (data->cluster_bits < 0) @@ -226,10 +222,10 @@ data->root_sector = data->fat_sector + bpb.num_fats * data->sectors_per_fat; data->num_root_sectors - = ((((grub_uint32_t) grub_le_to_cpu16 (bpb.num_root_entries) + = (((((grub_uint32_t) grub_le_to_cpu16 (bpb.num_root_entries) * GRUB_FAT_DIR_ENTRY_SIZE + grub_le_to_cpu16 (bpb.bytes_per_sector) - 1) - >> (data->logical_sector_bits + GRUB_DISK_SECTOR_BITS)) + >> (data->logical_sector_bits)) / disk->sector_size ) << (data->logical_sector_bits)); data->cluster_sector = data->root_sector + data->num_root_sectors; @@ -353,7 +349,7 @@ in clusters. */ if (data->file_cluster == ~0U) { - size = (data->num_root_sectors << GRUB_DISK_SECTOR_BITS) - offset; + size = (data->num_root_sectors * disk->sector_size) - offset; if (size > len) size = len; @@ -366,7 +362,7 @@ /* Calculate the logical cluster number and offset. */ logical_cluster_bits = (data->cluster_bits + data->logical_sector_bits - + GRUB_DISK_SECTOR_BITS); + + fat_log2 (disk->sector_size)); logical_cluster = offset >> logical_cluster_bits; offset &= (1 << logical_cluster_bits) - 1; Index: fs/iso9660.c =================================================================== --- fs/iso9660.c (revision 1886) +++ fs/iso9660.c (working copy) @@ -550,8 +550,8 @@ { if (grub_disk_read (dir->data->disk, (dir->blk << GRUB_ISO9660_LOG2_BLKSZ) - + offset / GRUB_DISK_SECTOR_SIZE, - offset % GRUB_DISK_SECTOR_SIZE, + + offset / dir->data->disk->sector_size, + offset % dir->data->disk->sector_size, sizeof (dirent), (char *) &dirent)) return 0; @@ -580,16 +580,16 @@ && grub_iso9660_susp_iterate (dir->data, (dir->blk << GRUB_ISO9660_LOG2_BLKSZ) + (sua_off - / GRUB_DISK_SECTOR_SIZE), - sua_off % GRUB_DISK_SECTOR_SIZE, + / dir->data->disk->sector_size), + sua_off % dir->data->disk->sector_size, sua_size, susp_iterate_dir)) return 0; /* Read the name. */ if (grub_disk_read (dir->data->disk, (dir->blk << GRUB_ISO9660_LOG2_BLKSZ) - + nameoffset / GRUB_DISK_SECTOR_SIZE, - nameoffset % GRUB_DISK_SECTOR_SIZE, + + nameoffset / dir->data->disk->sector_size, + nameoffset % dir->data->disk->sector_size, dirent.namelen, (char *) name)) return 0; @@ -602,8 +602,8 @@ node->size = grub_le_to_cpu32 (dirent.size); node->blk = grub_le_to_cpu32 (dirent.first_sector); node->dir_blk = ((dir->blk << GRUB_ISO9660_LOG2_BLKSZ) - + offset / GRUB_DISK_SECTOR_SIZE); - node->dir_off = offset % GRUB_DISK_SECTOR_SIZE; + + offset / dir->data->disk->sector_size); + node->dir_off = offset % dir->data->disk->sector_size; /* If the filetype was not stored using rockridge, use whatever is stored in the iso9660 filesystem. */ Index: fs/affs.c =================================================================== --- fs/affs.c (revision 1886) +++ fs/affs.c (working copy) @@ -124,7 +124,7 @@ for (links = grub_divmod64 (fileblock, data->htsize, &mod); links; links--) { grub_disk_read (data->disk, block + data->blocksize - 1, - data->blocksize * (GRUB_DISK_SECTOR_SIZE + data->blocksize * (data->disk->sector_size - GRUB_AFFS_FILE_LOCATION), sizeof (file), (char *) &file); if (grub_errno) @@ -203,7 +203,7 @@ /* No sane person uses more than 8KB for a block. At least I hope for that person because in that case this won't work. */ - rootblock = grub_malloc (GRUB_DISK_SECTOR_SIZE * 16); + rootblock = grub_malloc (disk->sector_size * 16); if (!rootblock) goto fail; @@ -211,7 +211,7 @@ /* Read the rootblock. */ grub_disk_read (disk, (disk->total_sectors >> 1) + blocksize, 0, - GRUB_DISK_SECTOR_SIZE * 16, (char *) rootblock); + disk->sector_size * 16, (char *) rootblock); if (grub_errno) goto fail; @@ -222,10 +222,10 @@ rblock->checksum = 0; for (blocksize = 0; blocksize < 8; blocksize++) { - grub_uint32_t *currblock = rootblock + GRUB_DISK_SECTOR_SIZE * blocksize; + grub_uint32_t *currblock = rootblock + disk->sector_size * blocksize; unsigned int i; - for (i = 0; i < GRUB_DISK_SECTOR_SIZE / sizeof (*currblock); i++) + for (i = 0; i < disk->sector_size / sizeof (*currblock); i++) checksum += grub_be_to_cpu32 (currblock[i]); if (checksumr == -checksum) @@ -350,7 +350,7 @@ while (next) { grub_disk_read (data->disk, next + data->blocksize - 1, - data->blocksize * GRUB_DISK_SECTOR_SIZE + data->blocksize * data->disk->sector_size - GRUB_AFFS_FILE_LOCATION, sizeof (file), (char *) &file); if (grub_errno) @@ -524,7 +524,7 @@ /* The rootblock maps quite well on a file header block, it's something we can use here. */ grub_disk_read (data->disk, disk->total_sectors >> 1, - data->blocksize * (GRUB_DISK_SECTOR_SIZE + data->blocksize * (data->disk->sector_size - GRUB_AFFS_FILE_LOCATION), sizeof (file), (char *) &file); if (grub_errno) Index: fs/fshelp.c =================================================================== --- fs/fshelp.c (revision 1886) +++ fs/fshelp.c (working copy) @@ -233,15 +233,15 @@ grub_off_t filesize, int log2blocksize) { grub_disk_addr_t i, blockcnt; - int blocksize = 1 << (log2blocksize + GRUB_DISK_SECTOR_BITS); + int blocksize = (1 << log2blocksize) * disk->sector_size; /* Adjust LEN so it we can't read past the end of the file. */ if (pos + len > filesize) len = filesize - pos; - blockcnt = ((len + pos) + blocksize - 1) >> (log2blocksize + GRUB_DISK_SECTOR_BITS); + blockcnt = grub_divmod64(((len + pos) + blocksize - 1) >> log2blocksize, disk->sector_size, NULL); - for (i = pos >> (log2blocksize + GRUB_DISK_SECTOR_BITS); i < blockcnt; i++) + for (i = grub_divmod64((pos >> log2blocksize), disk->sector_size, NULL); i < blockcnt; i++) { grub_disk_addr_t blknr; int blockoff = pos & (blocksize - 1); @@ -266,7 +266,7 @@ } /* First block. */ - if (i == (pos >> (log2blocksize + GRUB_DISK_SECTOR_BITS))) + if (i == (grub_divmod64(pos >> log2blocksize, disk->sector_size, NULL))) { skipfirst = blockoff; blockend -= skipfirst; Index: fs/reiserfs.c =================================================================== --- fs/reiserfs.c (revision 1886) +++ fs/reiserfs.c (working copy) @@ -509,9 +509,9 @@ do { grub_disk_read (data->disk, - block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + block_number * (block_size / data->disk->sector_size), (((grub_off_t) block_number * block_size) - & (GRUB_DISK_SECTOR_SIZE - 1)), + & (data->disk->sector_size - 1)), block_size, (char *) block_header); if (grub_errno) goto fail; @@ -659,7 +659,7 @@ block_size = grub_le_to_cpu16 (node->data->superblock.block_size); len = grub_le_to_cpu16 (found.header.item_size); - block = found.block_number * (block_size >> GRUB_DISK_SECTOR_BITS); + block = found.block_number * (block_size / node->data->disk->sector_size); offset = grub_le_to_cpu16 (found.header.item_location); symlink_buffer = grub_malloc (len + 1); @@ -686,7 +686,7 @@ data = grub_malloc (sizeof (*data)); if (! data) goto fail; - grub_disk_read (disk, REISERFS_SUPER_BLOCK_OFFSET / GRUB_DISK_SECTOR_SIZE, + grub_disk_read (disk, REISERFS_SUPER_BLOCK_OFFSET / disk->sector_size, 0, sizeof (data->superblock), (char *) &(data->superblock)); if (grub_errno) goto fail; @@ -744,9 +744,9 @@ struct grub_reiserfs_item_header *item_headers; grub_disk_read (data->disk, - block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + block_number * (block_size / data->disk->sector_size), (((grub_off_t) block_number * block_size) - & (GRUB_DISK_SECTOR_SIZE - 1)), + & (data->disk->sector_size - 1)), block_size, (char *) block_header); if (grub_errno) goto fail; @@ -838,7 +838,7 @@ { struct grub_reiserfs_stat_item_v1 entry_v1_stat; grub_disk_read (data->disk, - entry_block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + entry_block_number * (block_size / data->disk->sector_size), grub_le_to_cpu16 (entry_item->header.item_location), sizeof (entry_v1_stat), (char *) &entry_v1_stat); @@ -880,7 +880,7 @@ { struct grub_reiserfs_stat_item_v2 entry_v2_stat; grub_disk_read (data->disk, - entry_block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + entry_block_number * (block_size / data->disk->sector_size), grub_le_to_cpu16 (entry_item->header.item_location), sizeof (entry_v2_stat), (char *) &entry_v2_stat); @@ -1028,10 +1028,10 @@ { struct grub_reiserfs_stat_item_v1 entry_v1_stat; grub_disk_read (data->disk, - block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + block_number * (block_size / data->disk->sector_size), entry_location + (((grub_off_t) block_number * block_size) - & (GRUB_DISK_SECTOR_SIZE - 1)), + & (data->disk->sector_size - 1)), sizeof (entry_v1_stat), (char *) &entry_v1_stat); if (grub_errno) goto fail; @@ -1041,10 +1041,10 @@ { struct grub_reiserfs_stat_item_v2 entry_v2_stat; grub_disk_read (data->disk, - block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + block_number * (block_size / data->disk->sector_size), entry_location + (((grub_off_t) block_number * block_size) - & (GRUB_DISK_SECTOR_SIZE - 1)), + & (data->disk->sector_size - 1)), sizeof (entry_v2_stat), (char *) &entry_v2_stat); if (grub_errno) goto fail; @@ -1111,7 +1111,7 @@ switch (found.type) { case GRUB_REISERFS_DIRECT: - block = found.block_number * (block_size >> GRUB_DISK_SECTOR_BITS); + block = found.block_number * (block_size / data->disk->sector_size); grub_dprintf ("reiserfs_blocktype", "D: %u\n", (unsigned) block); if (initial_position < current_position + item_size) { @@ -1143,7 +1143,7 @@ if (! indirect_block_ptr) goto fail; grub_disk_read (found.data->disk, - found.block_number * (block_size >> GRUB_DISK_SECTOR_BITS), + found.block_number * (block_size / found.data->disk->sector_size), grub_le_to_cpu16 (found.header.item_location), item_size, (char *) indirect_block_ptr); if (grub_errno) @@ -1155,7 +1155,7 @@ indirect_block++) { block = grub_le_to_cpu32 (indirect_block_ptr[indirect_block]) * - (block_size >> GRUB_DISK_SECTOR_BITS); + (block_size / found.data->disk->sector_size); grub_dprintf ("reiserfs_blocktype", "I: %u\n", (unsigned) block); if (current_position + block_size >= initial_position) { @@ -1334,7 +1334,7 @@ if (*label) { grub_disk_read (device->disk, - REISERFS_SUPER_BLOCK_OFFSET / GRUB_DISK_SECTOR_SIZE, + REISERFS_SUPER_BLOCK_OFFSET / device->disk->sector_size, REISERFS_LABEL_OFFSET, REISERFS_MAX_LABEL_LENGTH, *label); } Index: fs/jfs.c =================================================================== --- fs/jfs.c (revision 1886) +++ fs/jfs.c (working copy) @@ -276,9 +276,8 @@ } tree; if (grub_disk_read (data->disk, - grub_le_to_cpu32 (extents[found].extent.blk2) - << (grub_le_to_cpu16 (data->sblock.log2_blksz) - - GRUB_DISK_SECTOR_BITS), 0, + grub_divmod64(grub_le_to_cpu32 (extents[found].extent.blk2) + << (grub_le_to_cpu16 (data->sblock.log2_blksz)), data->disk->sector_size, NULL), 0, sizeof (tree), (char *) &tree)) return -1; @@ -309,14 +308,14 @@ /* Read in the IAG. */ if (grub_disk_read (data->disk, - iagblk << (grub_le_to_cpu16 (data->sblock.log2_blksz) - - GRUB_DISK_SECTOR_BITS), 0, + grub_divmod64 (iagblk << (grub_le_to_cpu16 (data->sblock.log2_blksz)), data->disk->sector_size, NULL), 0, sizeof (struct grub_jfs_iag), (char *) &iag)) return grub_errno; inoblk = grub_le_to_cpu32 (iag.inodes[inoext].blk2); - inoblk <<= (grub_le_to_cpu16 (data->sblock.log2_blksz) - - GRUB_DISK_SECTOR_BITS); + inoblk <<= (grub_le_to_cpu16 (data->sblock.log2_blksz)); + inoblk /= data->disk->sector_size; + inoblk += inonum; if (grub_disk_read (data->disk, inoblk, 0, @@ -412,7 +411,8 @@ } blk = grub_le_to_cpu32 (de[inode->dir.header.sorted[0]].ex.blk2); - blk <<= (grub_le_to_cpu16 (data->sblock.log2_blksz) - GRUB_DISK_SECTOR_BITS); + blk <<= (grub_le_to_cpu16 (data->sblock.log2_blksz)); + blk /= data->disk->sector_size; /* Read in the nodes until we are on the leaf node level. */ do @@ -430,8 +430,7 @@ de = (struct grub_jfs_internal_dirent *) diro->dirpage->dirent; index = diro->dirpage->sorted[diro->dirpage->header.sindex * 32]; blk = (grub_le_to_cpu32 (de[index].ex.blk2) - << (grub_le_to_cpu16 (data->sblock.log2_blksz) - - GRUB_DISK_SECTOR_BITS)); + << (grub_le_to_cpu16 (data->sblock.log2_blksz)) * data->disk->sector_size); } while (!(diro->dirpage->header.flags & GRUB_JFS_TREE_LEAF)); diro->leaf = diro->dirpage->dirent; @@ -485,8 +484,8 @@ return GRUB_ERR_OUT_OF_RANGE; next = grub_le_to_cpu64 (diro->dirpage->header.nextb); - next <<= (grub_le_to_cpu16 (diro->data->sblock.log2_blksz) - - GRUB_DISK_SECTOR_BITS); + next <<= (grub_le_to_cpu16 (diro->data->sblock.log2_blksz)); + next /= diro->data->disk->sector_size; if (grub_disk_read (diro->data->disk, next, 0, grub_le_to_cpu32 (diro->data->sblock.blksz), @@ -583,8 +582,7 @@ data->disk->read_hook = read_hook; grub_disk_read (data->disk, - blknr << (grub_le_to_cpu16 (data->sblock.log2_blksz) - - GRUB_DISK_SECTOR_BITS), + blknr << (grub_le_to_cpu16 (data->sblock.log2_blksz)) * data->disk->sector_size, skipfirst, blockend, buf); data->disk->read_hook = 0; Index: fs/ext2.c =================================================================== --- fs/ext2.c (revision 1886) +++ fs/ext2.c (working copy) @@ -495,8 +495,8 @@ if (!data) return 0; - /* Read the superblock. */ - grub_disk_read (disk, 1 * 2, 0, sizeof (struct grub_ext2_sblock), + /* Read the superblock. from address 1024 instead of some sector! */ + grub_disk_read (disk, 0, 1024, sizeof (struct grub_ext2_sblock), (char *) &data->sblock); if (grub_errno) goto fail; Index: fs/minix.c =================================================================== --- fs/minix.c (revision 1886) +++ fs/minix.c (working copy) @@ -263,8 +263,8 @@ if (data->version == 1) { - block += ino / (GRUB_DISK_SECTOR_SIZE / sizeof (struct grub_minix_inode)); - int offs = (ino % (GRUB_DISK_SECTOR_SIZE + block += ino / (data->disk->sector_size / sizeof (struct grub_minix_inode)); + int offs = (ino % (data->disk->sector_size / sizeof (struct grub_minix_inode)) * sizeof (struct grub_minix_inode)); @@ -273,10 +273,10 @@ } else { - block += ino / (GRUB_DISK_SECTOR_SIZE + block += ino / (data->disk->sector_size / sizeof (struct grub_minix2_inode)); int offs = (ino - % (GRUB_DISK_SECTOR_SIZE / sizeof (struct grub_minix2_inode)) + % (data->disk->sector_size / sizeof (struct grub_minix2_inode)) * sizeof (struct grub_minix2_inode)); grub_disk_read (data->disk, block, offs, Index: fs/hfsplus.c =================================================================== --- fs/hfsplus.c (revision 1886) +++ fs/hfsplus.c (working copy) @@ -224,7 +224,6 @@ static grub_dl_t my_mod; #endif - /* Return the offset of the record with the index INDEX, in the node NODE which is part of the B+ tree BTREE. */ static inline unsigned int @@ -309,8 +308,7 @@ if (blk != -1) return (blk - + (node->data->embedded_offset >> (node->data->log2blksize - - GRUB_DISK_SECTOR_BITS))); + + (node->data->embedded_offset * node->data->disk->sector_size) >> (node->data->log2blksize)); /* For the extent overflow file, extra extents can't be found in the extent overflow file. If this happens, you found a @@ -360,10 +358,11 @@ unsigned offset, unsigned length), int pos, grub_size_t len, char *buf) { +// TODO: Thinks of some nice way for log2 here... return grub_fshelp_read_file (node->data->disk, node, read_hook, pos, len, buf, grub_hfsplus_read_block, node->size, - node->data->log2blksize - GRUB_DISK_SECTOR_BITS); + node->data->log2blksize - fat_log2 (node->data->disk->sector_size)); } static struct grub_hfsplus_data * @@ -409,7 +408,7 @@ ablk_start = grub_be_to_cpu16 (volheader.hfs.first_block); data->embedded_offset = (ablk_start + extent_start - * (ablk_size >> GRUB_DISK_SECTOR_BITS)); + * (ablk_size / data->disk->sector_size)); grub_disk_read (disk, data->embedded_offset + GRUB_HFSPLUS_SBLOCK, 0, sizeof (volheader), (char *) &volheader); Index: fs/cpio.c =================================================================== --- fs/cpio.c (revision 1886) +++ fs/cpio.c (working copy) @@ -145,9 +145,9 @@ return grub_errno; data->size = grub_strtoul (hd.size, NULL, 8); - data->dofs = data->hofs + GRUB_DISK_SECTOR_SIZE; - *ofs = data->dofs + ((data->size + GRUB_DISK_SECTOR_SIZE - 1) & - ~(GRUB_DISK_SECTOR_SIZE - 1)); + data->dofs = data->hofs + data->disk->sector_size; + *ofs = data->dofs + ((data->size + data->disk->sector_size - 1) & + ~(data->disk->sector_size - 1)); } return GRUB_ERR_NONE; } Index: include/grub/ntfs.h =================================================================== --- include/grub/ntfs.h (revision 1886) +++ include/grub/ntfs.h (working copy) @@ -67,7 +67,9 @@ #define FLAG_ENCRYPTED 0x4000 #define FLAG_SPARSE 0x8000 -#define BLK_SHR GRUB_DISK_SECTOR_BITS +// TODO: This is quite bad, was GRUB_DISK_SECTOR_BITS (whch in turn was 9 for 512 Byte/Sector disks) +// Check if this is ok on devices with different sector sizes +#define BLK_SHR 9 #define MAX_MFT (1024 >> BLK_SHR) #define MAX_IDX (16384 >> BLK_SHR) Index: include/grub/disk.h =================================================================== --- include/grub/disk.h (revision 1886) +++ include/grub/disk.h (working copy) @@ -94,6 +94,9 @@ /* The underlying disk device. */ grub_disk_dev_t dev; + /* The size of each sector. */ + grub_uint32_t sector_size; + /* The total number of sectors. */ grub_uint64_t total_sectors; @@ -125,9 +128,9 @@ typedef struct grub_disk_memberlist *grub_disk_memberlist_t; #endif -/* The sector size. */ -#define GRUB_DISK_SECTOR_SIZE 0x200 -#define GRUB_DISK_SECTOR_BITS 9 +/* The sector size is now contained in grub_disk structure */ +//#define GRUB_DISK_SECTOR_SIZE 512 +//#define GRUB_DISK_SECTOR_BITS 9 /* The maximum number of disk caches. */ #define GRUB_DISK_CACHE_NUM 1021 Index: include/grub/lvm.h =================================================================== --- include/grub/lvm.h (revision 1886) +++ include/grub/lvm.h (working copy) @@ -65,7 +65,8 @@ struct grub_lvm_pv *pv; }; -#define GRUB_LVM_LABEL_SIZE GRUB_DISK_SECTOR_SIZE +// TODO: Check if LVM_LABEL_SIZE is 1 sector or 512 Bytes and change code accordingly +#define GRUB_LVM_LABEL_SIZE 512 #define GRUB_LVM_LABEL_SCAN_SECTORS 4L #define GRUB_LVM_LABEL_ID "LABELONE" Index: commands/crc.c =================================================================== --- commands/crc.c (revision 1886) +++ commands/crc.c (working copy) @@ -24,6 +24,7 @@ #include #include #include +#include static grub_err_t grub_cmd_crc (struct grub_arg_list *state __attribute__ ((unused)), @@ -31,7 +32,7 @@ { grub_file_t file; - char buf[GRUB_DISK_SECTOR_SIZE]; + char buf[GRUB_CMD_CHUNK_SIZE]; grub_ssize_t size; grub_uint32_t crc; Index: commands/cat.c =================================================================== --- commands/cat.c (revision 1886) +++ commands/cat.c (working copy) @@ -31,8 +31,9 @@ int argc, char **args) { +#define GRUB_CMD_CAT_CHUNK_SIZE 512 grub_file_t file; - char buf[GRUB_DISK_SECTOR_SIZE]; + char buf[GRUB_CMD_CAT_CHUNK_SIZE]; grub_ssize_t size; int key = 0; Index: commands/hexdump.c =================================================================== --- commands/hexdump.c (revision 1886) +++ commands/hexdump.c (working copy) @@ -26,6 +26,8 @@ #include #include #include +#include +#include static const struct grub_arg_option options[] = { {"skip", 's', 0, "skip offset bytes from the beginning of file.", 0, @@ -37,7 +39,8 @@ static grub_err_t grub_cmd_hexdump (struct grub_arg_list *state, int argc, char **args) { - char buf[GRUB_DISK_SECTOR_SIZE * 4]; + // we can not use GRUB_CMD_CHUNK_SIZE here since we want to directly read from the device + char *buf; grub_ssize_t size, length; grub_addr_t skip; int namelen; @@ -63,10 +66,14 @@ return 0; if (disk->partition) - skip += grub_partition_get_start (disk->partition) << GRUB_DISK_SECTOR_BITS; + skip += grub_partition_get_start (disk->partition) * disk->sector_size; - sector = (skip >> (GRUB_DISK_SECTOR_BITS + 2)) * 4; - ofs = skip & (GRUB_DISK_SECTOR_SIZE * 4 - 1); + // we are going to read directly from disk, so take a whole sector! + // TODO: Why not use grub_disk_read which can handle also smaller and bigger chunks + buf = grub_malloc (disk->sector_size); + + sector = (grub_divmod64(skip, disk->sector_size, 0) >> 2) * 4; + ofs = skip & (disk->sector_size * 4 - 1); while (length) { grub_size_t len, n; @@ -75,8 +82,8 @@ if (ofs + len > sizeof (buf)) len = sizeof (buf) - ofs; - n = ((ofs + len + GRUB_DISK_SECTOR_SIZE - 1) - >> GRUB_DISK_SECTOR_BITS); + n = grub_divmod64((ofs + len + disk->sector_size - 1), + disk->sector_size, 0); if (disk->dev->read (disk, sector, n, buf)) break; @@ -89,6 +96,7 @@ } grub_disk_close (disk); + grub_free (buf); } else { @@ -99,8 +107,10 @@ return 0; file->offset = skip; + // here the size of the buffer does not matter since we use file access + buf = grub_malloc (GRUB_CMD_CHUNK_SIZE); - while ((size = grub_file_read (file, buf, sizeof (buf))) > 0) + while ((size = grub_file_read (file, buf, GRUB_CMD_CHUNK_SIZE)) > 0) { unsigned long len; @@ -116,6 +126,7 @@ } grub_file_close (file); + grub_free (buf); } return 0; Index: commands/blocklist.c =================================================================== --- commands/blocklist.c (revision 1886) +++ commands/blocklist.c (working copy) @@ -31,7 +31,7 @@ int argc, char **args) { grub_file_t file; - char buf[GRUB_DISK_SECTOR_SIZE]; + char *buf; unsigned long start_sector = 0; unsigned num_sectors = 0; int num_entries = 0; @@ -47,7 +47,7 @@ if (num_sectors > 0) { if (start_sector + num_sectors == sector - && offset == 0 && length == GRUB_DISK_SECTOR_SIZE) + && offset == 0 && length == file->device->disk->sector_size) { num_sectors++; return; @@ -57,7 +57,7 @@ num_sectors = 0; } - if (offset == 0 && length == GRUB_DISK_SECTOR_SIZE) + if (offset == 0 && length == file->device->disk->sector_size) { start_sector = sector; num_sectors++; @@ -90,6 +90,8 @@ return grub_error (GRUB_ERR_BAD_DEVICE, "this command is available only for disk devices."); + buf = grub_malloc (file->device->disk->sector_size); + if (file->device->disk->partition) part_start = grub_partition_get_start (file->device->disk->partition); @@ -103,6 +105,7 @@ grub_file_close (file); + grub_free (buf); return grub_errno; } Index: commands/loadenv.c =================================================================== --- commands/loadenv.c (revision 1886) +++ commands/loadenv.c (working copy) @@ -157,8 +157,8 @@ { grub_file_t file; grub_disk_t disk; - grub_disk_addr_t addr[GRUB_ENVBLK_MAXLEN >> GRUB_DISK_SECTOR_BITS]; - char buf[GRUB_DISK_SECTOR_SIZE]; + grub_disk_addr_t *addr; + char *buf; grub_disk_addr_t part_start = 0; int num = 0; @@ -168,10 +168,10 @@ void NESTED_FUNC_ATTR hook (grub_disk_addr_t sector, unsigned offset, unsigned length) { - if ((offset != 0) || (length != GRUB_DISK_SECTOR_SIZE)) + if ((offset != 0) || (length != disk->sector_size)) return; - if (num < (GRUB_ENVBLK_MAXLEN >> GRUB_DISK_SECTOR_BITS)) + if (num < (GRUB_ENVBLK_MAXLEN / disk->sector_size)) addr[num++] = sector; } @@ -184,7 +184,7 @@ file->read_hook = 0; - if (num != GRUB_ENVBLK_MAXLEN >> GRUB_DISK_SECTOR_BITS) + if (num != GRUB_ENVBLK_MAXLEN / disk->sector_size) { grub_error (GRUB_ERR_BAD_DEVICE, "invalid blocklist"); goto quit; @@ -194,14 +194,17 @@ if (disk->partition) part_start = grub_partition_get_start (disk->partition); - for (num = 0; num < (GRUB_ENVBLK_MAXLEN >> GRUB_DISK_SECTOR_BITS); num++) + buf = grub_malloc (disk->sector_size); + addr = grub_malloc (sizeof (*addr) * GRUB_ENVBLK_MAXLEN / disk->sector_size); + + for (num = 0; num < (GRUB_ENVBLK_MAXLEN / disk->sector_size); num++) { if (grub_disk_read (disk, addr[num] - part_start, 0, - GRUB_DISK_SECTOR_SIZE, buf)) + disk->sector_size, buf)) goto quit; - if (grub_memcmp (&buffer[num << GRUB_DISK_SECTOR_BITS], buf, - GRUB_DISK_SECTOR_SIZE)) + if (grub_memcmp (&buffer[num * disk->sector_size], buf, + disk->sector_size)) { grub_error (GRUB_ERR_BAD_DEVICE, "invalid blocklist"); goto quit; @@ -226,14 +229,16 @@ args++; } - for (num = 0; num < (GRUB_ENVBLK_MAXLEN >> GRUB_DISK_SECTOR_BITS); num++) + for (num = 0; num < (GRUB_ENVBLK_MAXLEN / disk->sector_size); num++) if (grub_disk_write (disk, addr[num] - part_start, 0, - GRUB_DISK_SECTOR_SIZE, - &buffer[num << GRUB_DISK_SECTOR_BITS])) + disk->sector_size, + &buffer[num * disk->sector_size])) goto quit; quit: grub_file_close (file); + grub_free (buf); + grub_free (addr); return grub_errno; } Index: partmap/apple.c =================================================================== --- partmap/apple.c (revision 1886) +++ partmap/apple.c (working copy) @@ -110,7 +110,7 @@ struct grub_apple_part apart; struct grub_disk raw; int partno = 0; - unsigned pos = GRUB_DISK_SECTOR_SIZE; + unsigned pos = disk->sector_size; /* Enforce raw disk access. */ raw = *disk; @@ -132,8 +132,8 @@ for (;;) { - if (grub_disk_read (&raw, pos / GRUB_DISK_SECTOR_SIZE, - pos % GRUB_DISK_SECTOR_SIZE, + if (grub_disk_read (&raw, pos / disk->sector_size, + pos % disk->sector_size, sizeof (struct grub_apple_part), (char *) &apart)) return grub_errno; @@ -161,14 +161,14 @@ return grub_errno; if (grub_be_to_cpu32 (apart.first_phys_block) - == GRUB_DISK_SECTOR_SIZE * 2) + == disk->sector_size * 2) return 0; pos += sizeof (struct grub_apple_part); partno++; } - if (pos != GRUB_DISK_SECTOR_SIZE) + if (pos != disk->sector_size) return 0; fail: Index: partmap/acorn.c =================================================================== --- partmap/acorn.c (revision 1886) +++ partmap/acorn.c (working copy) @@ -59,7 +59,7 @@ unsigned int sectors_per_cylinder; int i; - err = grub_disk_read (disk, 0xC00 / GRUB_DISK_SECTOR_SIZE, 0, + err = grub_disk_read (disk, 0xC00 / disk->sector_size, 0, sizeof (struct grub_acorn_boot_block), (char *) &boot); if (err) Index: partmap/gpt.c =================================================================== --- partmap/gpt.c (revision 1886) +++ partmap/gpt.c (working copy) @@ -107,7 +107,7 @@ } last_offset += grub_le_to_cpu32 (gpt.partentry_size); - if (last_offset == GRUB_DISK_SECTOR_SIZE) + if (last_offset == disk->sector_size) { last_offset = 0; entries++; Index: loader/i386/pc/linux.c =================================================================== --- loader/i386/pc/linux.c (revision 1886) +++ loader/i386/pc/linux.c (working copy) @@ -143,8 +143,8 @@ if (! setup_sects) setup_sects = GRUB_LINUX_DEFAULT_SETUP_SECTS; - real_size = setup_sects << GRUB_DISK_SECTOR_BITS; - prot_size = grub_file_size (file) - real_size - GRUB_DISK_SECTOR_SIZE; + real_size = setup_sects * file->device->disk->sector_size; + prot_size = grub_file_size (file) - real_size - file->device->disk->sector_size; grub_linux_tmp_addr = (char *) GRUB_LINUX_BZIMAGE_ADDR + prot_size; @@ -229,7 +229,7 @@ /* Put the real mode code at the temporary address. */ grub_memmove (grub_linux_tmp_addr, &lh, sizeof (lh)); - len = real_size + GRUB_DISK_SECTOR_SIZE - sizeof (lh); + len = real_size + file->device->disk->sector_size - sizeof (lh); if (grub_file_read (file, grub_linux_tmp_addr + sizeof (lh), len) != len) { grub_error (GRUB_ERR_FILE_READ_ERROR, "Couldn't read file"); @@ -240,10 +240,10 @@ || grub_le_to_cpu16 (lh.version) < 0x0200) /* Clear the heap space. */ grub_memset (grub_linux_tmp_addr - + ((setup_sects + 1) << GRUB_DISK_SECTOR_BITS), + + ((setup_sects + 1) * file->device->disk->sector_size), 0, ((GRUB_LINUX_MAX_SETUP_SECTS - setup_sects - 1) - << GRUB_DISK_SECTOR_BITS)); + * file->device->disk->sector_size)); /* Specify the boot file. */ dest = grub_stpcpy (grub_linux_tmp_addr + GRUB_LINUX_CL_OFFSET, Index: loader/i386/pc/chainloader.c =================================================================== --- loader/i386/pc/chainloader.c (revision 1886) +++ loader/i386/pc/chainloader.c (working copy) @@ -63,32 +63,9 @@ grub_dl_ref (my_mod); - file = grub_file_open (filename); - if (! file) - goto fail; - /* Read the first block. */ - if (grub_file_read (file, (char *) 0x7C00, GRUB_DISK_SECTOR_SIZE) - != GRUB_DISK_SECTOR_SIZE) - { - if (grub_errno == GRUB_ERR_NONE) - grub_error (GRUB_ERR_BAD_OS, "too small"); - - goto fail; - } - - /* Check the signature. */ - signature = *((grub_uint16_t *) (0x7C00 + GRUB_DISK_SECTOR_SIZE - 2)); - if (signature != grub_le_to_cpu16 (0xaa55) - && ! (flags & GRUB_CHAINLOADER_FORCE)) - { - grub_error (GRUB_ERR_BAD_OS, "invalid signature"); - goto fail; - } - - grub_file_close (file); - - /* Obtain the partition table from the root device. */ + /* Obtain the partition table from the root device. we have to open the + device in order to get the sector size */ dev = grub_device_open (0); if (dev) { @@ -96,6 +73,35 @@ if (disk) { + file = grub_file_open (filename); + if (! file) + { + goto fail; + grub_device_close (dev); + } + + /* Read the first block. */ + if (grub_file_read (file, (char *) 0x7C00, disk->sector_size) + != disk->sector_size) + { + if (grub_errno == GRUB_ERR_NONE) + grub_error (GRUB_ERR_BAD_OS, "too small"); + grub_device_close (dev); + goto fail; + } + + /* Check the signature. */ + signature = *((grub_uint16_t *) (0x7C00 + disk->sector_size - 2)); + if (signature != grub_le_to_cpu16 (0xaa55) + && ! (flags & GRUB_CHAINLOADER_FORCE)) + { + grub_error (GRUB_ERR_BAD_OS, "invalid signature"); + grub_device_close (dev); + goto fail; + } + + grub_file_close (file); + grub_partition_t p = disk->partition; /* In i386-pc, the id is equal to the BIOS drive number. */ Index: geninit.sh =================================================================== --- geninit.sh (revision 1886) +++ geninit.sh (working copy) @@ -49,7 +49,7 @@ while read line; do file=`echo $line | cut -f1 -d:` if echo $@ | grep $file >/dev/null; then - echo $line | sed -e 's/.*GRUB_MOD_INIT *(\([a-zA-Z0-9_]*\)).*/ grub_\1_init ();/' + echo $line | sed -e 's/.*GRUB_MOD_INIT *(\([a-zA-Z0-9_]*\)).*/ grub_\1_init (); grub_util_info ("\1");/' fi done < ${lst} Index: util/grub-probe.c =================================================================== --- util/grub-probe.c (revision 1886) +++ util/grub-probe.c (working copy) @@ -112,18 +112,32 @@ int abstraction_type; grub_device_t dev = NULL; grub_fs_t fs; + + grub_util_info ("starting probe..."); + if (path != NULL) grub_util_info ("path = %s.", path); + if (device_name != NULL) grub_util_info ("device_name = %s", device_name); if (path == NULL) { - if (! grub_util_check_block_device (device_name)) + if (! grub_util_check_block_device (device_name)) { + grub_util_info ("2"); grub_util_error ("%s is not a block device.\n", device_name); + } } - else + else { + grub_util_info ("3"); device_name = grub_guess_root_device (path); + } + grub_util_info ("1"); + if (path != NULL) grub_util_info ("path = %s.", path); + if (device_name != NULL) grub_util_info ("device_name = %s", device_name); + if (! device_name) grub_util_error ("cannot find a device for %s.\n", path); + grub_util_info ("2"); + if (print == PRINT_DEVICE) { printf ("%s\n", device_name); @@ -165,7 +179,7 @@ grub_util_info ("opening %s", drive_name); dev = grub_device_open (drive_name); if (! dev) - grub_util_error ("%s", grub_errmsg); + grub_util_error ("grub_device_open failed: %s", grub_errmsg); if (print == PRINT_PARTMAP) { @@ -358,22 +372,32 @@ } argument = argv[optind]; + + grub_util_info ("arguments parsed."); /* Initialize the emulated biosdisk driver. */ grub_util_biosdisk_init (dev_map ? : DEFAULT_DEVICE_MAP); + + grub_util_info ("biosdisk initialized"); /* Initialize all modules. */ grub_init_all (); + grub_util_info ("all modules initialized"); + /* Do it. */ if (argument_is_device) probe (NULL, argument); else probe (argument, NULL); + + grub_util_info ("probe executed"); /* Free resources. */ grub_fini_all (); grub_util_biosdisk_fini (); + + grub_util_info ("all modules deinitialized"); free (dev_map); Index: util/i386/pc/grub-mkimage.c =================================================================== --- util/i386/pc/grub-mkimage.c (revision 1886) +++ util/i386/pc/grub-mkimage.c (working copy) @@ -129,7 +129,7 @@ #endif static void -generate_image (const char *dir, char *prefix, FILE *out, char *mods[], char *memdisk_path) +generate_image (const char *dir, char *prefix, FILE *out, char *mods[], char *memdisk_path, grub_uint32_t target_sector_size) { grub_addr_t module_addr = 0; char *kernel_img, *boot_img, *core_img; @@ -208,19 +208,19 @@ grub_util_info ("the core size is 0x%x", core_size); - num = ((core_size + GRUB_DISK_SECTOR_SIZE - 1) >> GRUB_DISK_SECTOR_BITS); + num = ((core_size + target_sector_size - 1) / target_sector_size); if (num > 0xffff) grub_util_error ("the core image is too big"); boot_path = grub_util_get_path (dir, "diskboot.img"); boot_size = grub_util_get_image_size (boot_path); - if (boot_size != GRUB_DISK_SECTOR_SIZE) + if (boot_size >= target_sector_size) grub_util_error ("diskboot.img is not one sector size"); boot_img = grub_util_read_image (boot_path); /* i386 is a little endian architecture. */ - *((grub_uint16_t *) (boot_img + GRUB_DISK_SECTOR_SIZE + *((grub_uint16_t *) (boot_img + target_sector_size - GRUB_BOOT_MACHINE_LIST_SIZE + 8)) = grub_cpu_to_le16 (num); @@ -229,7 +229,7 @@ free (boot_path); module_addr = (path_list - ? (GRUB_BOOT_MACHINE_KERNEL_ADDR + GRUB_DISK_SECTOR_SIZE + ? (GRUB_BOOT_MACHINE_KERNEL_ADDR + target_sector_size + kernel_size) : 0); @@ -280,6 +280,7 @@ {"help", no_argument, 0, 'h'}, {"version", no_argument, 0, 'V'}, {"verbose", no_argument, 0, 'v'}, + {"sector-size", required_argument, 0, 's'}, {0, 0, 0, 0} }; @@ -301,6 +302,7 @@ -h, --help display this message and exit\n\ -V, --version print version information and exit\n\ -v, --verbose print verbose messages\n\ + -s, --sector-size=NR set sector size to NR bytes\n\ \n\ Report bugs to <%s>.\n\ ", GRUB_LIBDIR, DEFAULT_DIRECTORY, PACKAGE_BUGREPORT); @@ -316,6 +318,7 @@ char *prefix = NULL; char *memdisk = NULL; FILE *fp = stdout; + grub_uint32_t target_sector_size = 0; progname = "grub-mkimage"; @@ -372,6 +375,10 @@ case 'v': verbosity++; break; + + case 's': + target_sector_size = atoi (optarg); + break; default: usage (1); @@ -386,8 +393,15 @@ grub_util_error ("cannot open %s", output); } - generate_image (dir ? : GRUB_LIBDIR, prefix ? : DEFAULT_DIRECTORY, fp, argv + optind, memdisk); + if (target_sector_size == 0) + { + printf ("invalid sector size given!"); + usage (1); + } + + generate_image (dir ? : GRUB_LIBDIR, prefix ? : DEFAULT_DIRECTORY, fp, argv + optind, memdisk, target_sector_size); + fclose (fp); if (dir) Index: util/i386/pc/grub-setup.c =================================================================== --- util/i386/pc/grub-setup.c (revision 1886) +++ util/i386/pc/grub-setup.c (working copy) @@ -105,9 +105,8 @@ char *tmp_img; int i; grub_disk_addr_t first_sector; - grub_uint16_t current_segment - = GRUB_BOOT_MACHINE_KERNEL_SEG + (GRUB_DISK_SECTOR_SIZE >> 4); - grub_uint16_t last_length = GRUB_DISK_SECTOR_SIZE; + grub_uint16_t current_segment; + grub_uint16_t last_length = 0; grub_file_t file; FILE *fp; struct { grub_uint64_t start; grub_uint64_t end; } embed_region; @@ -160,7 +159,7 @@ grub_util_info ("the first sector is <%llu,%u,%u>", sector, offset, length); - if (offset != 0 || length != GRUB_DISK_SECTOR_SIZE) + if (offset != 0 || length != dest_dev->disk->sector_size) grub_util_error ("The first sector of the core file is not sector-aligned"); first_sector = sector; @@ -174,7 +173,7 @@ grub_util_info ("saving <%llu,%u,%u> with the segment 0x%x", sector, offset, length, (unsigned) current_segment); - if (offset != 0 || last_length != GRUB_DISK_SECTOR_SIZE) + if (offset != 0 || last_length != dest_dev->disk->sector_size) grub_util_error ("Non-sector-aligned data is found in the core file"); if (block != first_block @@ -193,15 +192,25 @@ } last_length = length; - current_segment += GRUB_DISK_SECTOR_SIZE >> 4; + current_segment += dest_dev->disk->sector_size >> 4; } - + + /* Open the destination device and read sector size (automagically done by grub_device_open)*/ + dest_dev = grub_device_open (dest); + if (! dest_dev) + grub_util_error ("%s", grub_errmsg); + + /* initialize sector-size dependant variables */ + last_length = dest_dev->disk->sector_size; + current_segment = GRUB_BOOT_MACHINE_KERNEL_SEG + (dest_dev->disk->sector_size >> 4); + /* Read the boot image by the OS service. */ boot_path = grub_util_get_path (dir, boot_file); boot_size = grub_util_get_image_size (boot_path); - if (boot_size != GRUB_DISK_SECTOR_SIZE) - grub_util_error ("The size of `%s' is not %d", - boot_path, GRUB_DISK_SECTOR_SIZE); + if (boot_size != dest_dev->disk->sector_size) + grub_util_error ("The size of `%s' is not %d, you should adapt the image sector size to the" \ + "sector size of the target block device.", + boot_path, dest_dev->disk->sector_size); boot_img = grub_util_read_image (boot_path); free (boot_path); @@ -215,23 +224,23 @@ core_path = grub_util_get_path (dir, core_file); core_size = grub_util_get_image_size (core_path); - core_sectors = ((core_size + GRUB_DISK_SECTOR_SIZE - 1) - >> GRUB_DISK_SECTOR_BITS); - if (core_size < GRUB_DISK_SECTOR_SIZE) + core_sectors = ((core_size + dest_dev->disk->sector_size - 1) + / dest_dev->disk->sector_size); + if (core_size < dest_dev->disk->sector_size) grub_util_error ("The size of `%s' is too small", core_path); - else if (core_size > 0xFFFF * GRUB_DISK_SECTOR_SIZE) + else if (core_size > 0xFFFF * dest_dev->disk->sector_size) grub_util_error ("The size of `%s' is too large", core_path); core_img = grub_util_read_image (core_path); /* Have FIRST_BLOCK to point to the first blocklist. */ first_block = (struct boot_blocklist *) (core_img - + GRUB_DISK_SECTOR_SIZE + + dest_dev->disk->sector_size - sizeof (*block)); - install_dos_part = (grub_int32_t *) (core_img + GRUB_DISK_SECTOR_SIZE + install_dos_part = (grub_int32_t *) (core_img + dest_dev->disk->sector_size + GRUB_KERNEL_MACHINE_INSTALL_DOS_PART); - install_bsd_part = (grub_int32_t *) (core_img + GRUB_DISK_SECTOR_SIZE + install_bsd_part = (grub_int32_t *) (core_img + dest_dev->disk->sector_size + GRUB_KERNEL_MACHINE_INSTALL_BSD_PART); /* Open the root device and the destination device. */ @@ -239,17 +248,13 @@ if (! root_dev) grub_util_error ("%s", grub_errmsg); - dest_dev = grub_device_open (dest); - if (! dest_dev) - grub_util_error ("%s", grub_errmsg); - grub_util_info ("setting the root device to `%s'", root); if (grub_env_set ("root", root) != GRUB_ERR_NONE) grub_util_error ("%s", grub_errmsg); /* Read the original sector from the disk. */ - tmp_img = xmalloc (GRUB_DISK_SECTOR_SIZE); - if (grub_disk_read (dest_dev->disk, 0, 0, GRUB_DISK_SECTOR_SIZE, tmp_img)) + tmp_img = xmalloc (dest_dev->disk->sector_size); + if (grub_disk_read (dest_dev->disk, 0, 0, dest_dev->disk->sector_size, tmp_img)) grub_util_error ("%s", grub_errmsg); /* Copy the possible DOS BPB. */ @@ -327,7 +332,7 @@ first_block->len = grub_cpu_to_le16 (core_sectors - 1); first_block->segment = grub_cpu_to_le16 (GRUB_BOOT_MACHINE_KERNEL_SEG - + (GRUB_DISK_SECTOR_SIZE >> 4)); + + (dest_dev->disk->sector_size >> 4)); /* Make sure that the second blocklist is a terminator. */ block = first_block - 1; @@ -346,7 +351,7 @@ *kernel_sector = grub_cpu_to_le64 (embed_region.start); /* Write the boot image onto the disk. */ - if (grub_disk_write (dest_dev->disk, 0, 0, GRUB_DISK_SECTOR_SIZE, + if (grub_disk_write (dest_dev->disk, 0, 0, dest_dev->disk->sector_size, boot_img)) grub_util_error ("%s", grub_errmsg); @@ -457,14 +462,14 @@ grub_util_error ("%s", grub_errmsg); file->read_hook = save_first_sector; - if (grub_file_read (file, tmp_img, GRUB_DISK_SECTOR_SIZE) - != GRUB_DISK_SECTOR_SIZE) + if (grub_file_read (file, tmp_img, dest_dev->disk->sector_size) + != dest_dev->disk->sector_size) grub_util_error ("Failed to read the first sector of the core image"); block = first_block; file->read_hook = save_blocklists; - if (grub_file_read (file, tmp_img, core_size - GRUB_DISK_SECTOR_SIZE) - != (grub_ssize_t) core_size - GRUB_DISK_SECTOR_SIZE) + if (grub_file_read (file, tmp_img, core_size - dest_dev->disk->sector_size) + != (grub_ssize_t) core_size - dest_dev->disk->sector_size) grub_util_error ("Failed to read the rest sectors of the core image"); grub_file_close (file); @@ -487,11 +492,11 @@ if (! fp) grub_util_error ("Cannot open `%s'", core_path); - grub_util_write_image (core_img, GRUB_DISK_SECTOR_SIZE * 2, fp); + grub_util_write_image (core_img, dest_dev->disk->sector_size * 2, fp); fclose (fp); /* Write the boot image onto the disk. */ - if (grub_disk_write (dest_dev->disk, 0, 0, GRUB_DISK_SECTOR_SIZE, boot_img)) + if (grub_disk_write (dest_dev->disk, 0, 0, dest_dev->disk->sector_size, boot_img)) grub_util_error ("%s", grub_errmsg); finish: Index: util/grub-mkdevicemap.c =================================================================== --- util/grub-mkdevicemap.c (revision 1886) +++ util/grub-mkdevicemap.c (working copy) @@ -70,6 +70,9 @@ # ifndef BLKGETSIZE # define BLKGETSIZE _IO(0x12,96) /* return device size */ # endif /* ! BLKGETSIZE */ +# ifndef BLKSSZGET +# define BLKSSZGET _IO(0x12,104)/* get block device sector size */ +#endif #endif /* __linux__ */ /* Use __FreeBSD_kernel__ instead of __FreeBSD__ for compatibility with @@ -328,7 +331,7 @@ static int check_device (const char *device) { - char buf[512]; + char *buf; FILE *fp; /* If DEVICE is empty, just return error. */ @@ -393,12 +396,20 @@ #endif /* __FreeBSD_kernel__ || __NetBSD__ || __OpenBSD__ */ /* Attempt to read the first sector. */ - if (fread (buf, 1, 512, fp) != 512) + grub_uint32_t size; + if (ioctl (fileno (fp), BLKSSZGET, &size)) { + grub_util_info ("can not get sector size for %s, assuming 512Bytes (non fatal).", device); + size = 512; + } + buf = grub_malloc( size ); + if (fread (buf, 1, size, fp) != size) + { + free (buf); fclose (fp); return 0; } - + free (buf); fclose (fp); return 1; } Index: util/hostdisk.c =================================================================== --- util/hostdisk.c (revision 1886) +++ util/hostdisk.c (working copy) @@ -64,6 +64,9 @@ # ifndef BLKGETSIZE64 # define BLKGETSIZE64 _IOR(0x12,114,size_t) /* return device size */ # endif /* ! BLKGETSIZE64 */ +# ifndef BLKSSZGET +# define BLKSSZGET _IO(0x12,104)/* get block device sector size */ +#endif # ifndef MAJOR # ifndef MINORBITS # define MINORBITS 8 @@ -170,10 +173,14 @@ size = grub_util_get_disk_size (map[drive].device); - if (size % 512) +// TODO: find correct sector size for mingw32 + grub_util_info ("compiled with mingw32, assuming 512 byte sector size!"); + disk->sector_size = 512; + + if (size % disk->sector_size) grub_util_error ("unaligned device size"); - disk->total_sectors = size >> 9; + disk->total_sectors = grub_divmod64 (size, disk->sector_size, NULL); grub_util_info ("the size of %s is %llu", name, disk->total_sectors); @@ -194,6 +201,13 @@ goto fail; } + if (ioctl (fd, BLKSSZGET, &nr)) + { + close (fd); + goto fail; + } + disk->sector_size = nr; + if (ioctl (fd, BLKGETSIZE64, &nr)) { close (fd); @@ -201,12 +215,12 @@ } close (fd); - disk->total_sectors = nr / 512; + disk->total_sectors = grub_divmod64 (nr, disk->sector_size, NULL); - if (nr % 512) + if (nr % disk->sector_size) grub_util_error ("unaligned device size"); - grub_util_info ("the size of %s is %llu", name, disk->total_sectors); + grub_util_info ("the size of %s is %llu with sector size %iu", name, disk->total_sectors, disk->sector_size); return GRUB_ERR_NONE; } @@ -215,15 +229,19 @@ /* In GNU/Hurd, stat() will return the right size. */ #elif !defined (__GNU__) # warning "No special routine to get the size of a block device is implemented for your OS. This is not possibly fatal." +# warning "No routine for getting sector size is implemented, assuming 512 bytes." + disk->sector_size = 512; #endif - if (stat (map[drive].device, &st) < 0) - return grub_error (GRUB_ERR_BAD_DEVICE, "cannot stat `%s'", map[drive].device); + { + if (stat (map[drive].device, &st) < 0) + return grub_error (GRUB_ERR_BAD_DEVICE, "cannot stat `%s'", map[drive].device); - disk->total_sectors = st.st_size >> GRUB_DISK_SECTOR_BITS; + disk->total_sectors = grub_divmod64 (st.st_size, disk->sector_size, NULL); - grub_util_info ("the size of %s is %lu", name, disk->total_sectors); + grub_util_info ("the size of %s is %lu with sector size %iu", name, disk->total_sectors, disk->sector_size); - return GRUB_ERR_NONE; + return GRUB_ERR_NONE; + } } #ifdef __linux__ @@ -346,7 +364,7 @@ _syscall5 (int, _llseek, uint, filedes, ulong, hi, ulong, lo, loff_t *, res, uint, wh); - offset = (loff_t) sector << GRUB_DISK_SECTOR_BITS; + offset = (loff_t) sector * disk->sector_size; if (_llseek (fd, offset >> 32, offset & 0xffffffff, &result, SEEK_SET)) { grub_error (GRUB_ERR_BAD_DEVICE, "cannot seek `%s'", map[disk->id].device); @@ -356,7 +374,7 @@ } #else { - off_t offset = (off_t) sector << GRUB_DISK_SECTOR_BITS; + off_t offset = (off_t) sector * disk->sector_size; if (lseek (fd, offset, SEEK_SET) != offset) { @@ -422,6 +440,8 @@ return size; } + +/* read size number of SECTORS which each in turn is of disk->sector_size bytes */ static grub_err_t grub_util_biosdisk_read (grub_disk_t disk, grub_disk_addr_t sector, grub_size_t size, char *buf) @@ -439,20 +459,20 @@ sectors that are read together with the MBR in one read. It should only remap the MBR, so we split the read in two parts. -jochen */ - if (nread (fd, buf, GRUB_DISK_SECTOR_SIZE) != GRUB_DISK_SECTOR_SIZE) + if (nread (fd, buf, disk->sector_size) != disk->sector_size) { grub_error (GRUB_ERR_READ_ERROR, "cannot read `%s'", map[disk->id].device); close (fd); return grub_errno; } - buf += GRUB_DISK_SECTOR_SIZE; + buf += disk->sector_size; size--; } #endif /* __linux__ */ - - if (nread (fd, buf, size << GRUB_DISK_SECTOR_BITS) - != (ssize_t) (size << GRUB_DISK_SECTOR_BITS)) + + if (nread (fd, buf, size * disk->sector_size) + != (ssize_t) (size * disk->sector_size)) grub_error (GRUB_ERR_READ_ERROR, "cannot read from `%s'", map[disk->id].device); close (fd); @@ -469,8 +489,8 @@ if (fd < 0) return grub_errno; - if (nwrite (fd, buf, size << GRUB_DISK_SECTOR_BITS) - != (ssize_t) (size << GRUB_DISK_SECTOR_BITS)) + if (nwrite (fd, buf, size * disk->sector_size) + != (ssize_t) (size * disk->sector_size)) grub_error (GRUB_ERR_WRITE_ERROR, "cannot write to `%s'", map[disk->id].device); close (fd); @@ -615,7 +635,7 @@ if (bsd_part >= 0) sprintf (p + strlen (p), ",%c", bsd_part + 'a'); - + return p; } @@ -788,8 +808,11 @@ return 0; } - if (! S_ISBLK (st.st_mode)) + if (! S_ISBLK (st.st_mode)) + { + grub_util_info ("not a block device: %s.", drive); return make_device_name (drive, -1, -1); + } #if defined(__linux__) || defined(__CYGWIN__) /* Linux counts partitions uniformly, whether a BSD partition or a DOS @@ -853,7 +876,7 @@ } name = make_device_name (drive, -1, -1); - + if (MAJOR (st.st_rdev) == FLOPPY_MAJOR) return name; @@ -884,9 +907,13 @@ grub_util_info ("opening the device %s", name); disk = grub_disk_open (name); free (name); - + if (! disk) return 0; + + // hdg.start is start in 512 byte sectors size regardless of the actual + // sector size of the drive! FIXME + hdg.start = hdg.start * 512 / disk->sector_size; grub_partition_iterate (disk, find_partition); if (grub_errno != GRUB_ERR_NONE) @@ -902,7 +929,7 @@ "cannot find the partition of `%s'", os_dev); return 0; } - + return make_device_name (drive, dos_part, bsd_part); } @@ -929,7 +956,7 @@ bsd_part = *q - 'a'; } } - + return make_device_name (drive, dos_part, bsd_part); } --2oS5YaxWCcQjTEyO-- From MAILER-DAEMON Wed Oct 08 12:40:43 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Knc5a-0002Bv-Tx for mharc-grub-devel@gnu.org; Wed, 08 Oct 2008 12:40:42 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Knc5Y-0002B4-GD for grub-devel@gnu.org; Wed, 08 Oct 2008 12:40:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Knc5W-00029p-JR for grub-devel@gnu.org; Wed, 08 Oct 2008 12:40:39 -0400 Received: from [199.232.76.173] (port=56480 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Knc5W-00029b-Dq for grub-devel@gnu.org; Wed, 08 Oct 2008 12:40:38 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:48501 helo=kirsi1.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Knc5W-0002ky-HU for grub-devel@gnu.org; Wed, 08 Oct 2008 12:40:38 -0400 Received: from [127.0.0.1] (84.248.105.254) by kirsi1.inet.fi (8.5.014) id 48DA2F8900C5C349 for grub-devel@gnu.org; Wed, 8 Oct 2008 19:40:34 +0300 Message-ID: <48ECE286.9090701@nic.fi> Date: Wed, 08 Oct 2008 19:40:38 +0300 From: =?UTF-8?B?VmVzYSBKw6TDpHNrZWzDpGluZW4=?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <1460730204.89441223439151710.JavaMail.root@aczmb1> In-Reply-To: <1460730204.89441223439151710.JavaMail.root@aczmb1> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: No scrolling for long input lines X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2008 16:40:40 -0000 Andy Goth wrote: > "Andy Goth" wrote: >> I'll test the current SVN this Friday, or perhaps Thursday night at >> the earliest. > > Actually I did spend time tonight investigating. I needed to get the latest SVN for another reason (about which I have questions I'll ask in a few days), so I went ahead and looked into my scrolling input problem. > > Yup, still there. Today's SVN is affected. > > The problem is present when actually booting using GRUB (ordinary VGA text mode), but it all works fine in grub-emu. > > Wait, I take that back. In grub-emu, typing very long lines (that wrap and *cause the screen to scroll*) results in the text wrapping at column 80 instead of column 79, so that there is *not* a white space character in the rightmost column. Pressing Ctrl-U from such a line will only erase only the bottom line of text, except for the first six characters (which presumably correspond to "grub> "). > > Something's flaky! However, this grub-emu stuff might be unrelated to the problem I've been having with the actual boot loader. > > I also add that in grub-emu, the carriage doesn't return after printing an error message, so I get a stairstep effect. With such an indented prompt, issuing a command like "ls" causes output to be printed to the *left* of the prompt. > > Enough about grub-emu. In the actual boot loader, I noticed that the pattern seems to be: it will scroll the screen if inserting text will cause the last character to overflow the right edge of the screen. That sounds like the way it should be, right? The problem is that only currently visible characters appear to be checked for overflow. This doesn't include the character being typed or characters that previously have failed to scroll onscreen. > > Test cases: > > 1. Near the top of the screen, type a bunch of text and overflow the edge. Works fine. > 2. Hold down enter until the screen starts scrolling. Works fine. > 3. Type a bunch of text and overflow the edge. Fails to scroll! > 4. Use the left arrow key one or two times and type text. Fails to scroll! > 5. Use the left arrow key until the cursor is onscreen, and type text. Everything scrolls into view. > > I'd absolutely love to debug all this and provide patches, but I really don't have time right now. In fact I didn't have time to do the research I did; I should have been sleeping. :^( This seems to be BIOS issue in a way. In startup.S grub_console_real_putchar there is quite good comment about what are BIOS limitations. Choices are to modify this code here, or make better bios console terminal. From MAILER-DAEMON Wed Oct 08 17:40:53 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kngm5-0000P0-38 for mharc-grub-devel@gnu.org; Wed, 08 Oct 2008 17:40:53 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kngm3-0000OE-G4 for grub-devel@gnu.org; Wed, 08 Oct 2008 17:40:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kngm2-0000Nl-QI for grub-devel@gnu.org; Wed, 08 Oct 2008 17:40:51 -0400 Received: from [199.232.76.173] (port=56360 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kngm0-0000Mn-Dj; Wed, 08 Oct 2008 17:40:49 -0400 Received: from lax-green-bigip-5.dreamhost.com ([208.113.200.5]:48101 helo=blingymail-a1.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kngm0-0002Xn-78; Wed, 08 Oct 2008 17:40:48 -0400 Received: from jidanni2.jidanni.org (122-127-33-88.dynamic.hinet.net [122.127.33.88]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by blingymail-a1.g.dreamhost.com (Postfix) with ESMTP id A63A35C994; Wed, 8 Oct 2008 14:40:44 -0700 (PDT) To: grub-devel@gnu.org References: <20081007095652.GD7127@fencepost.gnu.org> From: jidanni@jidanni.org Date: Thu, 09 Oct 2008 05:40:32 +0800 Message-ID: <87skr6935b.fsf_-_@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) Cc: bug-grub@gnu.org Subject: forgot passwd, cannot login, [rd]init=/bin/sh don't work X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2008 21:40:51 -0000 Gentlemen, last time I forgot my password and couldn't log into my machine here on my far away rural mountaintop, I ended up digging up an old Debian "potato" CDROM and installing it into some free space on my disk, from which I could edit /etc/passwd and zero out the password. These days that would no longer necessarily work, see man mkfs.ext3 -I. > Presuming Linux, you can add "init=/bin/sh" to the kernel command line. This > will give you a shell without asking for a password. From this shell you can > edit your password file. Didn't work. >Initrd scripts might change everything. OK, I then tried linux-doc-2.6.26/Documentation/kernel-parameters.txt.gz: rdinit= [KNL] Format: Run specified binary instead of /init from the ramdisk, used for early userspace startup. See initrd. So in grub2 I chose "e" to edit, and changed the lines to linux /boot/vmlinuz-2.6.26-1-686 root=UUID=... rdinit=/bin/sh initrd /boot/initrd.img-2.6.26-1-686 hit ESC then RET, and alas it was like I didn't type anything at all but just hit RET, booting proceeded as usual, and /proc/cmdline shows that my changes to that command line were thrown away. From MAILER-DAEMON Wed Oct 08 19:10:09 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KniAT-0007cd-9h for mharc-grub-devel@gnu.org; Wed, 08 Oct 2008 19:10:09 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KniAR-0007bZ-J1 for grub-devel@gnu.org; Wed, 08 Oct 2008 19:10:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KniAQ-0007ZP-2F for grub-devel@gnu.org; Wed, 08 Oct 2008 19:10:07 -0400 Received: from [199.232.76.173] (port=51257 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KniAP-0007Yk-B1 for grub-devel@gnu.org; Wed, 08 Oct 2008 19:10:05 -0400 Received: from main.gmane.org ([80.91.229.2]:54089 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KniAP-0001Rf-Cr for grub-devel@gnu.org; Wed, 08 Oct 2008 19:10:05 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KniAH-00031A-9N for grub-devel@gnu.org; Wed, 08 Oct 2008 23:09:57 +0000 Received: from adsl-69-234-183-20.dsl.irvnca.pacbell.net ([69.234.183.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Oct 2008 23:09:57 +0000 Received: from w41ter by adsl-69-234-183-20.dsl.irvnca.pacbell.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Oct 2008 23:09:57 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: grub-devel@gnu.org From: walt Date: Wed, 08 Oct 2008 16:09:42 -0700 Lines: 26 Message-ID: References: <20081007095652.GD7127@fencepost.gnu.org> <87skr6935b.fsf_-_@jidanni.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: adsl-69-234-183-20.dsl.irvnca.pacbell.net User-Agent: Thunderbird/3.0a2pre (X11; 2008100805) In-Reply-To: <87skr6935b.fsf_-_@jidanni.org> Sender: news X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Cc: bug-grub@gnu.org Subject: Re: forgot passwd, cannot login, [rd]init=/bin/sh don't work X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2008 23:10:07 -0000 jidanni@jidanni.org wrote: > ... > OK, I then tried linux-doc-2.6.26/Documentation/kernel-parameters.txt.gz: > rdinit= [KNL] > Format: > Run specified binary instead of /init from the ramdisk, > used for early userspace startup. See initrd. > > So in grub2 I chose "e" to edit, and changed the lines to > linux /boot/vmlinuz-2.6.26-1-686 root=UUID=... rdinit=/bin/sh > initrd /boot/initrd.img-2.6.26-1-686 > hit ESC then RET, and alas it was like I didn't type anything at > all but just hit RET, booting proceeded as usual, and /proc/cmdline > shows that my changes to that command line were thrown away. The only reason to use a ramdisk during boot is if your kernel doesn't have any support for your root filesystem (unlikely) or for your hardware (much more likely). If the disk controller on your motherboard isn't too exotic you could probably boot the kernel directly, i.e: /boot/vmlinuz-2.6.26-1-686 init=/bin/sh root=whatever Note the use of *init* instead of rdinit because you aren't using the initial ramdisk this way. May or may not work, but it's worth a try. From MAILER-DAEMON Wed Oct 08 21:09:10 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Knk1e-0005Q4-9q for mharc-grub-devel@gnu.org; Wed, 08 Oct 2008 21:09:10 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Knk1c-0005Po-DN for grub-devel@gnu.org; Wed, 08 Oct 2008 21:09:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Knk1b-0005Ot-04 for grub-devel@gnu.org; Wed, 08 Oct 2008 21:09:07 -0400 Received: from [199.232.76.173] (port=35727 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Knk1a-0005Oa-Ny for grub-devel@gnu.org; Wed, 08 Oct 2008 21:09:06 -0400 Received: from lax-green-bigip-5.dreamhost.com ([208.113.200.5]:58437 helo=blingymail-a1.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Knk1b-0003TS-2v for grub-devel@gnu.org; Wed, 08 Oct 2008 21:09:07 -0400 Received: from jidanni2.jidanni.org (122-127-33-88.dynamic.hinet.net [122.127.33.88]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by blingymail-a1.g.dreamhost.com (Postfix) with ESMTP id B57A45CD89; Wed, 8 Oct 2008 18:09:03 -0700 (PDT) Cc: grub-devel@gnu.org References: <4728c15d0810081751i57cfe910x9aa321f25f89495a@mail.gmail.com> From: jidanni@jidanni.org Date: Thu, 09 Oct 2008 09:09:00 +0800 Message-ID: <87bpxu8thv.fsf@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) Subject: Re: forgot passwd, cannot login, [rd]init=/bin/sh don't work X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2008 01:09:09 -0000 AW> If you have a LiveCD or recovery CD which many distros of linux have, then AW> boot under that. Then, when you are in the root shell, you can mount your AW> systems partition, and then you can use the command chroot AW> . That will make the live cd use AW> your systems file system. Then simply passwd as root, and make your new root AW> password. Yes but as happened to me before, when one digs out one's old live CDs, they often cannot deal with the newer filesystems (man mkfs.ext3 -I), so I was wondering if there was a grub way rather than burning new live CDs every few years. From MAILER-DAEMON Thu Oct 09 04:12:38 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KnqdR-0007g7-TR for mharc-grub-devel@gnu.org; Thu, 09 Oct 2008 04:12:37 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnqdP-0007bG-6c for grub-devel@gnu.org; Thu, 09 Oct 2008 04:12:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnqdO-0007ZL-3T for grub-devel@gnu.org; Thu, 09 Oct 2008 04:12:34 -0400 Received: from [199.232.76.173] (port=37976 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnqdN-0007Z9-TZ for grub-devel@gnu.org; Thu, 09 Oct 2008 04:12:33 -0400 Received: from mx20.gnu.org ([199.232.41.8]:25044) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KnqdN-00037D-FO for grub-devel@gnu.org; Thu, 09 Oct 2008 04:12:33 -0400 Received: from mx03.syneticon.net ([87.79.32.166]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnqdM-0000l4-Jb for grub-devel@gnu.org; Thu, 09 Oct 2008 04:12:32 -0400 Received: from localhost (filter1.syneticon.net [192.168.113.3]) by mx03.syneticon.net (Postfix) with ESMTP id 445519369 for ; Thu, 9 Oct 2008 10:12:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx03.syneticon.net Received: from mx03.syneticon.net ([192.168.113.4]) by localhost (mx03.syneticon.net [192.168.113.3]) (amavisd-new, port 10025) with ESMTP id bj8pbGzGsmoO for ; Thu, 9 Oct 2008 10:12:27 +0200 (CEST) Received: from [192.168.10.145] (koln-4db48193.pool.einsundeins.de [77.180.129.147]) by mx03.syneticon.net (Postfix) with ESMTP for ; Thu, 9 Oct 2008 10:12:27 +0200 (CEST) Message-ID: <48EDBCEA.6020507@wpkg.org> Date: Thu, 09 Oct 2008 10:12:26 +0200 From: Tomasz Chmielewski User-Agent: Thunderbird 2.0.0.17 (X11/20080929) MIME-Version: 1.0 To: grub-devel@gnu.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-kernel: by mx20.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: what RAID levels does GRUB2 support? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2008 08:12:35 -0000 According to http://grub.enbug.org/LVMandRAID, "GRUB has support for LVM and RAID since version 1.95" and "Installing GRUB while /boot is on RAID and/or LVM should be straightforward". However, it doesn't specify what RAID levels are supported. RAID-1 is certainly supported. What about other RAID levels, like RAID-5, RAID-0 or RAID-10? Will GRUB2 boot a Linux system from such RAID levels without a separate /boot partition? -- Tomasz Chmielewski http://wpkg.org From MAILER-DAEMON Thu Oct 09 04:28:41 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Knqsz-0005Nn-BT for mharc-grub-devel@gnu.org; Thu, 09 Oct 2008 04:28:41 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Knqsv-0005KK-Sg for grub-devel@gnu.org; Thu, 09 Oct 2008 04:28:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Knqsu-0005J3-Cn for grub-devel@gnu.org; Thu, 09 Oct 2008 04:28:37 -0400 Received: from [199.232.76.173] (port=59641 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Knqsu-0005Iu-93 for grub-devel@gnu.org; Thu, 09 Oct 2008 04:28:36 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:52585) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Knqst-0005Nu-S2 for grub-devel@gnu.org; Thu, 09 Oct 2008 04:28:36 -0400 Received: from [85.180.40.81] (e180040081.adsl.alicedsl.de [85.180.40.81]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1Knqsi1C41-0001ti; Thu, 09 Oct 2008 10:28:24 +0200 From: Felix Zielcke To: The development of GRUB 2 In-Reply-To: <48EDBCEA.6020507@wpkg.org> References: <48EDBCEA.6020507@wpkg.org> Content-Type: text/plain Date: Thu, 09 Oct 2008 10:28:23 +0200 Message-Id: <1223540903.4139.0.camel@fz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX182ALAB886GqO8kcA+qxRT1eu/EXOdvqAosVLm Qd4W8Bv2rszGfCCpgm8dCxqfWaovQ0ob6osGWsR3Q9kmtV2fsE 9pTXcJ6/8PjRJ6PiUNMR2O0TPjC6OWM X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: what RAID levels does GRUB2 support? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2008 08:28:38 -0000 Am Donnerstag, den 09.10.2008, 10:12 +0200 schrieb Tomasz Chmielewski: > According to http://grub.enbug.org/LVMandRAID, "GRUB has support for LVM > and RAID since version 1.95" and "Installing GRUB while /boot is on RAID > and/or LVM should be straightforward". > > However, it doesn't specify what RAID levels are supported. > > RAID-1 is certainly supported. What about other RAID levels, like > RAID-5, RAID-0 or RAID-10? > > Will GRUB2 boot a Linux system from such RAID levels without a separate > /boot partition? the SVN version supports everything from the Linux Software RAID RAID 0,1,10,4,5,6 and multipath which is just mapped to RAID 1 in grub2's code From MAILER-DAEMON Thu Oct 09 05:53:49 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KnsDN-00015N-Lh for mharc-grub-devel@gnu.org; Thu, 09 Oct 2008 05:53:49 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnsDM-000141-7e for grub-devel@gnu.org; Thu, 09 Oct 2008 05:53:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnsDJ-00012g-FL for grub-devel@gnu.org; Thu, 09 Oct 2008 05:53:46 -0400 Received: from [199.232.76.173] (port=42990 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnsDI-00012Z-U7 for grub-devel@gnu.org; Thu, 09 Oct 2008 05:53:45 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]:53191) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnsDH-0003RQ-Qv for grub-devel@gnu.org; Thu, 09 Oct 2008 05:53:44 -0400 Received: from [85.180.55.81] (e180055081.adsl.alicedsl.de [85.180.55.81]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1KnsDF40Rc-0000Pj; Thu, 09 Oct 2008 11:53:42 +0200 From: Felix Zielcke To: The development of GRUB 2 In-Reply-To: <200810072124.47987.okuji@enbug.org> References: <20080801144818.GA17609@thorin> <20080801153934.GA20000@thorin> <200810072124.47987.okuji@enbug.org> Content-Type: text/plain Date: Thu, 09 Oct 2008 11:53:40 +0200 Message-Id: <1223546020.4143.1.camel@fz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19viSdlqBps5MEoxPp0NM1RonFtUzE+eD2HdSg mno/YMXmD7+mCdnlwm7Q9zJOrwmfqHUc7eDWWeysKYWH8ohyKn 3SR5pLU5OqMhN4khCS1By9XXU3uTiqi X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6? (barebone, rare!) Subject: Re: rename grub to grub-legacy ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2008 09:53:48 -0000 Am Dienstag, den 07.10.2008, 21:24 +0200 schrieb Yoshinori K. Okuji: > > I have no objection. Sorry for a slow response. So if I understand it right then `svn mv svn+ssh://svn.sv.gnu.org/grub/trunk/grub svn+ssh://svn.sv.gnu.org/grub/trunk/grub-legacy' should do it, inclusive saving the history? I just better ask before trying it out :) From MAILER-DAEMON Thu Oct 09 06:23:46 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KnsgM-0003ma-Ak for mharc-grub-devel@gnu.org; Thu, 09 Oct 2008 06:23:46 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnsgK-0003mM-5N for grub-devel@gnu.org; Thu, 09 Oct 2008 06:23:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnsgH-0003m6-IH for grub-devel@gnu.org; Thu, 09 Oct 2008 06:23:42 -0400 Received: from [199.232.76.173] (port=54298 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnsgG-0003lw-VF for grub-devel@gnu.org; Thu, 09 Oct 2008 06:23:41 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]:57632) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnsgF-0000be-G0 for grub-devel@gnu.org; Thu, 09 Oct 2008 06:23:40 -0400 Received: from helfmeier.de (port-92-195-87-176.dynamic.qsc.de [92.195.87.176]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1Knsg01hFR-0001nI; Thu, 09 Oct 2008 12:23:26 +0200 Received: by helfmeier.de (sSMTP sendmail emulation); Thu, 09 Oct 2008 12:23:25 +0200 Date: Thu, 9 Oct 2008 12:23:25 +0200 From: Clemens Helfmeier To: The development of GRUB 2 Message-ID: <20081009102325.GA856@helfmeier.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.3 X-Provags-ID: V01U2FsdGVkX1+6Xr22tS6CQs8E5NzWgKHjApsc7b9ZZ65gZzL pd31ULz3tm/kxGKFeehAFwnlmEr6x96I32/d2zTGUupC8xWea7 EZT+wpX7RBqpI5L2F2GRQ== X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6? (barebone, rare!) Subject: ATAPI Driver problems X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2008 10:23:44 -0000 Hi everybody, I am trying to access the qemu cdrom drive (atapi) with grub2. Unfortunately, qemu crashes with "triple faults". A bit of google revealed that this would also reboot a real machine, so qemu has reasons for it. This always happens at the same location of code (0xb3a0 in my case) but the output bofore the crash is not always the same. I don't know if output is delayed either in qemu or in grub, does anyone know that? I also wonder why the qemu cdrom drive is not detected as removable nor as cdrom drive: grub> ls (ata2)/ ../disk/ata.c:798: opened device ata0 successfully. ../disk/ata.c:803: using block size 0x200 for device ata0. ../disk/ata.c:816: closed device ata0,1. ../disk/ata.c:920: opening ATAPI dev `ata2' ../disk/scsi.c:261: dev opened ../disk/scsi.c:270: inquiry: devtype=0x00 removable=0 qemu: fatal: triple fault How can i debug the running grub2 in the qemu machine? Is there an easy way with gdb? Did someone already get the ATAPI code working somehow? Where can i find information on how to access atapi/ata drives? (the snipped above has been created with my sector size patched svn version) Any ideas, commens, ...? Clemens From MAILER-DAEMON Thu Oct 09 11:36:59 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KnxZT-0008OM-7k for mharc-grub-devel@gnu.org; Thu, 09 Oct 2008 11:36:59 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnxZQ-0008NF-3v for grub-devel@gnu.org; Thu, 09 Oct 2008 11:36:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnxZP-0008Ms-50 for grub-devel@gnu.org; Thu, 09 Oct 2008 11:36:55 -0400 Received: from [199.232.76.173] (port=41089 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnxZP-0008Mj-2V for grub-devel@gnu.org; Thu, 09 Oct 2008 11:36:55 -0400 Received: from c60.cesmail.net ([216.154.195.49]:44174) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1KnxZO-0002De-OU for grub-devel@gnu.org; Thu, 09 Oct 2008 11:36:54 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 09 Oct 2008 11:36:52 -0400 Received: from [192.168.0.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id CA2F0618FDE for ; Thu, 9 Oct 2008 11:36:52 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: <1223546020.4143.1.camel@fz.local> References: <20080801144818.GA17609@thorin> <20080801153934.GA20000@thorin> <200810072124.47987.okuji@enbug.org> <1223546020.4143.1.camel@fz.local> Content-Type: text/plain Date: Thu, 09 Oct 2008 11:36:51 -0400 Message-Id: <1223566611.28088.30.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: rename grub to grub-legacy ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2008 15:36:56 -0000 On Thu, 2008-10-09 at 11:53 +0200, Felix Zielcke wrote: > Am Dienstag, den 07.10.2008, 21:24 +0200 schrieb Yoshinori K. Okuji: > > > > I have no objection. Sorry for a slow response. > > So if I understand it right then > `svn mv svn+ssh://svn.sv.gnu.org/grub/trunk/grub svn+ssh://svn.sv.gnu.org/grub/trunk/grub-legacy' > should do it, inclusive saving the history? > I just better ask before trying it out :) Preserving history is not perfect. I believe it's impossible to refer to the old revisions by the new names in diff, so one would need to use old paths for the pre-move revisions. Anyway, "svn mv" is the Subversion way of doing things. If we are certain that we want to move the repository, it's better to do it early. It's also better to do it when there are no unmerged branches. I believe Okuji wanted to use a different naming scheme, that would put "grub2" or "grub-legacy" above trunk. You may want to check it to avoid moving things twice. All the above notwithstanding, I'm still skeptical about the whole moving idea based on my experience with other projects. Repositories are for developers and should be used in the way that minimizes troubles for developers rather than reduces the entry barrier for newbies. If GRUB2 is moved in any way, I'm not sure I'll be able to keep the git mirror at repo.or.cz up to date. It doesn't seem that git-svn can deal with it. I'm going to try to keep is running, but I cannot promise it. -- Regards, Pavel Roskin From MAILER-DAEMON Thu Oct 09 11:58:49 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Knxub-0004kS-Ai for mharc-grub-devel@gnu.org; Thu, 09 Oct 2008 11:58:49 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnxuZ-0004hn-Rb for grub-devel@gnu.org; Thu, 09 Oct 2008 11:58:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnxuY-0004fW-2H for grub-devel@gnu.org; Thu, 09 Oct 2008 11:58:47 -0400 Received: from [199.232.76.173] (port=41824 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnxuX-0004eh-Cv for grub-devel@gnu.org; Thu, 09 Oct 2008 11:58:45 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:52432) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnxuV-0007Uu-8f for grub-devel@gnu.org; Thu, 09 Oct 2008 11:58:44 -0400 Received: from fz (e180061180.adsl.alicedsl.de [85.180.61.180]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1KnxuU0mS5-0005Is; Thu, 09 Oct 2008 17:58:42 +0200 From: "Felix Zielcke" To: "'The development of GRUB 2'" References: <20080801144818.GA17609@thorin> <20080801153934.GA20000@thorin> <200810072124.47987.okuji@enbug.org> <1223546020.4143.1.camel@fz.local> <1223566611.28088.30.camel@dv> In-Reply-To: <1223566611.28088.30.camel@dv> Date: Thu, 9 Oct 2008 17:58:38 +0200 Message-ID: <001801c92a27$e5a61dd0$b0f25970$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckqJPEp3KOGetwiSn6laRSipCAytwAAfLog Content-Language: de X-Provags-ID: V01U2FsdGVkX18BKDol9JVg/RncuiCX6iA6PMOTTGe3pW1W6UE Xc3wyCkFtjnw2+Vc4h018uq1X3UaVWd52PB1PJ0Pj4etv6Rj9F 5krVNNnyJ8gQa9wp0sOQehlFJkvAvXt X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: RE: rename grub to grub-legacy ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2008 15:58:48 -0000 > -----Original Message----- > From: grub-devel-bounces+fzielcke=3Dz-51.de@gnu.org = [mailto:grub-devel- > bounces+fzielcke=3Dz-51.de@gnu.org] On Behalf Of Pavel Roskin > Sent: Thursday, October 09, 2008 5:37 PM > To: The development of GRUB 2 > Subject: Re: rename grub to grub-legacy ? >=20 > I believe Okuji wanted to use a different naming scheme, that would = put > "grub2" or "grub-legacy" above trunk. You may want to check it to > avoid > moving things twice. Right, there was already a topic about the SVN structure I totally = forgot about: http://lists.gnu.org/archive/html/grub-devel/2008-07/msg00248.html > All the above notwithstanding, I'm still skeptical about the whole > moving idea based on my experience with other projects. Repositories > are for developers and should be used in the way that minimizes > troubles > for developers rather than reduces the entry barrier for newbies. I think grub-legacy is dead from developer POV or am I wrong? But you're right if we change things then we should do this only once, so I'm now not that sure what to do now. From MAILER-DAEMON Thu Oct 09 14:20:17 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Ko07U-0002Qo-4r for mharc-grub-devel@gnu.org; Thu, 09 Oct 2008 14:20:16 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ko07P-0002MK-J0 for grub-devel@gnu.org; Thu, 09 Oct 2008 14:20:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ko07L-0002Ik-7K for grub-devel@gnu.org; Thu, 09 Oct 2008 14:20:08 -0400 Received: from [199.232.76.173] (port=50965 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ko07L-0002Ih-46 for grub-devel@gnu.org; Thu, 09 Oct 2008 14:20:07 -0400 Received: from mail-in-05.arcor-online.net ([151.189.21.45]:37430) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ko07K-000505-SZ for grub-devel@gnu.org; Thu, 09 Oct 2008 14:20:07 -0400 Received: from mail-in-20-z2.arcor-online.net (mail-in-20-z2.arcor-online.net [151.189.8.85]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 209921839A3 for ; Thu, 9 Oct 2008 20:20:01 +0200 (CEST) Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) by mail-in-20-z2.arcor-online.net (Postfix) with ESMTP id 0B577107AA6 for ; Thu, 9 Oct 2008 20:20:01 +0200 (CEST) Received: from cerberus.olympus (dslb-088-074-247-134.pools.arcor-ip.net [88.74.247.134]) (Authenticated sender: blubberdiblub@arcor.de) by mail-in-11.arcor-online.net (Postfix) with ESMTP id 7CA682C160F for ; Thu, 9 Oct 2008 20:20:00 +0200 (CEST) Received: from cerberus.olympus ([192.168.1.3] ident=foobar) by cerberus.olympus with esmtp (Exim 4.69) (envelope-from ) id 1Ko07D-0001T1-R7 for grub-devel@gnu.org; Thu, 09 Oct 2008 20:19:59 +0200 From: Niels =?iso-8859-1?q?B=F6hm?= To: The development of GRUB 2 Date: Thu, 9 Oct 2008 20:19:59 +0200 User-Agent: KMail/1.9.9 References: <20081007095652.GD7127@fencepost.gnu.org> <87skr6935b.fsf_-_@jidanni.org> In-Reply-To: <87skr6935b.fsf_-_@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200810092019.59531.bitbucket@arcor.de> X-Virus-Scanned: ClamAV 0.93.3/8399/Thu Oct 9 14:27:14 2008 on mail-in-11.arcor-online.net X-Virus-Status: Clean X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Subject: Re: forgot passwd, cannot login, [rd]init=/bin/sh don't work X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2008 18:20:12 -0000 On Wednesday 08 October 2008, jidanni@jidanni.org wrote: > > So in grub2 I chose "e" to edit, and changed the lines to > linux /boot/vmlinuz-2.6.26-1-686 root=3DUUID=3D... rdinit=3D/bin/sh > initrd /boot/initrd.img-2.6.26-1-686 > hit ESC then RET, and alas it was like I didn't type anything at > all but just hit RET, booting proceeded as usual, and /proc/cmdline > shows that my changes to that command line were thrown away. That's normal behaviour, if you press ESC all your changes are gone. The solution is not to press ESC, but Ctrl-x instead. There's also a hint=20 about that in the online help below the editor frame. Niels B=F6hm From MAILER-DAEMON Fri Oct 10 18:06:42 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KoQ8A-0002gt-9P for mharc-grub-devel@gnu.org; Fri, 10 Oct 2008 18:06:42 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KoQ87-0002gb-Na for grub-devel@gnu.org; Fri, 10 Oct 2008 18:06:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KoQ84-0002ex-Pi for grub-devel@gnu.org; Fri, 10 Oct 2008 18:06:37 -0400 Received: from [199.232.76.173] (port=50444 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KoQ84-0002ej-GY for grub-devel@gnu.org; Fri, 10 Oct 2008 18:06:36 -0400 Received: from c60.cesmail.net ([216.154.195.49]:50781) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1KoQ84-0007Uz-4e for grub-devel@gnu.org; Fri, 10 Oct 2008 18:06:36 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 10 Oct 2008 18:06:28 -0400 Received: from [192.168.0.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id 5F7F2618FDE for ; Fri, 10 Oct 2008 18:06:28 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: <001801c92a27$e5a61dd0$b0f25970$@de> References: <20080801144818.GA17609@thorin> <20080801153934.GA20000@thorin> <200810072124.47987.okuji@enbug.org> <1223546020.4143.1.camel@fz.local> <1223566611.28088.30.camel@dv> <001801c92a27$e5a61dd0$b0f25970$@de> Content-Type: text/plain Date: Fri, 10 Oct 2008 18:06:26 -0400 Message-Id: <1223676386.11969.1.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: RE: rename grub to grub-legacy ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2008 22:06:40 -0000 On Thu, 2008-10-09 at 17:58 +0200, Felix Zielcke wrote: > I think grub-legacy is dead from developer POV or am I wrong? There have been some commits after the last release. A major issue can force releasing another version. > But you're right if we change things then we should do this only once, > so I'm now not that sure what to do now. Let's wait then. It's not like the existing structure is blocking anything. -- Regards, Pavel Roskin From MAILER-DAEMON Fri Oct 10 21:19:41 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KoT8v-0006nH-3Q for mharc-grub-devel@gnu.org; Fri, 10 Oct 2008 21:19:41 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KoT8t-0006nC-Oe for grub-devel@gnu.org; Fri, 10 Oct 2008 21:19:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KoT8s-0006mq-Ch for grub-devel@gnu.org; Fri, 10 Oct 2008 21:19:38 -0400 Received: from [199.232.76.173] (port=43226 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KoT8s-0006mn-7e for grub-devel@gnu.org; Fri, 10 Oct 2008 21:19:38 -0400 Received: from lax-green-bigip-5.dreamhost.com ([208.113.200.5]:40608 helo=blingymail-a3.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KoT8r-0008Te-Qs for grub-devel@gnu.org; Fri, 10 Oct 2008 21:19:37 -0400 Received: from jidanni2.jidanni.org (122-127-45-217.dynamic.hinet.net [122.127.45.217]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by blingymail-a3.g.dreamhost.com (Postfix) with ESMTP id 1896714D77D for ; Fri, 10 Oct 2008 18:19:37 -0700 (PDT) To: grub-devel@gnu.org From: jidanni@jidanni.org Date: Sat, 11 Oct 2008 05:19:59 +0800 Message-ID: <874p3ki1vk.fsf@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) Subject: grub-install message should mention --recheck X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2008 01:19:40 -0000 Please implement these changes in making this typical grub-install message. Thanks. # grub-install /dev/hda Installation finished. No error reported. This is the contents of the device map /boot/grub/device.map. - Check if this is correct or not. If any of the lines is incorrect, - fix it and re-run the script `grub-install'. + If not correct try --recheck, or fix and rerun. (hd0) /dev/hda From MAILER-DAEMON Fri Oct 10 22:46:14 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KoUUg-00005n-IQ for mharc-grub-devel@gnu.org; Fri, 10 Oct 2008 22:46:14 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KoUUe-0008V0-CR for grub-devel@gnu.org; Fri, 10 Oct 2008 22:46:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KoUUc-0008Rs-45 for grub-devel@gnu.org; Fri, 10 Oct 2008 22:46:11 -0400 Received: from [199.232.76.173] (port=50817 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KoUUc-0008Rg-0t for grub-devel@gnu.org; Fri, 10 Oct 2008 22:46:10 -0400 Received: from lax-green-bigip-5.dreamhost.com ([208.113.200.5]:54729 helo=blingymail-a1.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KoUUb-0006Uv-Gt for grub-devel@gnu.org; Fri, 10 Oct 2008 22:46:09 -0400 Received: from jidanni2.jidanni.org (122-127-43-81.dynamic.hinet.net [122.127.43.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by blingymail-a1.g.dreamhost.com (Postfix) with ESMTP id 1612B90483 for ; Fri, 10 Oct 2008 19:46:07 -0700 (PDT) To: grub-devel@gnu.org References: <200810092019.59531.bitbucket@arcor.de> From: jidanni@jidanni.org Date: Sat, 11 Oct 2008 10:46:04 +0800 Message-ID: <87bpxru9w3.fsf@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) Subject: Re: forgot passwd, cannot login, [rd]init=/bin/sh don't work X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2008 02:46:13 -0000 Ah, no wonder. These need rewording: Use the %C and %C keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting or 'c' for a command-line. Minimum Emacs-like screen editing is supported. TAB lists available completions. Press C-x ('x' with Ctrl) to boot, C-c ('c' with Ctrl) for a command-line or ESC to return menu. Here, I have reworded the latter, preserving terseness, and fixing grammar: Minimum Emacs-like editing is supported. TAB lists available completions. Press C-x ('x' with Ctrl) to boot, C-c for a command-line or ESC to throw away changes and return to menu. Kindly integrate it into your next version. Thank you. (There is also a grub screen with its several lines of help text enclosed by "[ ]". Might as well chuck them too.) By the way, I indeed now could login now without remembering the password. Use linux /boot/vmlinuz-... root=... rw init=/bin/sh initrd /boot/initrd.img-... The key is the "rw init=/bin/sh". (And after editing /etc/passwd to change root's :x: to ::, be sure not to just exit the shell, but hit CTRL-ALT-DEL, else one has to push the reset button.) From MAILER-DAEMON Sat Oct 11 21:53:29 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Koq9A-0000kk-VX for mharc-grub-devel@gnu.org; Sat, 11 Oct 2008 21:53:29 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Koq99-0000kU-CK for grub-devel@gnu.org; Sat, 11 Oct 2008 21:53:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Koq94-0000is-Ga for grub-devel@gnu.org; Sat, 11 Oct 2008 21:53:26 -0400 Received: from [199.232.76.173] (port=42395 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Koq94-0000in-BN for grub-devel@gnu.org; Sat, 11 Oct 2008 21:53:22 -0400 Received: from mtiwmhc11.worldnet.att.net ([204.127.131.115]:62133) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Koq94-0000Iq-43 for grub-devel@gnu.org; Sat, 11 Oct 2008 21:53:22 -0400 Received: from who8 (h-67-101-132-149.nycmny83.dynamic.covad.net[67.101.132.149]) by worldnet.att.net (mtiwmhc11) with SMTP id <20081012015320111004v0n0e>; Sun, 12 Oct 2008 01:53:20 +0000 From: "Gregg C Levine" To: "'The development of GRUB 2'" Date: Sat, 11 Oct 2008 21:53:28 -0400 Message-ID: <119DD4F0656646489BE762079BABF700@who8> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <001801c92a27$e5a61dd0$b0f25970$@de> Importance: Normal Thread-Index: AckqJPEp3KOGetwiSn6laRSipCAytwAAfLogAHltwSA= X-detected-operating-system: by monty-python.gnu.org: NetCache Data OnTap 5.x Subject: RE: rename grub to grub-legacy ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2008 01:53:27 -0000 Hello! Indeed. You are quite correct concerning GRUB as it is described. However given the fluid state of GRUB2 I am reluctant to try it out = unless I can convince my hardware to play along. -- Gregg C Levine hansolofalcon@worldnet.att.net "The Force will be with you always." Obi-Wan Kenobi =A0=20 > -----Original Message----- > From: grub-devel-bounces+hansolofalcon=3Dworldnet.att.net@gnu.org [mailto:grub-devel- > bounces+hansolofalcon=3Dworldnet.att.net@gnu.org] On Behalf Of Felix = Zielcke > Sent: Thursday, October 09, 2008 11:59 AM > To: 'The development of GRUB 2' > Subject: RE: rename grub to grub-legacy ? >=20 > > -----Original Message----- > > From: grub-devel-bounces+fzielcke=3Dz-51.de@gnu.org = [mailto:grub-devel- > > bounces+fzielcke=3Dz-51.de@gnu.org] On Behalf Of Pavel Roskin > > Sent: Thursday, October 09, 2008 5:37 PM > > To: The development of GRUB 2 > > Subject: Re: rename grub to grub-legacy ? > > > > I believe Okuji wanted to use a different naming scheme, that would = put > > "grub2" or "grub-legacy" above trunk. You may want to check it to > > avoid > > moving things twice. >=20 > Right, there was already a topic about the SVN structure I totally = forgot about: >=20 > http://lists.gnu.org/archive/html/grub-devel/2008-07/msg00248.html >=20 > > All the above notwithstanding, I'm still skeptical about the whole > > moving idea based on my experience with other projects. = Repositories > > are for developers and should be used in the way that minimizes > > troubles > > for developers rather than reduces the entry barrier for newbies. >=20 > I think grub-legacy is dead from developer POV or am I wrong? >=20 > But you're right if we change things then we should do this only once, > so I'm now not that sure what to do now. >=20 >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel From MAILER-DAEMON Sun Oct 12 20:29:28 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpBJP-0001Wx-Ru for mharc-grub-devel@gnu.org; Sun, 12 Oct 2008 20:29:27 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpBJO-0001Ws-LC for grub-devel@gnu.org; Sun, 12 Oct 2008 20:29:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpBJM-0001WF-0o for grub-devel@gnu.org; Sun, 12 Oct 2008 20:29:25 -0400 Received: from [199.232.76.173] (port=42097 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpBJL-0001W4-Ou for grub-devel@gnu.org; Sun, 12 Oct 2008 20:29:23 -0400 Received: from wf-out-1314.google.com ([209.85.200.173]:3040) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpBJL-0001CX-UC for grub-devel@gnu.org; Sun, 12 Oct 2008 20:29:24 -0400 Received: by wf-out-1314.google.com with SMTP id 28so1663089wfc.24 for ; Sun, 12 Oct 2008 17:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=QQKcUUIHr4iXB+pbk4bsTJgSUBb0fS+dWMfyz8rACqA=; b=A5oQwP/LYghc15PoFwbyHecFMM8BerZqSEfwTQjhK1mutb1jhfyy9rRSdtg58f0F+5 rQ5zzQJX6skGfllS2X/WdyQopcp7CrGK5wOiAFpOsspfaKt9YDWcPoajSdrJJ3dwEzek yLTkxVsGAbZHt36U8Q8v1gzdZR70WEI4bsM6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=ZKx/Lw5fRlhIIze4pWfK+SESRARldrYSqAFVXReexKjTHhtBwpGZhtYwYcCxlKqcm6 mlSpSjcpr2jKgeqf+nmYYNJgLqj0id+vwfKn4rQMQGpZKuo8hXVEW7x4LTH4Qaaj2Xng h2JizfUPe0c1i2BaiHPtjN93iKC+2NGo9DPvg= Received: by 10.142.107.5 with SMTP id f5mr2246217wfc.210.1223857761852; Sun, 12 Oct 2008 17:29:21 -0700 (PDT) Received: by 10.142.232.18 with HTTP; Sun, 12 Oct 2008 17:29:21 -0700 (PDT) Message-ID: Date: Sun, 12 Oct 2008 20:29:21 -0400 From: "James Shewey" To: grub-devel@gnu.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_98916_18098217.1223857761843" X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Problem in configure X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 00:29:26 -0000 ------=_Part_98916_18098217.1223857761843 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I believe that line 6938, which reads: if test "x$grub_cv_prog_target_cc" = xno; then May contain an error. Perhaps this should read if test "$grub_cv_prog_target_cc" = xno; then or if test "$grub_cv_prog_target_cc" = no; then ? -James ------=_Part_98916_18098217.1223857761843 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I believe that line 6938, which reads:

if test "x$grub_cv_prog_target_cc" = xno; then

May contain an error. Perhaps this should read

if test "$grub_cv_prog_target_cc" = xno; then

or

if test "$grub_cv_prog_target_cc" = no; then

?

-James



------=_Part_98916_18098217.1223857761843-- From MAILER-DAEMON Sun Oct 12 21:08:15 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpBux-0006Ue-J1 for mharc-grub-devel@gnu.org; Sun, 12 Oct 2008 21:08:15 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpBuv-0006SP-Ro for grub-devel@gnu.org; Sun, 12 Oct 2008 21:08:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpBuu-0006QK-75 for grub-devel@gnu.org; Sun, 12 Oct 2008 21:08:13 -0400 Received: from [199.232.76.173] (port=42506 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpBut-0006Q5-Vq for grub-devel@gnu.org; Sun, 12 Oct 2008 21:08:12 -0400 Received: from wf-out-1314.google.com ([209.85.200.173]:6888) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpBuu-0007it-2q for grub-devel@gnu.org; Sun, 12 Oct 2008 21:08:12 -0400 Received: by wf-out-1314.google.com with SMTP id 28so1668282wfc.24 for ; Sun, 12 Oct 2008 18:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=hPARcnx52iBq4kf/uAzHotc+pEw7Y1486+pA6joBLVU=; b=TBpWHHKweemRmb76wJvpyyo3t8jKhqr645V2WGMeKjW9Zubit9VASGE7cSqga7iNG+ W1k/779qlEOPYT7KdYGX+g/nWvzgDf8p/ZXKIcw4e9DfME+X55Wa2fmOR4b3RKQrloIc IgpjVKFhf34/T5LR6iEmYlp2dVmJHgeYCUp8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=T8GvUtjLYO94CZ/8UdHPWMEabbJh7sKa/UJL06gCIiAEGlhlC7Bwc2fDieGoK78f67 DLcyMnCaj4rUWuiS0/d5BxWhpJNeo00IAG0tn57EaC7Bad/p9Tnvqa26VTszWouFV5i9 ETgjzhGsmwSGsNk6QQuGuOrvrDCeEfQgUjpt8= Received: by 10.142.187.8 with SMTP id k8mr2257099wff.226.1223860090005; Sun, 12 Oct 2008 18:08:10 -0700 (PDT) Received: by 10.142.232.18 with HTTP; Sun, 12 Oct 2008 18:08:09 -0700 (PDT) Message-ID: Date: Sun, 12 Oct 2008 21:08:09 -0400 From: "James Shewey" To: grub-devel@gnu.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_99001_25266585.1223860089996" References: X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Problem in configure X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 01:08:14 -0000 ------=_Part_99001_25266585.1223860089996 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This may be a nevermind situation. I was compiling on a 64 bit system. Changing the line described to if test "$grub_cv_prog_target_cc" = xno; then" Resulted in an error stating that neither start or _start was defined. This led me to the following post: http://bbs.archlinux.org/viewtopic.php?id=56033. This led me to try compiling on my 32 bit system which worked just fine. On Sun, Oct 12, 2008 at 8:29 PM, James Shewey wrote: > I believe that line 6938, which reads: > > if test "x$grub_cv_prog_target_cc" = xno; then > > May contain an error. Perhaps this should read > > if test "$grub_cv_prog_target_cc" = xno; then > > or > > if test "$grub_cv_prog_target_cc" = no; then > > ? > > -James > > > > ------=_Part_99001_25266585.1223860089996 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
This may be a nevermind situation. I was compiling on a 64 bit system. Changing the line described to if test "$grub_cv_prog_target_cc" = xno; then" Resulted in an error stating that neither start or _start was defined. This led me to the following post: http://bbs.archlinux.org/viewtopic.php?id=56033. This led me to try compiling on my 32 bit system which worked just fine.

On Sun, Oct 12, 2008 at 8:29 PM, James Shewey <jdshewey@gmail.com> wrote:
I believe that line 6938, which reads:

if test "x$grub_cv_prog_target_cc" = xno; then

May contain an error. Perhaps this should read

if test "$grub_cv_prog_target_cc" = xno; then

or

if test "$grub_cv_prog_target_cc" = no; then

?

-James




------=_Part_99001_25266585.1223860089996-- From MAILER-DAEMON Mon Oct 13 02:57:02 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpHMU-0006d2-Oz for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 02:57:02 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpHMT-0006cN-FU for grub-devel@gnu.org; Mon, 13 Oct 2008 02:57:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpHMR-0006cB-Sr for grub-devel@gnu.org; Mon, 13 Oct 2008 02:57:00 -0400 Received: from [199.232.76.173] (port=55099 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpHMR-0006c8-My for grub-devel@gnu.org; Mon, 13 Oct 2008 02:56:59 -0400 Received: from mx20.gnu.org ([199.232.41.8]:43378) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KpHMQ-0003g8-TE for grub-devel@gnu.org; Mon, 13 Oct 2008 02:56:59 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpHME-0001WM-Hr for grub-devel@gnu.org; Mon, 13 Oct 2008 02:56:46 -0400 Received: from helfmeier.de (port-92-195-40-36.dynamic.qsc.de [92.195.40.36]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1KpHM52V1d-0007aj; Mon, 13 Oct 2008 08:56:39 +0200 Received: by helfmeier.de (sSMTP sendmail emulation); Mon, 13 Oct 2008 08:56:39 +0200 Date: Mon, 13 Oct 2008 08:56:39 +0200 From: Clemens Helfmeier To: The development of GRUB 2 Message-ID: <20081013065639.GD2412@helfmeier.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.3 X-Provags-ID: V01U2FsdGVkX19t5Zi5U/uwcRZ8q7oTTdVoJllszdp1BbF5reb U4UZXmgxAcMmDWOL+LnYCVhppN6cUcbRSnppkot/SuGHej852U gO+ylieHBaEHN44l7IhLg== X-detected-kernel: by mx20.gnu.org: Linux 2.6? (barebone, rare!) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: Re: Problem in configure X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 06:57:01 -0000 Hi James, This is a shell thing. It just ensures that the evaluation does not result in if test = xno; then (in case the variable is empty) and thus throw an error. with "x" it its like this for an empty variable if test x = xno; then which would work fine for shells. The x does not affect the result of the evaluation since it is on both sides of the evaluation. Bye, Clemens On Sun, Oct 12, 2008 at 09:08:09PM -0400, James Shewey wrote: > This may be a nevermind situation. I was compiling on a 64 bit system. > Changing the line described to if test "$grub_cv_prog_target_cc" = xno; > then" Resulted in an error stating that neither start or _start was defined. > This led me to the following post: > http://bbs.archlinux.org/viewtopic.php?id=56033. This led me to try > compiling on my 32 bit system which worked just fine. > > On Sun, Oct 12, 2008 at 8:29 PM, James Shewey wrote: > > > I believe that line 6938, which reads: > > > > if test "x$grub_cv_prog_target_cc" = xno; then > > > > May contain an error. Perhaps this should read > > > > if test "$grub_cv_prog_target_cc" = xno; then > > > > or > > > > if test "$grub_cv_prog_target_cc" = no; then > > > > ? > > > > -James > > > > > > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel From MAILER-DAEMON Mon Oct 13 03:39:08 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpI1E-0005CF-JN for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 03:39:08 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpI1C-00059j-6E for grub-devel@gnu.org; Mon, 13 Oct 2008 03:39:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpI19-00057U-KO for grub-devel@gnu.org; Mon, 13 Oct 2008 03:39:04 -0400 Received: from [199.232.76.173] (port=37142 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpI19-00057I-Hu for grub-devel@gnu.org; Mon, 13 Oct 2008 03:39:03 -0400 Received: from mx20.gnu.org ([199.232.41.8]:46820) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KpI19-0006th-2J for grub-devel@gnu.org; Mon, 13 Oct 2008 03:39:03 -0400 Received: from mailout08.t-online.de ([194.25.134.20]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpI17-0005nn-F3 for grub-devel@gnu.org; Mon, 13 Oct 2008 03:39:01 -0400 Received: from fwd05.aul.t-online.de by mailout08.sul.t-online.de with smtp id 1KpI15-0008TZ-03; Mon, 13 Oct 2008 09:38:59 +0200 Received: from localhost (JOt4u8ZYZhIqX49ebc9FSGOIS469Ge6LuI0SK6dzIj3OXPSjFy23KD5BtjQAku6ZaO@[172.20.101.250]) by fwd05.aul.t-online.de with esmtp id 1KpI0t-0YWBe40; Mon, 13 Oct 2008 09:38:47 +0200 MIME-Version: 1.0 Received: from 194.45.13.131:35097 by cmpweb07.aul.t-online.de with HTTP/1.1 (Kommunikationscenter V9-2-19 on API V3-3-11) In-Reply-To: <20081013065639.GD2412@helfmeier.de> References: <20081013065639.GD2412@helfmeier.de> Date: Mon, 13 Oct 2008 09:38:47 +0200 To: "The development of GRUB 2" X-UMS: email X-Mailer: TOI Kommunikationscenter V9-2-19 From: "Christian Franke" Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <1KpI0t-0YWBe40@fwd05.aul.t-online.de> X-ID: JOt4u8ZYZhIqX49ebc9FSGOIS469Ge6LuI0SK6dzIj3OXPSjFy23KD5BtjQAku6ZaO@t-dialin.net X-TOI-MSGID: e1bc13e1-f4d0-47b9-a9a1-8f2fd0fe780f X-detected-kernel: by mx20.gnu.org: Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: Re: Problem in configure X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 07:39:06 -0000 Clemens Helfmeier wrote: > This is a shell thing. It just ensures that the evaluation does not > result in if test = xno; then > (in case the variable is empty) and thus throw an error. with "x" it > its like this for an empty variable > if test x = xno; then > which would work fine for shells. > BTW: This is not necessary if the expanded argument is quoted like in the original example. Instead of test "x$foo" = "xno" it is OK to use: test "$foo" = "no" or test "$foo" = no which is IMO more easy to read. For an unset/empty variable, this expands to test "" = no which does not throw an error. The leading 'x' was probably necessary for very ancient shells with broken evaluation of quoted empty argument. Even using the 'x' to avoid quoting is dangerous. It works for empty variables, but throws an error if the variable contains spaces, e.g: foo="one two" test x$foo = xno result: test xone two = xno bash: test: too many arguments Regards, Christian From MAILER-DAEMON Mon Oct 13 07:33:13 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpLfl-0003GI-QN for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 07:33:13 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpLfj-0003Et-9J for grub-devel@gnu.org; Mon, 13 Oct 2008 07:33:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpLfh-0003Dk-KP for grub-devel@gnu.org; Mon, 13 Oct 2008 07:33:10 -0400 Received: from [199.232.76.173] (port=60087 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpLfh-0003DU-Du for grub-devel@gnu.org; Mon, 13 Oct 2008 07:33:09 -0400 Received: from wr-out-0506.google.com ([64.233.184.233]:46735) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpLfh-0004vQ-9n for grub-devel@gnu.org; Mon, 13 Oct 2008 07:33:09 -0400 Received: by wr-out-0506.google.com with SMTP id c30so1171384wra.14 for ; Mon, 13 Oct 2008 04:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:content-class :from:subject:date:importance:x-priority:to :content-transfer-encoding:content-type:message-id; bh=hMVCP67dwX5kSeFgq6xMisJkgsLTdDG7JLEuvDuqrFg=; b=rDF+ilFhCReysOj1hcvoxhCsURHd1kRg8qtOuiRPOe4ez2QU6WlPLDuBZXRCkUELId XZViFtZ6fShZ6w+m30HrTDGT8RP+hrGyrRp4g6xw1IglKSi7deeJE9Ycvdb+DO+nSwvB t08d2F9hH5tH02v/h9QuhmbYaPA12+nC7eIwE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:content-class:from:subject:date:importance:x-priority :to:content-transfer-encoding:content-type:message-id; b=Fo6VtxaBaebEy+q4ns8LsQZg96P9OIWnxKDpFm96JYPY4aVC/yDQmJzJyZyFvz5fIJ G6C9tGLpVGB9lj8nz4z7bYgJkHH7oaZ2R5Hf5HzwaWRlbe4HJwGAf6Hvc7njvv5Ynmlv JBdprEnxwmvH24aCerLy6iAV/uUVoMVwpoSj0= Received: by 10.65.215.14 with SMTP id s14mr10470543qbq.18.1223897587739; Mon, 13 Oct 2008 04:33:07 -0700 (PDT) Received: from Inbox ([72.61.147.76]) by mx.google.com with ESMTPS id q16sm9154745qbq.0.2008.10.13.04.33.04 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Oct 2008 04:33:06 -0700 (PDT) MIME-Version: 1.0 content-class: From: James Shewey Date: Mon, 13 Oct 2008 07:33:17 -0400 Importance: normal X-Priority: 3 To: The development of GRUB 2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Message-ID: <48f331f2.102b400a.1f58.ffffd488@mx.google.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: RE: Problem in configure X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 11:33:12 -0000 Ahh. That makes sense. Interesting bit of history there. The x in the left = side of the evuation is what threw me. I didn't think that would even be le= gal syntactically, but those explanations make a lot of sense. - James -----Original Message----- From: Christian Franke Sent: Monday, October 13, 2008 3:38 AM To: The development of GRUB 2 Subject: Re: Problem in configure Clemens Helfmeier wrote: > This is a shell thing. It just ensures that the evaluation does not > result in if test =3D xno; then > (in case the variable is empty) and thus throw an error. with "x" it > its like this for an empty variable > if test x =3D xno; then > which would work fine for shells. >=20 BTW: This is not necessary if the expanded argument is quoted like in the original example. Instead of test "x$foo" =3D "xno" it is OK to use: test "$foo" =3D "no" or test "$foo" =3D no which is IMO more easy to read. For an unset/empty variable, this expands to test "" =3D no which does not throw an error. The leading 'x' was probably necessary for very ancient shells with broken evaluation of quoted empty argument. [The entire original message is not included]= From MAILER-DAEMON Mon Oct 13 12:36:50 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpQPa-0003sP-Dh for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 12:36:50 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpQPY-0003s8-Ed for grub-devel@gnu.org; Mon, 13 Oct 2008 12:36:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpQPX-0003rw-UJ for grub-devel@gnu.org; Mon, 13 Oct 2008 12:36:48 -0400 Received: from [199.232.76.173] (port=36849 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpQPX-0003rt-MR for grub-devel@gnu.org; Mon, 13 Oct 2008 12:36:47 -0400 Received: from gateway14.websitewelcome.com ([69.56.150.9]:37506) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KpQPX-0001gb-5X for grub-devel@gnu.org; Mon, 13 Oct 2008 12:36:47 -0400 Received: (qmail 19480 invoked from network); 13 Oct 2008 16:52:39 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway14.websitewelcome.com with SMTP; 13 Oct 2008 16:52:39 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:45503 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KpQPR-0004Db-ET; Mon, 13 Oct 2008 11:36:41 -0500 Date: Mon, 13 Oct 2008 09:35:53 -0700 From: Colin D Bennett To: The development of GRUB 2 Message-ID: <20081013093553.4f3e978e@gibibit.com> In-Reply-To: <48E891E4.1000507@nic.fi> References: <20080830235254.7cc5ad80@gamma.lan> <48E891E4.1000507@nic.fi> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.3; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/Udqh2x.PRdFvK2yYrrUpI+H"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: Subject: Re: [PATCH] GSoC #05 Menu entry class attribute (v2) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 16:36:48 -0000 --Sig_/Udqh2x.PRdFvK2yYrrUpI+H Content-Type: multipart/mixed; boundary="MP_/5wr3jd20pGxjaaIX0ulxjKC" --MP_/5wr3jd20pGxjaaIX0ulxjKC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 05 Oct 2008 13:07:32 +0300 Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > Colin D Bennett wrote: > > This patch adds support for a 'class' attribute on menu entries. > > It is somewhat of a kludge, however since currently you just append > > "|class=3Dthis,that" to the menu entry title to specify the classes. > >=20 > > Classes are used to provide a simple and flexible way for the best > > available icon to be used in a graphical menu, but there are other > > possible uses for them as well. The idea originates from the CSS > > (cascading style sheets) and HTML 'class' concept. >=20 > Here is the patch snipped for using menuentry --class foo "title" { }. >=20 > Please try it out and see if it fits. Hi Vesa, Thanks for the argument parsing improvement. I'm glad to rip out the '|class=3D' title kludge. Here is the result of merging your patch into the menu entry class code. Regards, Colin --MP_/5wr3jd20pGxjaaIX0ulxjKC Content-Type: text/x-patch; name=05_menu-entry-class_v2.patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=05_menu-entry-class_v2.patch 2008-10-13 Colin D Bennett Support classes for menu entries via the '--class CLASSNAME' argument to the menuentry command. Argument list parsing functionality by Vesa J=C3=A4=C3=A4skel=C3=A4inen . * include/grub/menu.h (grub_menu_entry_class): New struct type. (grub_menu_entry): Added 'classes' field. * include/grub/normal.h (grub_normal_menu_addentry): Changed signature to take a list of arguments instead of just a title. * include/grub/script.h (grub_script_cmd_menuentry): Replaced title with arglist. (grub_script_create_cmdmenu): Changed signature to take an arglist instead of just a single arg (title). * normal/execute.c (grub_script_execute_menuentry): Parse arguments to the 'menuentry' script command. * normal/main.c (free_menu_entry_classes): New function. (grub_normal_menu_addentry): Take and process a list of arguments; handle '--class CLASSNAME' arguments and store the list of class names in the menu entry. * normal/parser.y (menuentry): Take a list of arguments. * normal/script.c (grub_script_create_cmdmenu): Take an argument list, store it in the command. =3D=3D=3D modified file 'include/grub/menu.h' --- include/grub/menu.h 2008-08-30 19:20:13 +0000 +++ include/grub/menu.h 2008-10-13 16:15:06 +0000 @@ -20,12 +20,24 @@ #ifndef GRUB_MENU_HEADER #define GRUB_MENU_HEADER 1 =20 +struct grub_menu_entry_class +{ + char *name; + struct grub_menu_entry_class *next; +}; + /* The menu entry. */ struct grub_menu_entry { /* The title name. */ const char *title; =20 + /* The classes associated with the menu entry: + used to choose an icon or other style attributes. + This is a dummy head node for the linked list, so for an entry E, + E.classes->next is the first class if it is not NULL. */ + struct grub_menu_entry_class *classes; + /* The commands associated with this menu entry. */ struct grub_script *commands; =20 =3D=3D=3D modified file 'include/grub/normal.h' --- include/grub/normal.h 2008-10-03 14:26:41 +0000 +++ include/grub/normal.h 2008-10-13 16:15:06 +0000 @@ -141,7 +141,7 @@ char *grub_normal_do_completion (char *buf, int *restore, void (*hook) (const char *item, grub_completion_type_t type, int coun= t)); grub_err_t grub_normal_print_device_info (const char *name); -grub_err_t grub_normal_menu_addentry (const char *title, +grub_err_t grub_normal_menu_addentry (int argc, const char **args, struct grub_script *script, const char *sourcecode); char *grub_env_write_color_normal (struct grub_env_var *var, const char *v= al); =3D=3D=3D modified file 'include/grub/script.h' --- include/grub/script.h 2008-05-30 02:26:56 +0000 +++ include/grub/script.h 2008-10-13 16:15:06 +0000 @@ -113,8 +113,8 @@ { struct grub_script_cmd cmd; =20 - /* The title of the menu entry. */ - struct grub_script_arg *title; + /* The arguments for this menu entry. */ + struct grub_script_arglist *arglist; =20 /* The sourcecode the entry will be generated from. */ const char *sourcecode; @@ -204,7 +204,7 @@ =20 struct grub_script_cmd * grub_script_create_cmdmenu (struct grub_parser_param *state, - struct grub_script_arg *title, + struct grub_script_arglist *arglist, char *sourcecode, int options); =20 =3D=3D=3D modified file 'normal/execute.c' --- normal/execute.c 2008-01-15 15:32:17 +0000 +++ normal/execute.c 2008-10-13 16:15:06 +0000 @@ -216,29 +216,50 @@ grub_script_execute_menuentry (struct grub_script_cmd *cmd) { struct grub_script_cmd_menuentry *cmd_menuentry; - char *title; + struct grub_script_arglist *arglist; struct grub_script *script; + char **args =3D 0; + int argcount =3D 0; + int i =3D 0; =20 cmd_menuentry =3D (struct grub_script_cmd_menuentry *) cmd; =20 - /* The title can contain variables, parse them and generate a string - from it. */ - title =3D grub_script_execute_argument_to_string (cmd_menuentry->title); - if (! title) - return grub_errno; + if (cmd_menuentry->arglist) + { + argcount =3D cmd_menuentry->arglist->argcount; + + /* Create argv from the arguments. */ + args =3D grub_malloc (sizeof (char *) * argcount); + + if (! args) + { + return grub_errno; + } + + for (arglist =3D cmd_menuentry->arglist; arglist; arglist =3D arglis= t->next) + { + char *str; + str =3D grub_script_execute_argument_to_string (arglist->arg); + args[i++] =3D str; + } + } =20 /* Parse the menu entry *again*. */ script =3D grub_script_parse ((char *) cmd_menuentry->sourcecode, 0); =20 - if (! script) + /* Add new menu entry. */ + if (script) { - grub_free (title); - return grub_errno; + grub_normal_menu_addentry (argcount, args, + script, cmd_menuentry->sourcecode); } =20 - /* XXX: When this fails, the memory should be freed? */ - return grub_normal_menu_addentry (title, script, - cmd_menuentry->sourcecode); + /* Free arguments. */ + for (i =3D 0; i < argcount; i++) + grub_free (args[i]); + grub_free (args); + + return grub_errno; } =20 =0C =3D=3D=3D modified file 'normal/main.c' --- normal/main.c 2008-08-30 19:20:13 +0000 +++ normal/main.c 2008-10-13 16:15:06 +0000 @@ -148,14 +148,41 @@ grub_env_unset_data_slot ("menu"); } =20 +static void +free_menu_entry_classes (struct grub_menu_entry_class *head) +{ + /* Free all the classes. */ + while (head) + { + struct grub_menu_entry_class *next; + + grub_free (head->name); + next =3D head->next; + grub_free (head); + head =3D next; + } +} + grub_err_t -grub_normal_menu_addentry (const char *title, struct grub_script *script, +grub_normal_menu_addentry (int argc, const char **args, struct grub_script= *script, const char *sourcecode) { - const char *menutitle; + const char *menutitle =3D 0; const char *menusourcecode; grub_menu_t menu; grub_menu_entry_t *last; + int failed =3D 0; + int i; + struct grub_menu_entry_class *classes_head; /* Dummy head node for list= . */ + struct grub_menu_entry_class *classes_tail; + + /* Allocate dummy head node for class list. */ + classes_head =3D grub_malloc (sizeof (struct grub_menu_entry_class)); + if (! classes_head) + return grub_errno; + classes_head->name =3D 0; + classes_head->next =3D 0; + classes_tail =3D classes_head; =20 menu =3D grub_env_get_data_slot("menu"); if (! menu) @@ -167,10 +194,81 @@ if (! menusourcecode) return grub_errno; =20 - menutitle =3D grub_strdup (title); - if (! menutitle) - { + /* Parse menu arguments. */ + for (i =3D 0; i < argc; i++) + { + /* Capture arguments. */ + if (grub_strncmp ("--", args[i], 2) =3D=3D 0) + { + const char *arg =3D &args[i][2]; + + /* Handle menu class. */ + if (grub_strcmp(arg, "class") =3D=3D 0) + { + char *class_name; + struct grub_menu_entry_class *new_class; + + i++; + class_name =3D grub_strdup (args[i]); + if (! class_name) + { + failed =3D 1; + break; + } + + /* Create a new class and add it at the tail of the list. */ + new_class =3D grub_malloc (sizeof (struct grub_menu_entry_class)); + if (! new_class) + { + grub_free (class_name); + failed =3D 1; + break; + } + /* Fill in the new class node. */ + new_class->name =3D class_name; + new_class->next =3D 0; + /* Link the tail to it, and make it the new tail. */ + classes_tail->next =3D new_class; + classes_tail =3D new_class; + continue; + } + else + { + /* Handle invalid argument. */ + failed =3D 1; + grub_error (GRUB_ERR_MENU, "invalid argument for menuentry: %s", ar= gs[i]); + break; + } + } + + /* Capture title. */ + if (! menutitle) + { + menutitle =3D grub_strdup (args[i]); + } + else + { + failed =3D 1; + grub_error (GRUB_ERR_MENU, "too many titles for menuentry: %s", args[i]= ); + break; + } + } + + /* Validate arguments. */ + if ((! failed) && (! menutitle)) + { + grub_error (GRUB_ERR_MENU, "menuentry is missing title"); + failed =3D 1; + } + + /* If argument parsing failed, free any allocated resources. */ + if (failed) + { + free_menu_entry_classes (classes_head); + grub_free ((void *) menutitle); grub_free ((void *) menusourcecode); + + /* Here we assume that grub_error has been used to specify failure d= etails. */ return grub_errno; } =20 @@ -181,6 +279,7 @@ *last =3D grub_malloc (sizeof (**last)); if (! *last) { + free_menu_entry_classes (classes_head); grub_free ((void *) menutitle); grub_free ((void *) menusourcecode); return grub_errno; @@ -188,6 +287,7 @@ =20 (*last)->commands =3D script; (*last)->title =3D menutitle; + (*last)->classes =3D classes_head; (*last)->next =3D 0; (*last)->sourcecode =3D menusourcecode; =20 =3D=3D=3D modified file 'normal/parser.y' --- normal/parser.y 2008-07-02 00:00:37 +0000 +++ normal/parser.y 2008-10-13 16:15:06 +0000 @@ -204,7 +204,7 @@ ; =20 /* A menu entry. Carefully save the memory that is allocated. */ -menuentry: "menuentry" argument +menuentry: "menuentry" arguments { grub_script_lexer_ref (state->lexerstate); } newlines '{' =3D=3D=3D modified file 'normal/script.c' --- normal/script.c 2007-12-30 08:52:06 +0000 +++ normal/script.c 2008-10-13 16:15:06 +0000 @@ -206,7 +206,7 @@ The options for this entry are passed in OPTIONS. */ struct grub_script_cmd * grub_script_create_cmdmenu (struct grub_parser_param *state, - struct grub_script_arg *title, + struct grub_script_arglist *arglist, char *sourcecode, int options) { @@ -232,9 +232,9 @@ cmd->cmd.next =3D 0; /* XXX: Check if this memory is properly freed. */ cmd->sourcecode =3D sourcecode; - cmd->title =3D title; + cmd->arglist =3D arglist; cmd->options =3D options; -=20 + return (struct grub_script_cmd *) cmd; } =20 --MP_/5wr3jd20pGxjaaIX0ulxjKC-- --Sig_/Udqh2x.PRdFvK2yYrrUpI+H Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjzeOwACgkQokx8fzcGbYdGdQCfRgwZl7EerJCtFYIYIVra9DtP G9YAn1f5w9jQqAr4fU0JH1M4xwrRNTDT =s7lP -----END PGP SIGNATURE----- --Sig_/Udqh2x.PRdFvK2yYrrUpI+H-- From MAILER-DAEMON Mon Oct 13 12:49:12 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpQbY-0000mB-Fo for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 12:49:12 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpQbX-0000m3-6I for grub-devel@gnu.org; Mon, 13 Oct 2008 12:49:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpQbV-0000kA-8Y for grub-devel@gnu.org; Mon, 13 Oct 2008 12:49:10 -0400 Received: from [199.232.76.173] (port=36454 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpQbV-0000k0-58 for grub-devel@gnu.org; Mon, 13 Oct 2008 12:49:09 -0400 Received: from gateway11.websitewelcome.com ([67.18.7.10]:48597) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KpQbU-0003nP-Ko for grub-devel@gnu.org; Mon, 13 Oct 2008 12:49:08 -0400 Received: (qmail 18862 invoked from network); 13 Oct 2008 17:01:17 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway11.websitewelcome.com with SMTP; 13 Oct 2008 17:01:17 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:57183 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KpQbP-0005R1-4n for grub-devel@gnu.org; Mon, 13 Oct 2008 11:49:03 -0500 Date: Mon, 13 Oct 2008 09:48:15 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081013094815.733491bb@gibibit.com> In-Reply-To: <48EA60D6.7060708@nic.fi> References: <777113540.40311223236640078.JavaMail.root@aczmb1> <48EA60D6.7060708@nic.fi> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.3; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/0/BHle6TCstu1SBxHOlbheJ"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #07 VBE double buffering (vs r1885) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 16:49:11 -0000 --Sig_/0/BHle6TCstu1SBxHOlbheJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 06 Oct 2008 22:02:46 +0300 Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > Andy Goth wrote: > > "Colin D Bennett" wrote: > > Requiring full-screen repaints is an architectural design that > > might need rework to undo later. Or might not, depending on how > > you implement it. The interim approach you choose now should be > > informed by foresight. > [...] > Hi, >=20 > I would like to thank Andy for his comments on the topic. I do share > the same concern about designing double buffering to work properly > without making hasty implementation first. We can use non-buffered > solution as a first stage "hasty implementation" and design good > enough solution to handle double buffering well. >=20 > Dirty rectangles for every buffer (two in double buffer case) might be > the best approach here. I think there is some kind of dirty rectangle > implementation on gfxterm so that could be used as a base for this > work. After that it could be improved to increase performance but the > main point being that there has to be proper framework to make it > work properly. >=20 > Usually the slowest step is to transfer image data from main memory to > video memory (and usually the slowest is to read from video memory to > main memory and then save it back to video memory). If we can optimize > memory copies between video and main memories we are on good track to > solve speed problem. I agree that a dirty region repaint management system will provide better performance, but I certainly do not have time to implement it now. IMO that would take a lot of work. I *am* interested in getting high performance, but (1) I simply don't have time to do it myself right now, and=20 (2) gfxmenu seems plenty fast to me--I have run Lua-driven full screen animations as a desktop background for gfxmenu, and it worked fantastically. The menu system performs decently even on my ultra-low-power-but-low-performance-too Via C3 system. Granted, the gfxterm terminal is nearly unusable right now, but I think its performance can be improved significantly through a few relatively minor changes. Regards, Colin --Sig_/0/BHle6TCstu1SBxHOlbheJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjze9IACgkQokx8fzcGbYdfHACfRarZxw0k1As/sqoDcYa9SFbd xeIAn3jWOijnLrEzEaCbcZCyGyRMbtbd =q0RM -----END PGP SIGNATURE----- --Sig_/0/BHle6TCstu1SBxHOlbheJ-- From MAILER-DAEMON Mon Oct 13 13:01:41 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpQnd-0007gE-9D for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 13:01:41 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpQna-0007fy-Qa for grub-devel@gnu.org; Mon, 13 Oct 2008 13:01:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpQnZ-0007fV-9L for grub-devel@gnu.org; Mon, 13 Oct 2008 13:01:38 -0400 Received: from [199.232.76.173] (port=48756 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpQnZ-0007fS-3p for grub-devel@gnu.org; Mon, 13 Oct 2008 13:01:37 -0400 Received: from gateway03.websitewelcome.com ([69.93.155.28]:41110) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KpQnY-00068R-PD for grub-devel@gnu.org; Mon, 13 Oct 2008 13:01:37 -0400 Received: (qmail 23448 invoked from network); 13 Oct 2008 17:15:49 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway03.websitewelcome.com with SMTP; 13 Oct 2008 17:15:49 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:36602 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KpQmw-0006do-4o; Mon, 13 Oct 2008 12:00:58 -0500 Date: Mon, 13 Oct 2008 10:00:10 -0700 From: Colin D Bennett To: The development of GRUB 2 Message-ID: <20081013100010.22d1dc54@gibibit.com> In-Reply-To: <48E67DB3.8030408@nic.fi> References: <20080831000157.0c548199@gamma.lan> <48BAC517.4060002@nic.fi> <48BD5F00.9090902@nic.fi> <48E67DB3.8030408@nic.fi> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.3; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/y__vI.LdOqCjj76dhBTc2kE"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: Subject: Re: [PATCH] GSoC #09 Bitmap scaling X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 17:01:39 -0000 --Sig_/y__vI.LdOqCjj76dhBTc2kE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 03 Oct 2008 23:16:51 +0300 Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > > Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > >> It is really necessary that all generic graphical menu code like > >> bitmap scaler works always. Not just for some optimized formats as > >> otherwise it would render graphical menu unusable in some cases. > >> It can be not so pretty on low end systems, but it should at least > >> work. That is the reason there is map/unmap functions in video api. > >> > >> So there has to be first generic implementation and then you can > >> use optimized one if there exist one. > >=20 > > Just thinking as this is operating in a bitmap, we could just make > > sure we use only couple of formats and let video driver dot the > > rest. That would simplify it a bit. >=20 > Hi, >=20 > Now that Colin is back in action I am reviving this thread :). >=20 > I have been thinking this a bit and I think best solution to bitmaps > is something like following. >=20 > Two types of bitmap: easily accessible and optimized bitmaps for > hardware. >=20 > Easily accessible are meant to be modified by user and provides slow > blitting performance. Basically we should only support two formats. > RGB888 and ARGB8888 (order can be different). This way we can make > easy code to modify bitmaps. >=20 > When there is no need to modify bitmap anymore, one calls > grub_video_bitmap_optimize(bitmap, rendering_target) and then bitmap > is optimized to match reder_targets format. >=20 > there would be two new helpers that gives access to bitmap data. > grub_video_bitmap_lock() and to release it grub_video_bitmap_unlock(). > Lock will fail if bitmap is optimized. What is the effect of lock/unlock on an unoptimized bitmap? Is it like a reference counting memory management scheme? > I am wondering should we have grub_video_bitmap_unoptimize() to map > back to editable mode. But that might be more pain and promote bad > ways to do conversion. If some code needed to modify an optimized bitmap, we could just have that code keep the unoptimized version of the bitmap around for modification, and just re-optimize the bitmap after modifying it. Of course it would only make sense to optimize bitmaps that will be blitted more than once. > Now bitmap loaders would be modified to return data in easily > accessible format so bitmaps can be modified and so on. >=20 > Now to bitmap scaling. This can only be done for easily accessible > formats and could be something like this: >=20 > +grub_err_t > +grub_video_bitmap_create_scaled (struct grub_video_bitmap **dst, > + int dst_width, int dst_height, > + struct grub_video_bitmap *src, > + enum > + grub_video_bitmap_scale_method > scale_method); >=20 > Now in example static bitmaps would be optimized right away in order > to make their blitting fast. I do not know if we need special > handling for transparent bitmaps. May need some experimenting. I have been scaling bitmaps with alpha transparency and it works fine with the scaling code in the patch. It's used for the menu frame, the selected item highlight, and entry icons, to name a few uses. > Actual scalers would be hidden from API and can only be specified by > enum type. Ok; sounds good. > It could be a good idea to implement all scalers in same file. Unless > there is some weird scaler that needs thousands of lines of code. I'm fine with that. (Though in general my preference is for short source files: 900+ line files become like a labyrinth of code, a maze of twisty passages all alike.) > Any opinions? >=20 > Thanks, > Vesa J=C3=A4=C3=A4skel=C3=A4inen Regards, Colin --Sig_/y__vI.LdOqCjj76dhBTc2kE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjzfp0ACgkQokx8fzcGbYcfKgCfRw0+x/hAX+yqCLctkQmhiPxk XAAAn0yM2Xr+/CV9c4t2G4QLYf73f+Jf =7T5R -----END PGP SIGNATURE----- --Sig_/y__vI.LdOqCjj76dhBTc2kE-- From MAILER-DAEMON Mon Oct 13 13:13:52 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpQzQ-000441-FH for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 13:13:52 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpQzP-00042h-31 for grub-devel@gnu.org; Mon, 13 Oct 2008 13:13:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpQzN-00040g-Fm for grub-devel@gnu.org; Mon, 13 Oct 2008 13:13:50 -0400 Received: from [199.232.76.173] (port=50534 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpQzN-00040d-7V for grub-devel@gnu.org; Mon, 13 Oct 2008 13:13:49 -0400 Received: from gateway02.websitewelcome.com ([69.56.170.20]:40906) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KpQzN-0008O2-4r for grub-devel@gnu.org; Mon, 13 Oct 2008 13:13:49 -0400 Received: (qmail 715 invoked from network); 13 Oct 2008 17:30:21 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway02.websitewelcome.com with SMTP; 13 Oct 2008 17:30:21 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:37103 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KpQzG-0007uM-O7 for grub-devel@gnu.org; Mon, 13 Oct 2008 12:13:42 -0500 Date: Mon, 13 Oct 2008 10:12:54 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081013101254.29e56d37@gibibit.com> In-Reply-To: <20081013094815.733491bb@gibibit.com> References: <777113540.40311223236640078.JavaMail.root@aczmb1> <48EA60D6.7060708@nic.fi> <20081013094815.733491bb@gibibit.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.3; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/ZYJ_epYorTkJpoqUgFTHNB+"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #07 VBE double buffering (vs r1885) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 17:13:51 -0000 --Sig_/ZYJ_epYorTkJpoqUgFTHNB+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 13 Oct 2008 09:48:15 -0700 Colin D Bennett wrote: > I *am* interested in getting high performance, but > (1) I simply don't have time to do it myself right now, and=20 > (2) gfxmenu seems plenty fast to me--I have run Lua-driven full screen > animations as a desktop background for gfxmenu, and it worked > fantastically. The menu system performs decently even on my > ultra-low-power-but-low-performance-too Via C3 system. Another reason I did not implement dirty region repaint optimization that I forgot to mention: (3) Dirty region repaint handling does not help at all when most of the screen is being updated on each frame. Since I expect the "fancy menu" to become more and more full of eye-candy (that is the purpose, after all!), the dirty region handling would only help for the most vanilla of themes. I have said I will add some animation and special effects to GRUB. Things that I think would be cool (and cool =3D> more people drawn to use GRUB) include a fade-in/fade-out when GRUB starts/executes an entry, a fully animated background of some sort (of the type that many xscreensavers use), etc. Regards, Colin --Sig_/ZYJ_epYorTkJpoqUgFTHNB+ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjzgZkACgkQokx8fzcGbYd1CwCgie/4vb9xfGE6sb4bCUeIjRek 9mAAnREOPTyCSr6rnsNcenAjLQLC62bk =zsP+ -----END PGP SIGNATURE----- --Sig_/ZYJ_epYorTkJpoqUgFTHNB+-- From MAILER-DAEMON Mon Oct 13 14:27:56 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpS96-00082I-Ob for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 14:27:56 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpS95-00081c-47 for grub-devel@gnu.org; Mon, 13 Oct 2008 14:27:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpS94-00081I-7g for grub-devel@gnu.org; Mon, 13 Oct 2008 14:27:54 -0400 Received: from [199.232.76.173] (port=40413 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpS94-00081D-1t for grub-devel@gnu.org; Mon, 13 Oct 2008 14:27:54 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:55032 helo=kirsi1.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpS93-0004hg-0R for grub-devel@gnu.org; Mon, 13 Oct 2008 14:27:53 -0400 Received: from [127.0.0.1] (84.248.105.254) by kirsi1.inet.fi (8.5.014) id 48DA2F890100EF37 for grub-devel@gnu.org; Mon, 13 Oct 2008 21:27:47 +0300 Message-ID: <48F39322.8060508@nic.fi> Date: Mon, 13 Oct 2008 21:27:46 +0300 From: =?UTF-8?B?VmVzYSBKw6TDpHNrZWzDpGluZW4=?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <20080831000157.0c548199@gamma.lan> <48BAC517.4060002@nic.fi> <48BD5F00.9090902@nic.fi> <48E67DB3.8030408@nic.fi> <20081013100010.22d1dc54@gibibit.com> In-Reply-To: <20081013100010.22d1dc54@gibibit.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: Quoted-Printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #09 Bitmap scaling X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 18:27:55 -0000 Colin D Bennett wrote: > On Fri, 03 Oct 2008 23:16:51 +0300 > Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: >> I have been thinking this a bit and I think best solution to bitmaps >> is something like following. >> >> Two types of bitmap: easily accessible and optimized bitmaps for >> hardware. >> >> Easily accessible are meant to be modified by user and provides slow >> blitting performance. Basically we should only support two formats. >> RGB888 and ARGB8888 (order can be different). This way we can make >> easy code to modify bitmaps. >> >> When there is no need to modify bitmap anymore, one calls >> grub_video_bitmap_optimize(bitmap, rendering_target) and then bitmap >> is optimized to match reder_targets format. >> >> there would be two new helpers that gives access to bitmap data. >> grub_video_bitmap_lock() and to release it grub_video_bitmap_unlock(). >> Lock will fail if bitmap is optimized. >=20 > What is the effect of lock/unlock on an unoptimized bitmap? Is it like > a reference counting memory management scheme? Idea is that if bitmap is still locked you cannot optimize it or you cannot lock it again. And if bitmap is optimized you cannot get pointer to modify it. Eg. Function call returns memory pointer. >> I am wondering should we have grub_video_bitmap_unoptimize() to map >> back to editable mode. But that might be more pain and promote bad >> ways to do conversion. >=20 > If some code needed to modify an optimized bitmap, we could just have > that code keep the unoptimized version of the bitmap around for > modification, and just re-optimize the bitmap after modifying it. Of > course it would only make sense to optimize bitmaps that will be > blitted more than once. And if bitmap is animated, there is no good reason to optimize it either. >> Now bitmap loaders would be modified to return data in easily >> accessible format so bitmaps can be modified and so on. >> >> Now to bitmap scaling. This can only be done for easily accessible >> formats and could be something like this: >> >> +grub_err_t >> +grub_video_bitmap_create_scaled (struct grub_video_bitmap **dst, >> + int dst_width, int dst_height, >> + struct grub_video_bitmap *src, >> + enum >> + grub_video_bitmap_scale_method >> scale_method); >> >> Now in example static bitmaps would be optimized right away in order >> to make their blitting fast. I do not know if we need special >> handling for transparent bitmaps. May need some experimenting. >=20 > I have been scaling bitmaps with alpha transparency and it works fine > with the scaling code in the patch. It's used for the menu frame, the > selected item highlight, and entry icons, to name a few uses. Well... For our use it should be sufficient. So lets use that. >> Actual scalers would be hidden from API and can only be specified by >> enum type. >=20 > Ok; sounds good. >=20 >> It could be a good idea to implement all scalers in same file. Unless >> there is some weird scaler that needs thousands of lines of code. >=20 > I'm fine with that. (Though in general my preference is for short > source files: 900+ line files become like a labyrinth of code, a > maze of twisty passages all alike.) True. But sometimes it is good idea to keep it in same place. I didn't look at the files but I think it should not be too long. In example you can hide those other methods with static specifier. Thanks, Vesa J=C3=A4=C3=A4skel=C3=A4inen From MAILER-DAEMON Mon Oct 13 16:00:59 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpTb9-0004io-50 for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 16:00:59 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpTb6-0004hE-4x for grub-devel@gnu.org; Mon, 13 Oct 2008 16:00:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpTb5-0004gK-DS for grub-devel@gnu.org; Mon, 13 Oct 2008 16:00:55 -0400 Received: from [199.232.76.173] (port=60766 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpTb5-0004g7-4c for grub-devel@gnu.org; Mon, 13 Oct 2008 16:00:55 -0400 Received: from gateway04.websitewelcome.com ([67.18.59.10]:39110) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KpTb4-0003xV-IZ for grub-devel@gnu.org; Mon, 13 Oct 2008 16:00:54 -0400 Received: (qmail 25475 invoked from network); 13 Oct 2008 20:12:54 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway04.websitewelcome.com with SMTP; 13 Oct 2008 20:12:54 -0000 Received: from spk.venturedesignservices.com ([65.61.115.34]:42961 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KpTb1-0007vf-Gh for grub-devel@gnu.org; Mon, 13 Oct 2008 15:00:51 -0500 Date: Mon, 13 Oct 2008 13:00:05 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081013130005.2adac4b2@gibibit.com> In-Reply-To: <48F39322.8060508@nic.fi> References: <20080831000157.0c548199@gamma.lan> <48BAC517.4060002@nic.fi> <48BD5F00.9090902@nic.fi> <48E67DB3.8030408@nic.fi> <20081013100010.22d1dc54@gibibit.com> <48F39322.8060508@nic.fi> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.3; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/DH0Roj_1n2ogOywlUkg2DFj"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #09 Bitmap scaling X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 20:00:56 -0000 --Sig_/DH0Roj_1n2ogOywlUkg2DFj Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 13 Oct 2008 21:27:46 +0300 Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > Colin D Bennett wrote: > > On Fri, 03 Oct 2008 23:16:51 +0300 > > Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > >> I have been thinking this a bit and I think best solution to > >> bitmaps is something like following. > >> > >> Two types of bitmap: easily accessible and optimized bitmaps for > >> hardware. > >> > >> Easily accessible are meant to be modified by user and provides > >> slow blitting performance. Basically we should only support two > >> formats. RGB888 and ARGB8888 (order can be different). This way we > >> can make easy code to modify bitmaps. > >> > >> When there is no need to modify bitmap anymore, one calls > >> grub_video_bitmap_optimize(bitmap, rendering_target) and then > >> bitmap is optimized to match reder_targets format. > >> > >> there would be two new helpers that gives access to bitmap data. > >> grub_video_bitmap_lock() and to release it > >> grub_video_bitmap_unlock(). Lock will fail if bitmap is optimized. > >=20 > > What is the effect of lock/unlock on an unoptimized bitmap? Is it > > like a reference counting memory management scheme? >=20 > Idea is that if bitmap is still locked you cannot optimize it or you > cannot lock it again. And if bitmap is optimized you cannot get > pointer to modify it. Eg. Function call returns memory pointer. I thought perhaps the 'optimize' operation would simply return a _new_ (and completely independent from that point forward) bitmap equivalent to the input bitmap but in the same format as the current video mode uses. Are you thinking that it would be best to have the 'optimize'/'unoptimize' operations actually just modify the bitmap in place? I guess this is nice from a memory conservation standpoint, but in some cases it wouldn't work well (i.e., 24-bit to 32-bit formats). >=20 > >> I am wondering should we have grub_video_bitmap_unoptimize() to map > >> back to editable mode. But that might be more pain and promote bad > >> ways to do conversion. > >=20 > > If some code needed to modify an optimized bitmap, we could just > > have that code keep the unoptimized version of the bitmap around for > > modification, and just re-optimize the bitmap after modifying it. > > Of course it would only make sense to optimize bitmaps that will be > > blitted more than once. >=20 > And if bitmap is animated, there is no good reason to optimize it > either. Agreed -- an animated bitmap is just a specific instance of a single use bitmap. > >> Now bitmap loaders would be modified to return data in easily > >> accessible format so bitmaps can be modified and so on. > >> > >> Now to bitmap scaling. This can only be done for easily accessible > >> formats and could be something like this: > >> > >> +grub_err_t > >> +grub_video_bitmap_create_scaled (struct grub_video_bitmap **dst, > >> + int dst_width, int dst_height, > >> + struct grub_video_bitmap *src, > >> + enum > >> + grub_video_bitmap_scale_method > >> scale_method); > >> > >> Now in example static bitmaps would be optimized right away in > >> order to make their blitting fast. I do not know if we need special > >> handling for transparent bitmaps. May need some experimenting. > >=20 > > I have been scaling bitmaps with alpha transparency and it works > > fine with the scaling code in the patch. It's used for the menu > > frame, the selected item highlight, and entry icons, to name a few > > uses. >=20 > Well... For our use it should be sufficient. So lets use that. Ok. > >> Actual scalers would be hidden from API and can only be specified > >> by enum type. > >=20 > > Ok; sounds good. > >=20 > >> It could be a good idea to implement all scalers in same file. > >> Unless there is some weird scaler that needs thousands of lines of > >> code. > >=20 > > I'm fine with that. (Though in general my preference is for short > > source files: 900+ line files become like a labyrinth of code, a > > maze of twisty passages all alike.) >=20 > True. But sometimes it is good idea to keep it in same place. I didn't > look at the files but I think it should not be too long. In example > you can hide those other methods with static specifier. Yes, it might be best here to simply put it all in one file--sounds fine to me. I agree that making things static is a benefit of putting all related stuff together in a file, to improve encapsulation. Regards, Colin --Sig_/DH0Roj_1n2ogOywlUkg2DFj Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjzqMYACgkQokx8fzcGbYeZMACfVCIw+zkgNJi1PixmWCZ8oDPR kycAnitTpG4PueWNznH1MBJGdw4g0gV4 =BK9s -----END PGP SIGNATURE----- --Sig_/DH0Roj_1n2ogOywlUkg2DFj-- From MAILER-DAEMON Mon Oct 13 17:11:51 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpUhj-0002Is-Cd for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 17:11:51 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpUhd-0002HD-Va for grub-devel@gnu.org; Mon, 13 Oct 2008 17:11:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpUhc-0002Gc-N0 for grub-devel@gnu.org; Mon, 13 Oct 2008 17:11:45 -0400 Received: from [199.232.76.173] (port=50451 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpUhc-0002GX-D6 for grub-devel@gnu.org; Mon, 13 Oct 2008 17:11:44 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:34786 helo=jenni1.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpUhb-0006EO-Nc for grub-devel@gnu.org; Mon, 13 Oct 2008 17:11:44 -0400 Received: from [127.0.0.1] (84.248.105.254) by jenni1.inet.fi (8.5.014) id 48DA2BD701032468 for grub-devel@gnu.org; Tue, 14 Oct 2008 00:11:42 +0300 Message-ID: <48F3B98E.4060109@nic.fi> Date: Tue, 14 Oct 2008 00:11:42 +0300 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <20080831000157.0c548199@gamma.lan> <48BAC517.4060002@nic.fi> <48BD5F00.9090902@nic.fi> <48E67DB3.8030408@nic.fi> <20081013100010.22d1dc54@gibibit.com> <48F39322.8060508@nic.fi> <20081013130005.2adac4b2@gibibit.com> In-Reply-To: <20081013130005.2adac4b2@gibibit.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #09 Bitmap scaling X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 21:11:46 -0000 Colin D Bennett wrote: > On Mon, 13 Oct 2008 21:27:46 +0300 > Vesa J=E4=E4skel=E4inen wrote: >> Idea is that if bitmap is still locked you cannot optimize it or you >> cannot lock it again. And if bitmap is optimized you cannot get >> pointer to modify it. Eg. Function call returns memory pointer. >=20 > I thought perhaps the 'optimize' operation would simply return a _new_ > (and completely independent from that point forward) bitmap equivalent > to the input bitmap but in the same format as the current video mode > uses. Problem with that is that it makes supporting code harder to use. With only handful of supported formats it much easier to write support code to modify bitmap. If you allow to use any format supported by video subsystem it is nightmare to support them all. So if we just support two formats. We only need to care about RGB and RGBA formats, rather easy task. Can be modified by using simple loops or indexing. When we know that there is no modifications to be done for bitmap, we can just call optimize() and it will convert (edited) bitmap to fast to blit format. As we have same handle all the time for bitmap we can just continue to use it as is. If we would make new instance of it, would either need to delete previous one and replace its usage with new one. Of course use case here affects. > Are you thinking that it would be best to have the > 'optimize'/'unoptimize' operations actually just modify the bitmap in > place? I guess this is nice from a memory conservation standpoint, but > in some cases it wouldn't work well (i.e., 24-bit to 32-bit formats). I do not think at this point how optimize() or unoptimize() will be implemented. Just general idea. Whether it is in-place operation or re-allocation for memory, is same to me. It just have to work :) Thanks, Vesa J=E4=E4skel=E4inen From MAILER-DAEMON Tue Oct 14 07:35:01 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpiB3-0007il-DL for mharc-grub-devel@gnu.org; Tue, 14 Oct 2008 07:35:01 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpiB1-0007hX-TQ for grub-devel@gnu.org; Tue, 14 Oct 2008 07:35:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpiAy-0007fp-4w for grub-devel@gnu.org; Tue, 14 Oct 2008 07:34:59 -0400 Received: from [199.232.76.173] (port=34727 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpiAx-0007fj-UX for grub-devel@gnu.org; Tue, 14 Oct 2008 07:34:56 -0400 Received: from web31605.mail.mud.yahoo.com ([68.142.198.151]:47223) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KpiAx-0001Za-Dz for grub-devel@gnu.org; Tue, 14 Oct 2008 07:34:55 -0400 Received: (qmail 73574 invoked by uid 60001); 14 Oct 2008 11:34:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=HE/Dewm1A1HLd26MipYDlHj78zWbnQu7RyiPTZG1j4Z60oxEtJXhGReNFIkzHgT4BzrWlqYTYt7YDGmsPIaBKpdqvlw/Zx8o7JTy1uj6T8Fvqwa4E6herSdY3KpDie/oj4kyAiDwYRvXLr0t+cNgD7seQPCphHG7hLhLWkGlNK0=; X-YMail-OSG: VYIRR5IVM1lb4ErIEekx0ojqwxcTAVz9jkoMEggnjo3J.iEemiKR7RRJqeJlrW9oLNvj8FCsn8zqRTxFBfNYmhyj3FethDNADSeyrlSwTFX7h6QAID8MlevvAGkuxp8mz8FOa7AqwjQbY7SyCxDNgz0TqzGsYIuudrVAUMWHnF2S0vwDeyewwVa63bc- Received: from [202.62.94.130] by web31605.mail.mud.yahoo.com via HTTP; Tue, 14 Oct 2008 04:34:53 PDT X-Mailer: YahooMailRC/1096.40 YahooMailWebService/0.7.218.2 Date: Tue, 14 Oct 2008 04:34:53 -0700 (PDT) From: Viswesh S To: The development of GRUB 2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <83465.72271.qm@web31605.mail.mud.yahoo.com> X-detected-operating-system: by monty-python.gnu.org: FreeBSD 6.x (1) Subject: Re: Windows,grub and grub2 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 11:35:00 -0000 Hi,=0A=0A=0A=0A----- Original Message ----=0A> From: Bean =0A> To: The development of GRUB 2 =0A> Sent: Monda= y, 29 September, 2008 4:20:57 PM=0A> Subject: Re: Windows,grub and grub2=0A= > =0A> On Mon, Sep 29, 2008 at 1:18 PM, Viswesh S wrote:=0A> > Hi,=0A> >=0A= > >=0A> >=0A> > ----- Original Message ----=0A> >> From: Bean =0A> >> To: T= he development of GRUB 2 =0A> >> Sent: Tuesday, 23 September, 2008 7:20:49 = PM=0A> >> Subject: Re: Windows,grub and grub2=0A> >>=0A> >> On Tue, Sep 23,= 2008 at 4:23 PM, Viswesh S wrote:=0A> >> >=0A> >> >=0A> >> >=0A> >> >=0A> = >> > ----- Original Message ----=0A> >> >> From: Bean=0A> >> >> To: The dev= elopment of GRUB 2=0A> >> >> Sent: Monday, 22 September, 2008 9:10:26 AM=0A= > >> >> Subject: Re: Windows,grub and grub2=0A> >> >>=0A> >> >> On Tue, Sep= 9, 2008 at 2:00 PM, Viswesh S wrote:=0A> >> >> > Below is the dump of scre= en output while chainloading the ntfsnew file.=0A> >> >> > ****************= ***********************=0A> >> >> > DI=3DCFF0 SI=3D07EE BP=3D1FF0 SP=3D1FE8= BX=3D0000 DX=3D0000 CX=3D0000 AX=3D0000=0A> >> >> > CS=3D0000 SS=3D0000 DS= =3D0000 ES=3D0000 FG=3D0246 IP=3D7C57=0A> >> >> >=0A> >> >> > DI=3D7FF0 SI= =3D07EE BP=3D1FF0 SP=3D7BF4 BX=3D55AA DX=3D0000 CX=3D0000 AX=3D0100 CX=3D07= C0=0A> >> >> > DS=3D07C0 ES=3D0000 FG=3D0007 IP=3D0082=0A> >> >> > ********= **********************************=0A> >> >> > Could you please let me know= the way to disassemble the binary file =0A> without=0A> >> >> > any header= .The way in which you decoded the boot record.=0A> >> >> >=0A> >> >> > Also= one more thing to let you know is that,=0A> >> >> >=0A> >> >> > with the g= rub-1.96 ( without the chainloader patch of disk->dev->read() =0A> ) ,=0A> = >> >> > with windows2003 in partition 1 and linux in partition 3, when we= =0A> >> chainload,=0A> >> >> > if we look at the partition table passed to = another bootloader ie =0A> location=0A> >> >> > 0x7be - we can see that it = is junk, but the surprising point is that, in=0A> >> >> > this case as I ha= ve mentioned in my first mail, windows boots up from=0A> >> >> > grub2.So i= t is that the partition table is not required for the =0A> chainloader=0A> = >> >> > thing and just the boot record is sufficient=0A> >> >>=0A> >> >> Hi= ,=0A> >> >>=0A> >> >> Oh, sorry for another long delay. I disassemble the f= ile with ida,=0A> >> >> which is an amazing tool. I don't know if there is = open source=0A> >> >> alternative, please let me know if you find one.=0A> = >> >>=0A> >> >> The output from ida is in masm format, I modify it a bit so= that it=0A> >> >> can be compiled using nasm. Please note that nasm doesn'= t generate the=0A> >> >> same binary file as original one, but you can get = an idea what it=0A> >> >> does.=0A> >> >>=0A> >> >> From the output, the pr= ogram fails at the second int 13 call, int=0A> >> >> 13/ah =3D 48h. Althoug= h I notice that DL=3D0, which is not supposed to=0A> >> >> happen. Perhaps = you can add a grub_printf in grub_chainloader_boot to=0A> >> >> show the va= lue of boot drive:=0A> >> >>=0A> >> >> static grub_err_t=0A> >> >> grub_cha= inloader_boot (void)=0A> >> >> {=0A> >> >> grub_printf ("boot_drive=3D%d\= n", boot_drive);=0A> >> >> grub_chainloader_real_boot (boot_drive, boot_p= art_addr);=0A> >> >>=0A> >> >> /* Never reach here. */=0A> >> >> retur= n GRUB_ERR_NONE;=0A> >> >> }=0A> >> >>=0A> >> >> --=0A> >> >> Bean=0A> >> >= >=0A> >> >>=0A> >> >=0A> >> > Hi,=0A> >> >=0A> >> > The value of boot drive= is 0x80.=0A> >> >=0A> >> > This was the same value in disk->drive also.=0A= > >>=0A> >> Hi,=0A> >>=0A> >> Interesting, perhaps %dx is changed somewhere= . Please try the=0A> >> following patch, it dumps the value of %dx just bef= ore jumping to the=0A> >> boot sector.=0A> >>=0A> >> --=0A> >> Bean=0A> >= =0A> > The patch works and now Windows is booting perfectly fine from Grub2= .=0A> >=0A> > I will go through the assembly and try to understand what mod= ifications you =0A> have done.So there is a problem in Grub2 code, which ne= eds to be fixed ?=0A> >=0A> > Till this point, I was chainloading grub from= Grub2 and then chainloading =0A> Windows2008 from it.=0A> >=0A> > Thanks f= or the consistent help till this point and for the future also.=0A> =0A> Hi= ,=0A> =0A> That's strange, the patch doesn't do anything except output the = value of dx:=0A> =0A> /* set up to pass boot drive */=0A> popl %= edx=0A> + movl %edx, %edi=0A> =0A> /* ESI must point to a partiti= on table entry */=0A> popl %esi=0A> =0A> call prot_to_real=0A= > .code16=0A> +=0A> + push %dx=0A> + call hex_out=0A> + = push %di=0A> + call hex_out=0A> +=0A> ljmp $0, $GRUB_MEMORY= _MACHINE_BOOT_LOADER_ADDR=0A> +=0A> +hex_out:=0A> + pushw %bp=0A> + = movw %sp, %bp=0A> + pushaw=0A> + movb $0xE, %ah=0A> + mov= w $7, %bx=0A> + movw $4, %cx=0A> + movw 4(%bp), %dx=0A> +1:= =0A> + rol $4, %dx=0A> + movb %dl, %al=0A> + andb $0xF, %= al=0A> + cmpb $10, %al=0A> + jb 2f=0A> + subb $('0'-'A'+1= 0), %al=0A> +2:=0A> + addb $'0', %al=0A> + int $0x10=0A> + l= oop 1b=0A> + movb $' ', %al=0A> + int $0x10=0A> + popaw= =0A> + popw %bp=0A> + ret $2=0A> .code32=0A> =0A> #include = "../loader.S"=0A> =0A> Perhaps you can try:=0A> =0A> 1, %edi is used as bac= kup register in case %edx is changed by=0A> prot_to_real, you can remove "m= ovl %edx, %edi", "push %di", "call=0A> hex_out" and see if it still works.= =0A> =0A> 2, It's possible that the bug is position related, replace "push = %dx",=0A> "call hex_out" with equal number of nop and see what happens.=0A>= =0A> -- =0A> Bean=0A> =0A=0AWe can remove the patch completely, without pu= tting nop also, but just comment out the following code=0A=0A/*=0A xorl = %eax, %eax=0A call EXT_C(grub_gate_a20)=0A*/=0A=0AThis is the only= difference and when I comment out this, Windows boots up from Grub2.=0A=0A= Regards,=0AViswesh=0A=0A=0A Add more friends to your messenger and enj= oy! Go to http://messenger.yahoo.com/invite/ From MAILER-DAEMON Tue Oct 14 10:15:35 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpkgR-0002jE-6r for mharc-grub-devel@gnu.org; Tue, 14 Oct 2008 10:15:35 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpkgO-0002iW-Rv for grub-devel@gnu.org; Tue, 14 Oct 2008 10:15:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpkgN-0002hQ-9N for grub-devel@gnu.org; Tue, 14 Oct 2008 10:15:32 -0400 Received: from [199.232.76.173] (port=53620 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpkgM-0002hC-S2 for grub-devel@gnu.org; Tue, 14 Oct 2008 10:15:30 -0400 Received: from india245.server4you.de ([85.25.150.237]:47647 helo=hohwie.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KpkgM-000291-OF for grub-devel@gnu.org; Tue, 14 Oct 2008 10:15:30 -0400 Received: from localhost (hohwie.com [127.0.0.1]) by hohwie.com (Postfix) with ESMTP id 4297E7B404A for ; Tue, 14 Oct 2008 16:15:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at hohwie.com Received: from hohwie.com ([127.0.0.1]) by localhost (hohwie.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EnCwF4eHW9TI for ; Tue, 14 Oct 2008 16:15:16 +0200 (CEST) Received: by hohwie.com (Postfix, from userid 1000) id 0424F7B405B; Tue, 14 Oct 2008 16:15:16 +0200 (CEST) Date: Tue, 14 Oct 2008 16:15:20 +0200 X-OfflineIMAP-1859262923-6f7574626f78-494e424f582e6f7574626f78: 1223993722-00325148375612-v4.0.16 From: Joerg Hohwieler To: grub-devel@gnu.org Message-ID: <20081014141520.GD7080@hohwie.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Lines: 27 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: grub2 netboot & memtest X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 14:15:33 -0000 Hi, I'm trying to use grub2 (current svn) netboot to boot memtest86+-2.01. Netboot already works and the b/w menu shows up. here's my grub.cfg: .. snip .. set timeout=100 set default=0 menuentry "memtest86+-2.01" { linux /memtest86+-2.01 } .. snip .. When I execute this command, grub2 complains: error: too small lower memory (0x99100 > 0x89000) What's wrong? What is the correct grub.cfg entry for booting memtest86+ ? Best regards, joerg From MAILER-DAEMON Wed Oct 15 01:43:49 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpzAj-0008BD-CQ for mharc-grub-devel@gnu.org; Wed, 15 Oct 2008 01:43:49 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpzAh-00089L-5u for grub-devel@gnu.org; Wed, 15 Oct 2008 01:43:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpzAg-00088A-2E for grub-devel@gnu.org; Wed, 15 Oct 2008 01:43:46 -0400 Received: from [199.232.76.173] (port=49005 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpzAf-00087z-RG for grub-devel@gnu.org; Wed, 15 Oct 2008 01:43:45 -0400 Received: from gateway03.websitewelcome.com ([69.93.37.21]:54775) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KpzAf-0007X2-SU for grub-devel@gnu.org; Wed, 15 Oct 2008 01:43:46 -0400 Received: (qmail 4396 invoked from network); 15 Oct 2008 05:58:36 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway03.websitewelcome.com with SMTP; 15 Oct 2008 05:58:36 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:39573 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KpzAa-0001KS-6K for grub-devel@gnu.org; Wed, 15 Oct 2008 00:43:40 -0500 Date: Tue, 14 Oct 2008 22:42:51 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081014224251.78ee2aa0@gibibit.com> In-Reply-To: <48F3B98E.4060109@nic.fi> References: <20080831000157.0c548199@gamma.lan> <48BAC517.4060002@nic.fi> <48BD5F00.9090902@nic.fi> <48E67DB3.8030408@nic.fi> <20081013100010.22d1dc54@gibibit.com> <48F39322.8060508@nic.fi> <20081013130005.2adac4b2@gibibit.com> <48F3B98E.4060109@nic.fi> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.3; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/2J8IndUJZ2BPQU.RryFkaOz"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #09 Bitmap scaling X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2008 05:43:47 -0000 --Sig_/2J8IndUJZ2BPQU.RryFkaOz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 14 Oct 2008 00:11:42 +0300 Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > Colin D Bennett wrote: > > On Mon, 13 Oct 2008 21:27:46 +0300 > > Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > >> Idea is that if bitmap is still locked you cannot optimize it or > >> you cannot lock it again. And if bitmap is optimized you cannot get > >> pointer to modify it. Eg. Function call returns memory pointer. > >=20 > > I thought perhaps the 'optimize' operation would simply return a > > _new_ (and completely independent from that point forward) bitmap > > equivalent to the input bitmap but in the same format as the > > current video mode uses. >=20 > Problem with that is that it makes supporting code harder to use. With > only handful of supported formats it much easier to write support code > to modify bitmap. If you allow to use any format supported by video > subsystem it is nightmare to support them all. >=20 > So if we just support two formats. We only need to care about RGB and > RGBA formats, rather easy task. Can be modified by using simple loops > or indexing. When we know that there is no modifications to be done > for bitmap, we can just call optimize() and it will convert (edited) > bitmap to fast to blit format. A minor point: You mentioned "RGB" and "RGBA" format--do you mean "true color" (either RGB[A] or BGR[A] layout) or do you mean literal RGB byte order? If we are talking about picking a single component order to standardize on, it should be BGR[A]. Every video adapter I have tested on so far (nVidia 7600GT, VIA Unichrome, VMware, QEMU) has supported BGRA (32 bpp) or BGR (24 bpp) but not RGBA or RGB. Perhaps others have found the contrary to be true; if so I would like to know. > As we have same handle all the time for bitmap we can just continue to > use it as is. If we would make new instance of it, would either need > to delete previous one and replace its usage with new one. Of course > use case here affects. Ok. That's fine. I'm still a little confused about the purpose of lock/unlock, however. Is it basically a way of catching mistakes in the code where we accidentally try to modify bitmap data when we don't want to? I guess what I'm asking is, do lock/unlock do anything more than set a flag that is checked, as in: (pseudocode) void *get_ptr(bitmap b) { if (b.optimized) return error(); return b.ptr;=20 } void optimize(bitmap b) { if (b.locked) error(); /* optimize b... */ } void lock(bitmap b) { if (b.locked) error(); b.locked =3D 1;=20 } void unlock(bitmap b) { b.locked =3D 0; } > > Are you thinking that it would be best to have the > > 'optimize'/'unoptimize' operations actually just modify the bitmap > > in place? I guess this is nice from a memory conservation > > standpoint, but in some cases it wouldn't work well (i.e., 24-bit > > to 32-bit formats). >=20 > I do not think at this point how optimize() or unoptimize() will be > implemented. Just general idea. Whether it is in-place operation or > re-allocation for memory, is same to me. It just have to work :) Ok. Another idea: What if the image-loading functions automatically optimize()'d the bitmaps when loaded, since we don't normally expect to modify loaded bitmaps before display. Then most all the bitmaps in use would automatically get the performance benefit with no change to all the users of the code. The only thing we do with loaded images is the scale them and blit them. The scaling algorithms can easily work on any 24 or 32 bit color mode without knowing details of which components are which (the process is the same regardless of the color component). Thus optimized images could still be scaled highly efficiently (without an unoptimize->scale->optimize process). For 15/16 bit or indexed color modes, we would have to unopt->scale->opt, but I really think that no one should be using those modes. If your video memory is too limited for 24 or 32 bit color, then just use the perfectly great text mode menu. Regards, Colin --Sig_/2J8IndUJZ2BPQU.RryFkaOz Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj1gt0ACgkQokx8fzcGbYezVQCdGu0K3ahRgGVfNcjb/0o/tsZV PNcAnimE+U64/OimbpQN/oDKFWML3zqT =dLr6 -----END PGP SIGNATURE----- --Sig_/2J8IndUJZ2BPQU.RryFkaOz-- From MAILER-DAEMON Wed Oct 15 10:34:20 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kq7S8-00078G-0G for mharc-grub-devel@gnu.org; Wed, 15 Oct 2008 10:34:20 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kq7S5-00077o-KQ for grub-devel@gnu.org; Wed, 15 Oct 2008 10:34:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kq7S3-00077I-Mr for grub-devel@gnu.org; Wed, 15 Oct 2008 10:34:17 -0400 Received: from [199.232.76.173] (port=39402 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kq7S3-00077E-EO for grub-devel@gnu.org; Wed, 15 Oct 2008 10:34:15 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:52783 helo=kirsi2.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kq7S2-0007jg-SI for grub-devel@gnu.org; Wed, 15 Oct 2008 10:34:15 -0400 Received: from [127.0.0.1] (84.248.105.254) by kirsi2.inet.fi (8.5.014) id 48DA300B01198061 for grub-devel@gnu.org; Wed, 15 Oct 2008 17:34:09 +0300 Message-ID: <48F5FF64.6010500@nic.fi> Date: Wed, 15 Oct 2008 17:34:12 +0300 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <20080831000157.0c548199@gamma.lan> <48BAC517.4060002@nic.fi> <48BD5F00.9090902@nic.fi> <48E67DB3.8030408@nic.fi> <20081013100010.22d1dc54@gibibit.com> <48F39322.8060508@nic.fi> <20081013130005.2adac4b2@gibibit.com> <48F3B98E.4060109@nic.fi> <20081014224251.78ee2aa0@gibibit.com> In-Reply-To: <20081014224251.78ee2aa0@gibibit.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #09 Bitmap scaling X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2008 14:34:18 -0000 Colin D Bennett wrote: > On Tue, 14 Oct 2008 00:11:42 +0300 > Vesa J=E4=E4skel=E4inen wrote: > A minor point: You mentioned "RGB" and "RGBA" format--do you mean "tru= e > color" (either RGB[A] or BGR[A] layout) or do you mean literal RGB byte > order? If we are talking about picking a single component order to > standardize on, it should be BGR[A]. Every video adapter I have tested > on so far (nVidia 7600GT, VIA Unichrome, VMware, QEMU) has supported > BGRA (32 bpp) or BGR (24 bpp) but not RGBA or RGB. Perhaps others have > found the contrary to be true; if so I would like to know. As I stated before order is not an issue. We can use BGR[A]. I am just used to speak about RGB :) >> As we have same handle all the time for bitmap we can just continue to >> use it as is. If we would make new instance of it, would either need >> to delete previous one and replace its usage with new one. Of course >> use case here affects. >=20 > Ok. That's fine. I'm still a little confused about the purpose of > lock/unlock, however. Is it basically a way of catching mistakes in > the code where we accidentally try to modify bitmap data when we don't > want to? I guess what I'm asking is, do lock/unlock do anything more > than set a flag that is checked, as in: (pseudocode) >=20 >=20 > void *get_ptr(bitmap b) > { > if (b.optimized) return error(); > return b.ptr;=20 > } > void optimize(bitmap b) > { > if (b.locked) error(); > /* optimize b... */ > } > void lock(bitmap b) > { > if (b.locked) error(); > b.locked =3D 1;=20 > } > void unlock(bitmap b) { b.locked =3D 0; } No, more like: void *lock(bitmap b) { if (b.locked) return NULL; if (b.optimized) return NULL; b.locked =3D 1; return b.dataptr; } void unlock(bitmap b) { b.locked =3D 0; } grub_err_t optimize(bitmap b, rendertarget r) { if (b.locked) return error; if (b.optimized) return error; // do magic b.optimized =3D 1; return success; } Now one would use it like: ptr =3D lock(); if (ptr) { // modify it. ptr[0] =3D blue; ptr[1] =3D green; ptr[2] =3D red; if (has_alpha) ptr[3] =3D alpha; unlock(); } >>> Are you thinking that it would be best to have the >>> 'optimize'/'unoptimize' operations actually just modify the bitmap >>> in place? I guess this is nice from a memory conservation >>> standpoint, but in some cases it wouldn't work well (i.e., 24-bit >>> to 32-bit formats). >> I do not think at this point how optimize() or unoptimize() will be >> implemented. Just general idea. Whether it is in-place operation or >> re-allocation for memory, is same to me. It just have to work :) >=20 > Ok. >=20 > Another idea: What if the image-loading functions automatically > optimize()'d the bitmaps when loaded, since we don't normally expect to > modify loaded bitmaps before display. Then most all the bitmaps in use > would automatically get the performance benefit with no change to all > the users of the code. The only thing we do with loaded images is the > scale them and blit them. No. If user has low color mode optimize will really make image look ugly. So best to postpone this conversion to far as possible. > The scaling algorithms can easily work on any 24 or 32 bit color mode > without knowing details of which components are which (the process is > the same regardless of the color component). Thus optimized images > could still be scaled highly efficiently (without an > unoptimize->scale->optimize process). For 15/16 bit or indexed color > modes, we would have to unopt->scale->opt, but I really think that no > one should be using those modes. If your video memory is too limited > for 24 or 32 bit color, then just use the perfectly great text mode > menu. I would still like to support all RGB modes. Indexed color modes are just backup option. From MAILER-DAEMON Wed Oct 15 14:41:32 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KqBJL-0000cv-O5 for mharc-grub-devel@gnu.org; Wed, 15 Oct 2008 14:41:31 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KqBJJ-0000cE-9W for grub-devel@gnu.org; Wed, 15 Oct 2008 14:41:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KqBJG-0000bU-Pm for grub-devel@gnu.org; Wed, 15 Oct 2008 14:41:27 -0400 Received: from [199.232.76.173] (port=52285 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KqBJG-0000bP-Bs for grub-devel@gnu.org; Wed, 15 Oct 2008 14:41:26 -0400 Received: from lax-green-bigip-5.dreamhost.com ([208.113.200.5]:37760 helo=blingymail-a3.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KqBJF-0001Ci-Uz for grub-devel@gnu.org; Wed, 15 Oct 2008 14:41:26 -0400 Received: from jidanni1.jidanni.org (122-127-35-52.dynamic.hinet.net [122.127.35.52]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by blingymail-a3.g.dreamhost.com (Postfix) with ESMTP id 680C114D78E for ; Wed, 15 Oct 2008 11:41:24 -0700 (PDT) To: grub-devel@gnu.org References: <87bpxru9w3.fsf@jidanni.org> From: jidanni@jidanni.org Date: Thu, 16 Oct 2008 02:41:22 +0800 Message-ID: <8763ntitv1.fsf@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) Subject: Re: forgot passwd, cannot login, [rd]init=/bin/sh don't work X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2008 18:41:29 -0000 Can somebody please integrate my patches? For the parent article and the "grub-install message should mention --recheck" article. I am a mere "apt-get install" user. I fear if I learn your whole source code system, and finally make an official patch, it too will fall on deaf ears. As I expect I will only have one patch per three years, please integrate it for me. Thanks. From MAILER-DAEMON Wed Oct 15 15:13:45 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KqBoX-0008Iu-0v for mharc-grub-devel@gnu.org; Wed, 15 Oct 2008 15:13:45 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KqBoV-0008IN-EB for grub-devel@gnu.org; Wed, 15 Oct 2008 15:13:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KqBoT-0008Ho-Sj for grub-devel@gnu.org; Wed, 15 Oct 2008 15:13:43 -0400 Received: from [199.232.76.173] (port=47239 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KqBoT-0008Hl-Qv for grub-devel@gnu.org; Wed, 15 Oct 2008 15:13:41 -0400 Received: from arnold.marlboro.edu ([206.192.68.78]:54258) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KqBoT-00089H-Jm for grub-devel@gnu.org; Wed, 15 Oct 2008 15:13:41 -0400 Received: from akbar.marlboro.edu (akbar.marlboro.edu [10.1.2.5]) by arnold.marlboro.edu (Postfix) with ESMTP id 844ED17A0A3 for ; Wed, 15 Oct 2008 15:13:33 -0400 (EDT) Received: from xyz.marlboro.edu (xyz.marlboro.edu [10.1.2.29]) by akbar.marlboro.edu (Postfix) with ESMTP id 7F09B11E558 for ; Wed, 15 Oct 2008 15:13:33 -0400 (EDT) Received: from [10.1.4.50] (mdhcp50.marlboro.edu [10.1.4.50]) by xyz.marlboro.edu (Postfix) with ESMTP id 689373AC01C for ; Wed, 15 Oct 2008 15:13:30 -0400 (EDT) Message-ID: <48F640DA.90202@isaac.cedarswampstudios.org> Date: Wed, 15 Oct 2008 15:13:30 -0400 From: Isaac Dupree User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: The development of GRUB 2 References: <874p3ki1vk.fsf@jidanni.org> In-Reply-To: <874p3ki1vk.fsf@jidanni.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Marlboro-MailScanner-Information: Please contact techsupport@marlboro.edu for more information X-Marlboro-MailScanner: Found to be clean, clean X-Marlboro-Information: Please contact techsupport@marlboro.edu for more information X-Marlboro-MailScanner-ID: 844ED17A0A3.8E08B X-Marlboro-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.399, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Marlboro-MailScanner-From: ml@isaac.cedarswampstudios.org X-Marlboro-MailScanner-Watermark: 1224702814.10774@o4AddxqeljGe3iVu187jgg X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: Re: grub-install message should mention --recheck X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2008 19:13:44 -0000 jidanni@jidanni.org wrote: > Please implement these changes in making this typical grub-install > message. Thanks. > > # grub-install /dev/hda > Installation finished. No error reported. > This is the contents of the device map /boot/grub/device.map. > - Check if this is correct or not. If any of the lines is incorrect, > - fix it and re-run the script `grub-install'. > + If not correct try --recheck, or fix and rerun. but the original message was much more clear about what you should do. And what do you mean by --recheck.. is this correct interpretation?: -- Check if this is correct or not. If any of the lines is incorrect, try `grub-install --recheck` (or is it `grub-install --recheck /dev/hda`?). Or (under what circumstances should you try which solution?) edit /boot/grub/device.map, and then re-run grub-install (i.e., `grub-install /dev/hda`). -Isaac From MAILER-DAEMON Wed Oct 15 17:32:27 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KqDyl-0003VR-BX for mharc-grub-devel@gnu.org; Wed, 15 Oct 2008 17:32:27 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KqDyj-0003UH-7M for grub-devel@gnu.org; Wed, 15 Oct 2008 17:32:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KqDyh-0003Te-Nu for grub-devel@gnu.org; Wed, 15 Oct 2008 17:32:24 -0400 Received: from [199.232.76.173] (port=49121 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KqDyh-0003Tb-L1 for grub-devel@gnu.org; Wed, 15 Oct 2008 17:32:23 -0400 Received: from lax-green-bigip-5.dreamhost.com ([208.113.200.5]:52968 helo=blingymail-a1.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KqDyh-0001yz-Ik for grub-devel@gnu.org; Wed, 15 Oct 2008 17:32:23 -0400 Received: from jidanni1.jidanni.org (122-127-35-52.dynamic.hinet.net [122.127.35.52]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by blingymail-a1.g.dreamhost.com (Postfix) with ESMTP id E16EF5CF2D for ; Wed, 15 Oct 2008 14:32:19 -0700 (PDT) To: grub-devel@gnu.org References: <48F640DA.90202@isaac.cedarswampstudios.org> From: jidanni@jidanni.org Date: Thu, 16 Oct 2008 05:32:17 +0800 Message-ID: <87k5c9h7dq.fsf@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) Subject: Re: grub-install message should mention --recheck X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2008 21:32:25 -0000 ID> try `grub-install --recheck` (or is it `grub-install --recheck Thanks. I am trying to say that four out of five times "adding --recheck to the invocation" will do what the user wants, instead of needing him to fire up an editor. So please mention it somehow. From MAILER-DAEMON Fri Oct 17 08:26:24 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KqoPQ-00021z-Ia for mharc-grub-devel@gnu.org; Fri, 17 Oct 2008 08:26:24 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KqoPP-00021n-EO for grub-devel@gnu.org; Fri, 17 Oct 2008 08:26:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KqoPO-00021O-AA for grub-devel@gnu.org; Fri, 17 Oct 2008 08:26:22 -0400 Received: from [199.232.76.173] (port=54332 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KqoPO-00021L-4l for grub-devel@gnu.org; Fri, 17 Oct 2008 08:26:22 -0400 Received: from mail-gx0-f10.google.com ([209.85.217.10]:57750) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KqoPN-0003tQ-Ht for grub-devel@gnu.org; Fri, 17 Oct 2008 08:26:22 -0400 Received: by gxk3 with SMTP id 3so968378gxk.18 for ; Fri, 17 Oct 2008 05:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:content-class :from:subject:date:importance:x-priority:to :content-transfer-encoding:content-type:message-id; bh=TzFrd6BOZZ5iVHewxncFBFLrPeJM2hnnwETxtzzdyDs=; b=MSCvOpR9bDhz3/vOPAp3kWhJLgS2uEQQkmeHyNQwWBNCJUDc12MjlJ6dsk2QawtfDV wJAs0SyO2w4OXyp5ZXXAgxfvQKpXuCMEwmgfDBaTjA1Ir+wlmryNH8pLK/nPVUN6H+5h L6fKRNRFcUkxD0/z9ZxbQs6mg4BDYA9mS39ns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:content-class:from:subject:date:importance:x-priority :to:content-transfer-encoding:content-type:message-id; b=ON1yaJDBPIQ6nhIBN/jQhWRbg16qg6YZEWqV+MPXQxOyaRP57TQyASugZRLJ0rvSRw jOBevI7r1v578ZNmGCH2Fwwf8irbQh5UdvcUz7oeHFkQ0HF2vz/FSE1ZnSX7Uig4hJ26 5RFEo1yAWGzXn/x1njC7eyg80m0nXeLEwVsbA= Received: by 10.100.164.12 with SMTP id m12mr5047611ane.144.1224246379468; Fri, 17 Oct 2008 05:26:19 -0700 (PDT) Received: from Inbox (174-146-80-11.area3.spcsdns.net [174.146.80.11]) by mx.google.com with ESMTPS id 4sm6087600yxj.7.2008.10.17.05.26.15 (version=SSLv3 cipher=RC4-MD5); Fri, 17 Oct 2008 05:26:17 -0700 (PDT) MIME-Version: 1.0 content-class: From: James Shewey Date: Fri, 17 Oct 2008 08:26:27 -0400 Importance: normal X-Priority: 3 To: The development of GRUB 2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Message-ID: <48f88469.4403be0a.4f8a.ffffe15a@mx.google.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: RE: forgot passwd, cannot login, [rd]init=/bin/sh don't work X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2008 12:26:23 -0000 Grub does not manage ubuntu or debian's (or any other distribution's) repos= itories and has no control over how often these distros recompile and upda= te these packages. Only their own codebase which is stored in their svn cod= ebase. Debian'snewest package is a little out of date, and ubuntu's newest = package is _really_ out of date. This means that your patch may have alrea= dy installed your patch in the grub2 codebase and by installing fro your di= stributon's repository, you wouldn't even know. This means that you can ei= ther a) file a bug report with your distrbution and wait for the package t= o propigate (which cold take up to 6 mos for ubuntu for the jaunty jackalop= e 9.04 release and even longer for debian, depending. You could speed this = up by running the alpha version of your distro, but this is not recommended= .) or b) break down and install from grub2 svn. Installing from svn is not = very hard. The commands are: svn co http://url Cd grub2 ./configure make sudo make install You would need to look up the url for the grub svn though. Also be aware th= at grub2 will not compile on a 64 bit system yet. James -----Original Message----- From: jidanni@jidanni.org Sent: Wednesday, October 15, 2008 2:41 PM To: grub-devel@gnu.org Subject: Re: forgot passwd, cannot login, [rd]init=3D/bin/sh don't work Can somebody please integrate my patches? For the parent article and the "grub-install message should mention --recheck" article. I am a mere "apt-get install" user. I fear if I learn your whole source code system, and finally make an official patch, it too will fall on deaf ears. As I expect I will only have one patch per three years, please integrate it for me. Thanks. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel From MAILER-DAEMON Fri Oct 17 23:44:48 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kr2kC-0007bn-IS for mharc-grub-devel@gnu.org; Fri, 17 Oct 2008 23:44:48 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kr2k9-0007b8-QZ for grub-devel@gnu.org; Fri, 17 Oct 2008 23:44:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kr2k8-0007am-V5 for grub-devel@gnu.org; Fri, 17 Oct 2008 23:44:45 -0400 Received: from [199.232.76.173] (port=51499 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kr2k8-0007ah-M8 for grub-devel@gnu.org; Fri, 17 Oct 2008 23:44:44 -0400 Received: from fg-out-1718.google.com ([72.14.220.152]:42521) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kr2k8-0007Re-Dw for grub-devel@gnu.org; Fri, 17 Oct 2008 23:44:44 -0400 Received: by fg-out-1718.google.com with SMTP id l26so667635fgb.30 for ; Fri, 17 Oct 2008 20:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=M8cq0XfCI2iCUbYryaeX5bhp7n39U3LA3sHHGUMbTfw=; b=hw6gwDjMeP6OZz07LtrnyHvudLxXdPPhcfNwhdLghqy4K0XYOv8cuTXKtv5ukamAin BbaqDSqul6DMnILtVSUZ18HLeCMCVkzjRsMXT5/1drUz3VLOtV1GDhBy1E5ZvIFtKxIO WpGgWAP7K4no+afD3g/fQVOQNnltBtpZC0xpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=w7le3GMnW3PLfr2EnC3jjT83CT0u+PTgUpkG2uA2vD11ngfhipA11OJuNLVofENO8z Q/Bsafv0pExyG8zbw8p2QkSRiXj0uC4zldt1j+OgPpxfkXbxmAuwmVurdJfuJjumESdD R9Mf6HzMARjeqv3al2aG9Yljy2IhMoRkZftPc= Received: by 10.181.146.11 with SMTP id y11mr1841737bkn.60.1224301481463; Fri, 17 Oct 2008 20:44:41 -0700 (PDT) Received: by 10.181.15.13 with HTTP; Fri, 17 Oct 2008 20:44:41 -0700 (PDT) Message-ID: Date: Sat, 18 Oct 2008 13:44:41 +1000 From: "Cameron Braid" Sender: cbraid@gmail.com To: "The development of GRUB 2" In-Reply-To: <48f88469.4403be0a.4f8a.ffffe15a@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10416_30409371.1224301481431" References: <48f88469.4403be0a.4f8a.ffffe15a@mx.google.com> X-Google-Sender-Auth: e572e68f252bbba1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: forgot passwd, cannot login, [rd]init=/bin/sh don't work X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2008 03:44:46 -0000 ------=_Part_10416_30409371.1224301481431 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Oct 17, 2008 at 10:26 PM, James Shewey wrote: > Grub does not manage ubuntu or debian's (or any other distribution's) > repositories and has no control over how often these distros recompile and > update these packages. Only their own codebase which is stored in their svn > codebase. Debian'snewest package is a little out of date, and ubuntu's > newest package is _really_ out of date. This means that your patch may have > already installed your patch in the grub2 codebase and by installing fro > your distributon's repository, you wouldn't even know. This means that you > can either a) file a bug report with your distrbution and wait for the > package to propigate (which cold take up to 6 mos for ubuntu for the jaunty > jackalope 9.04 release and even longer for debian, depending. You could > speed this up by running the alpha version of your distro, but this is not > recommended.) or b) break down and install from grub2 svn. Installing from > svn is not very hard. The commands are: > > svn co http://url > Cd grub2 > ./configure > make > sudo make install > > You would need to look up the url for the grub svn though. Also be aware > that grub2 will not compile on a 64 bit system yet. > cameronbraid@beast:grub2$ svn info Path: . URL: svn://svn.sv.gnu.org/grub/trunk/grub2 Repository Root: svn://svn.sv.gnu.org/grub Repository UUID: d0de0278-0dc1-4c01-8a07-af38b3205e46 Revision: 1886 Node Kind: directory Schedule: normal Last Changed Author: robertmh Last Changed Rev: 1886 Last Changed Date: 2008-10-05 20:51:23 +1000 (Sun, 05 Oct 2008) cameronbraid@beast:grub2$ uname -a Linux beast 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 *x86_64*GNU/Linux Compiles fine for me Cameron > > James > > -----Original Message----- > From: jidanni@jidanni.org > Sent: Wednesday, October 15, 2008 2:41 PM > To: grub-devel@gnu.org > Subject: Re: forgot passwd, cannot login, [rd]init=/bin/sh don't work > > Can somebody please integrate my patches? For the parent article and > the "grub-install message should mention --recheck" article. > > I am a mere "apt-get install" user. I fear if I learn your whole > source code system, and finally make an official patch, it too will > fall on deaf ears. > > As I expect I will only have one patch per three years, please > integrate it for me. Thanks. > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ------=_Part_10416_30409371.1224301481431 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Fri, Oct 17, 2008 at 10:26 PM, James Shewey <jdshewey@gmail.com> wrote:
Grub does not manage ubuntu or debian's (or any other distribution's) repositories and has no control  over how often these distros recompile and update these packages. Only their own codebase which is stored in their svn codebase. Debian'snewest package is a little out of date, and ubuntu's newest  package is _really_ out of date. This means that your patch may have already installed your patch in the grub2 codebase and by installing fro your distributon's repository, you wouldn't even know. This means that you can  either  a) file a bug report with your distrbution and wait for the package to propigate (which cold take up to 6 mos for ubuntu for the jaunty jackalope 9.04 release and even longer for debian, depending. You could speed this up by running the alpha version of your distro, but this is not recommended.) or b) break down and install from grub2 svn. Installing from svn is not very hard. The commands are:

svn co http://url
Cd grub2
./configure
make
sudo make install

You would need to look up the url for the grub svn though. Also be aware that grub2 will not compile on a 64 bit system yet.

cameronbraid@beast:grub2$ svn info
Path: .
URL: svn://svn.sv.gnu.org/grub/trunk/grub2
Repository Root: svn://svn.sv.gnu.org/grub
Repository UUID: d0de0278-0dc1-4c01-8a07-af38b3205e46
Revision: 1886
Node Kind: directory
Schedule: normal
Last Changed Author: robertmh
Last Changed Rev: 1886
Last Changed Date: 2008-10-05 20:51:23 +1000 (Sun, 05 Oct 2008)

cameronbraid@beast:grub2$ uname -a
Linux beast 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64 GNU/Linux

Compiles fine for me

Cameron


 

James

-----Original Message-----
From: jidanni@jidanni.org
Sent: Wednesday, October 15, 2008 2:41 PM
To: grub-devel@gnu.org
Subject: Re: forgot passwd, cannot login, [rd]init=/bin/sh don't work

Can somebody please integrate my patches? For the parent article and
the "grub-install message should mention --recheck" article.

I am a mere "apt-get install" user. I fear if I learn your whole
source code system, and finally make an official patch, it too will
fall on deaf ears.

As I expect I will only have one patch per three years, please
integrate it for me. Thanks.


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel



_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

------=_Part_10416_30409371.1224301481431-- From MAILER-DAEMON Sat Oct 18 08:20:42 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KrAnS-0003KL-Dd for mharc-grub-devel@gnu.org; Sat, 18 Oct 2008 08:20:42 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KrAnP-0003Jq-Qt for grub-devel@gnu.org; Sat, 18 Oct 2008 08:20:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KrAnO-0003JW-3w for grub-devel@gnu.org; Sat, 18 Oct 2008 08:20:38 -0400 Received: from [199.232.76.173] (port=39592 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KrAnN-0003JM-Ur for grub-devel@gnu.org; Sat, 18 Oct 2008 08:20:38 -0400 Received: from ey-out-1920.google.com ([74.125.78.145]:37125) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KrAnN-0001CB-Ds for grub-devel@gnu.org; Sat, 18 Oct 2008 08:20:37 -0400 Received: by ey-out-1920.google.com with SMTP id 4so339518eyg.24 for ; Sat, 18 Oct 2008 05:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:x-mailer:mime-version:subject:date :references; bh=YabKsPMNvvBiQsCeqFyPpM/FtfbTn6D0iYwDYJC1zuY=; b=b2ZKl4N38grAIMMOZQ1rGHBuFPhgd64GDqKd27IUYfI7/xx6iOWX3joBlFJyDDEoV5 Eq+PJcQzxk4qJaWY+eBLCJTsqmC6HAA/DXB15fHdIe5c1NJkjVFmAH6+cX3wb04OnWtU +Ua08+Lf0JckMeO7wSXvDxVRDUXv6xdCCkDfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type:x-mailer:mime-version :subject:date:references; b=EklAvS/kywvC50gpsfm1XS2HFS7iLftwZmE1Z1CMSRmSiMVxNW9MpyxY2QnjFCWcsQ yrGrB0/nImornbwGphuI+NOVbLfo8Q4o4S0bNRx/KE/eEhJ9Db5wrdlZu0TWm1MGsMZ+ iBXFCzAdt1a3L1BEBlMZ5Cx8UDWdAO7i8QaMU= Received: by 10.210.119.5 with SMTP id r5mr5825810ebc.89.1224332435938; Sat, 18 Oct 2008 05:20:35 -0700 (PDT) Received: from ?10.42.17.143? ([82.132.136.211]) by mx.google.com with ESMTPS id k10sm3385224nfh.25.2008.10.18.05.20.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 18 Oct 2008 05:20:34 -0700 (PDT) Message-Id: <658C52F1-025A-484D-8C7C-646D0B974B58@gmail.com> From: Steven Trotter To: The development of GRUB 2 In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1--935391801 X-Mailer: iPhone Mail (5F136) Mime-Version: 1.0 (iPhone Mail 5F136) Date: Sat, 18 Oct 2008 13:20:25 +0100 References: <48f88469.4403be0a.4f8a.ffffe15a@mx.google.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: forgot passwd, cannot login, [rd]init=/bin/sh don't work X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2008 12:20:40 -0000 --Apple-Mail-1--935391801 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit What does the configure script output for the lines that say Checking build/host/target system type ... Steve On 18 Oct 2008, at 04:44, "Cameron Braid" wrote: > > > On Fri, Oct 17, 2008 at 10:26 PM, James Shewey > wrote: > Grub does not manage ubuntu or debian's (or any other > distribution's) repositories and has no control over how often > these distros recompile and update these packages. Only their own > codebase which is stored in their svn codebase. Debian'snewest > package is a little out of date, and ubuntu's newest package is > _really_ out of date. This means that your patch may have already > installed your patch in the grub2 codebase and by installing fro > your distributon's repository, you wouldn't even know. This means > that you can either a) file a bug report with your distrbution and > wait for the package to propigate (which cold take up to 6 mos for > ubuntu for the jaunty jackalope 9.04 release and even longer for > debian, depending. You could speed this up by running the alpha > version of your distro, but this is not recommended.) or b) break > down and install from grub2 svn. Installing from svn is not very > hard. The commands are: > > svn co http://url > Cd grub2 > ./configure > make > sudo make install > > You would need to look up the url for the grub svn though. Also be > aware that grub2 will not compile on a 64 bit system yet. > > cameronbraid@beast:grub2$ svn info > Path: . > URL: svn://svn.sv.gnu.org/grub/trunk/grub2 > Repository Root: svn://svn.sv.gnu.org/grub > Repository UUID: d0de0278-0dc1-4c01-8a07-af38b3205e46 > Revision: 1886 > Node Kind: directory > Schedule: normal > Last Changed Author: robertmh > Last Changed Rev: 1886 > Last Changed Date: 2008-10-05 20:51:23 +1000 (Sun, 05 Oct 2008) > > cameronbraid@beast:grub2$ uname -a > Linux beast 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 > x86_64 GNU/Linux > > Compiles fine for me > > Cameron > > > > > James > > -----Original Message----- > From: jidanni@jidanni.org > Sent: Wednesday, October 15, 2008 2:41 PM > To: grub-devel@gnu.org > Subject: Re: forgot passwd, cannot login, [rd]init=/bin/sh don't work > > Can somebody please integrate my patches? For the parent article and > the "grub-install message should mention --recheck" article. > > I am a mere "apt-get install" user. I fear if I learn your whole > source code system, and finally make an official patch, it too will > fall on deaf ears. > > As I expect I will only have one patch per three years, please > integrate it for me. Thanks. > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel --Apple-Mail-1--935391801 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
What does the configure script output for the lines that say

Checking build/host/target system type ...

Steve

On 18 Oct 2008, at 04:44, "Cameron Braid" <cameron@braid.com.au> wrote:



On Fri, Oct 17, 2008 at 10:26 PM, James Shewey <jdshewey@gmail.com> wrote:
Grub does not manage ubuntu or debian's (or any other distribution's) repositories and has no control  over how often these distros recompile and update these packages. Only their own codebase which is stored in their svn codebase. Debian'snewest package is a little out of date, and ubuntu's newest  package is _really_ out of date. This means that your patch may have already installed your patch in the grub2 codebase and by installing fro your distributon's repository, you wouldn't even know. This means that you can  either  a) file a bug report with your distrbution and wait for the package to propigate (which cold take up to 6 mos for ubuntu for the jaunty jackalope 9.04 release and even longer for debian, depending. You could speed this up by running the alpha version of your distro, but this is not recommended.) or b) break down and install from grub2 svn. Installing from svn is not very hard. The commands are:

svn co http://url
Cd grub2
./configure
make
sudo make install

You would need to look up the url for the grub svn though. Also be aware that grub2 will not compile on a 64 bit system yet.

cameronbraid@beast:grub2$ svn info
Path: .
URL: svn://svn.sv.gnu.org/grub/trunk/grub2
Repository Root: svn://svn.sv.gnu.org/grub
Repository UUID: d0de0278-0dc1-4c01-8a07-af38b3205e46
Revision: 1886
Node Kind: directory
Schedule: normal
Last Changed Author: robertmh
Last Changed Rev: 1886
Last Changed Date: 2008-10-05 20:51:23 +1000 (Sun, 05 Oct 2008)

cameronbraid@beast:grub2$ uname -a
Linux beast 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64 GNU/Linux

Compiles fine for me

Cameron


 

James

-----Original Message-----
From: jidanni@jidanni.org
Sent: Wednesday, October 15, 2008 2:41 PM
To: grub-devel@gnu.org
Subject: Re: forgot passwd, cannot login, [rd]init=/bin/sh don't work

Can somebody please integrate my patches? For the parent article and
the "grub-install message should mention --recheck" article.

I am a mere "apt-get install" user. I fear if I learn your whole
source code system, and finally make an official patch, it too will
fall on deaf ears.

As I expect I will only have one patch per three years, please
integrate it for me. Thanks.


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel



_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--Apple-Mail-1--935391801-- From MAILER-DAEMON Mon Oct 20 09:54:28 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KrvDI-0003OL-IS for mharc-grub-devel@gnu.org; Mon, 20 Oct 2008 09:54:28 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KrvDG-0003Lp-8p for grub-devel@gnu.org; Mon, 20 Oct 2008 09:54:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KrvDF-0003L1-Hy for grub-devel@gnu.org; Mon, 20 Oct 2008 09:54:25 -0400 Received: from [199.232.76.173] (port=59119 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KrvDF-0003Ky-F3 for grub-devel@gnu.org; Mon, 20 Oct 2008 09:54:25 -0400 Received: from qb-out-1314.google.com ([72.14.204.173]:6752) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KrvDF-0003KG-24 for grub-devel@gnu.org; Mon, 20 Oct 2008 09:54:25 -0400 Received: by qb-out-1314.google.com with SMTP id f16so1679601qba.30 for ; Mon, 20 Oct 2008 06:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=/ZsLG15ePYj4eF6Q2ToEAeQICYN2wps2WVV46+20jps=; b=p0ddXECnMyn98cKeUQXU9t3PLd/M5FT2XMSOSks2AV4N2gIX3FjtQmXiPWFFdxeblb Wu5LBlaAbCkufeNY5w+IHRbeUfP9W3RP38BRlCIwryOrty+TqQJHa7wHos59+HA/o/lq thmjg8QyBvsqKOcAvz24jg+ZSEHSqBI+Ne7aY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=JA49KbWC4jKk7knf8ogYasnQpkOD/MnUuZHLYyYzSgi6xnKi8HZrSyN+dnyk42QGiQ +n6Ez+fPR2KmizKsps5+PxjqWocXW/iN1Z9YzYTa7+3/N9NcuTv3HFQwwArQ1Ibi/N7A 8Uw6bNwqetSLYFwTVS+xnDwV/Wj1KVVmatV1w= Received: by 10.140.201.8 with SMTP id y8mr4830800rvf.148.1224510863315; Mon, 20 Oct 2008 06:54:23 -0700 (PDT) Received: by 10.140.148.21 with HTTP; Mon, 20 Oct 2008 06:54:23 -0700 (PDT) Message-ID: <8753f9c00810200654i57c2dce2vf2bbcb601258e356@mail.gmail.com> Date: Mon, 20 Oct 2008 19:24:23 +0530 From: "Donn Khanna" To: grub-devel@gnu.org In-Reply-To: <8753f9c00810200649g13ed59e9k47b3bedefab46f3@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_69146_13174251.1224510863326" References: <8753f9c00810200649g13ed59e9k47b3bedefab46f3@mail.gmail.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Fwd: Boot Problem in Grub 1.92 ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2008 13:54:26 -0000 ------=_Part_69146_13174251.1224510863326 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have Now Successfully installed grub version 1.96 and there's also the menu like in 0.97 to boot. I got this menu after running update-grub command. Now I updated the grub.cfg (similar to grub.conf in v 0.97) as per rules in the official documentation website: http://grub.enbug.org/grub.cfg http://grub.enbug.org/TestingOnX86 http://grub.enbug.org/TestingOnEFI All of these web sites are in: http://grub.enbug.org/ The main purpose of loading grub 1.96 is hfs+ file system support. this support was added in v 1.92 I want a triple OS Booting (fedora 9, Mac OS X leopard, vista). All of my OS's are installed in different drives. Mac OS X is installed in hfs+ file system while vista in NTFS. After updating the grub.cfg file, it gives the following errors: For Mac OS X: error: Invalid signature For Vista: error: read write error in grub 0.97, it was unable to mount hfs+ file system and I was getting 2 OS. Now in grub 1.96, there's only fedora showing and I am able to boot only 1 OS.It is showing every item in the boot menu, it displays these errors when I press the enter button to boot the respective OS. Please Help. -- Rohit Gupta. ------=_Part_69146_13174251.1224510863326 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I have Now Successfully installed grub version 1.96 and there's also the menu like in 0.97 to boot. I got this menu after running update-grub command. Now I updated the grub.cfg (similar to grub.conf in v 0.97) as per rules in the official documentation website:

http://grub.enbug.org/grub.cfg
http://grub.enbug.org/TestingOnX86
http://grub.enbug.org/TestingOnEFI

All of these web sites are in:
http://grub.enbug.org/

The main purpose of loading grub 1.96 is hfs+ file system support. this support was added in v 1.92
I want a triple OS Booting (fedora 9, Mac OS X leopard, vista). All of my OS's are installed in different drives. Mac OS X is installed in hfs+ file system while vista in NTFS.

After updating the grub.cfg file, it gives the following errors:
For Mac OS X:
error: Invalid signature

For Vista:
error: read write error

in grub 0.97, it was unable to mount hfs+ file system and I was getting 2 OS. Now in grub 1.96, there's only fedora showing and I am able to boot only 1 OS.It is showing every item in the boot menu, it displays these errors when I press the enter button to boot the respective OS.
Please Help.

--
Rohit Gupta.

------=_Part_69146_13174251.1224510863326-- From MAILER-DAEMON Mon Oct 20 10:23:34 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KrvfS-0004eq-1l for mharc-grub-devel@gnu.org; Mon, 20 Oct 2008 10:23:34 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KrvfQ-0004el-AZ for grub-devel@gnu.org; Mon, 20 Oct 2008 10:23:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KrvfN-0004e4-Q2 for grub-devel@gnu.org; Mon, 20 Oct 2008 10:23:30 -0400 Received: from [199.232.76.173] (port=41341 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KrvfN-0004e1-Ix for grub-devel@gnu.org; Mon, 20 Oct 2008 10:23:29 -0400 Received: from po-out-1718.google.com ([72.14.252.155]:50114) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KrvfN-0002YD-Gq for grub-devel@gnu.org; Mon, 20 Oct 2008 10:23:29 -0400 Received: by po-out-1718.google.com with SMTP id y22so2381113pof.1 for ; Mon, 20 Oct 2008 07:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=G/aSsAL5lgRrfcGMH4eVjX8yfpPybtfvTCj7O+E1qwY=; b=hShbpd0zODvOdwNsHp5EHpjXfcK48RI1g1oxp9vstHhizZ68Z+6p+eRzAUlwdLwVg5 r9ZzJoxLTKZVkfiVmdet2uG0JNaueDhJWfOGKTc/yciAIY75+5F+usxthQIGlRIr6Ec+ JtFVT1YRYNScC4R8IGPOupye/mbC5xgfmkDC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=sfNlMDonpw5rGqS2lO6fv2M69exqXpBXEWGnGVLQ0gXz9uOFI/G3vUAXx1BwBR2isP hipzi3A8b/hJizIT6/GfGiUmT3mpdZGhcNwqYnFG51lQwUlDoiYwia5w2ULPFDvBABXz dcaHbwWvbxBGJHUiy5TbUM4sNbTjqwFKu/APQ= Received: by 10.141.52.5 with SMTP id e5mr4854067rvk.125.1224512606780; Mon, 20 Oct 2008 07:23:26 -0700 (PDT) Received: by 10.140.148.21 with HTTP; Mon, 20 Oct 2008 07:23:26 -0700 (PDT) Message-ID: <8753f9c00810200723g17a956ddk8256fdf633ad7872@mail.gmail.com> Date: Mon, 20 Oct 2008 19:53:26 +0530 From: "Donn Khanna" To: grub-devel@gnu.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_69512_17616215.1224512606869" X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Fwd: Boot Problem in Grub 1.96 ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2008 14:23:33 -0000 ------=_Part_69512_17616215.1224512606869 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have Now Successfully installed grub version 1.96 and there's also the menu like in 0.97 to boot. I got this menu after running update-grub command. Now I updated the grub.cfg (similar to grub.conf in v 0.97) as per rules in the official documentation website: http://grub.enbug.org/grub.cfg http://grub.enbug.org/TestingOnX86 http://grub.enbug.org/TestingOnEFI All of these web sites are in: http://grub.enbug.org/ The main purpose of loading grub 1.96 is hfs+ file system support. this support was added in v 1.92 I want a triple OS Booting (fedora 9, Mac OS X leopard, vista). All of my OS's are installed in different drives. Mac OS X is installed in hfs+ file system while vista in NTFS. After updating the grub.cfg file, it gives the following errors: For Mac OS X: error: Invalid signature For Vista: error: read write error in grub 0.97, it was unable to mount hfs+ file system and I was getting 2 OS. Now in grub 1.96, there's only fedora showing and I am able to boot only 1 OS.It is showing every item in the boot menu, it displays these errors when I press the enter button to boot the respective OS. Please Help. -- Rohit Gupta. ------=_Part_69512_17616215.1224512606869 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I have Now Successfully installed grub version 1.96 and there's also the menu like in 0.97 to boot. I got this menu after running update-grub command. Now I updated the grub.cfg (similar to grub.conf in v 0.97) as per rules in the official documentation website:

http://grub.enbug.org/grub.cfg
http://grub.enbug.org/TestingOnX86
http://grub.enbug.org/TestingOnEFI

All of these web sites are in:
http://grub.enbug.org/

The main purpose of loading grub 1.96 is hfs+ file system support. this support was added in v 1.92
I want a triple OS Booting (fedora 9, Mac OS X leopard, vista). All of my OS's are installed in different drives. Mac OS X is installed in hfs+ file system while vista in NTFS.

After updating the grub.cfg file, it gives the following errors:
For Mac OS X:
error: Invalid signature

For Vista:
error: read write error

in grub 0.97, it was unable to mount hfs+ file system and I was getting 2 OS. Now in grub 1.96, there's only fedora showing and I am able to boot only 1 OS.It is showing every item in the boot menu, it displays these errors when I press the enter button to boot the respective OS.
Please Help.

--
Rohit Gupta.


------=_Part_69512_17616215.1224512606869-- From MAILER-DAEMON Mon Oct 20 10:36:52 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KrvsJ-0001sb-Sn for mharc-grub-devel@gnu.org; Mon, 20 Oct 2008 10:36:51 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KrvsH-0001rt-AM for grub-devel@gnu.org; Mon, 20 Oct 2008 10:36:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KrvsF-0001rG-EO for grub-devel@gnu.org; Mon, 20 Oct 2008 10:36:48 -0400 Received: from [199.232.76.173] (port=57109 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KrvsF-0001rB-9W for grub-devel@gnu.org; Mon, 20 Oct 2008 10:36:47 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]:52899) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KrvsF-0004hj-2d for grub-devel@gnu.org; Mon, 20 Oct 2008 10:36:47 -0400 Received: from [85.180.48.255] (e180048255.adsl.alicedsl.de [85.180.48.255]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1Krvrw2k8U-0001GW; Mon, 20 Oct 2008 16:36:31 +0200 From: Felix Zielcke To: The development of GRUB 2 In-Reply-To: <8753f9c00810200723g17a956ddk8256fdf633ad7872@mail.gmail.com> References: <8753f9c00810200723g17a956ddk8256fdf633ad7872@mail.gmail.com> Content-Type: text/plain Date: Mon, 20 Oct 2008 16:36:27 +0200 Message-Id: <1224513387.3603.11.camel@fz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/KAVJtvberMsHD70izNHlxZRKo/BsrrDOWiep WD6Ijz3S0KuZuBHRGRvucOFqzU7RvrdDtRiN0vBlf20XZFO6mg 43+l3di81Byss9yNOCPgCnXYiPDVhiR X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6? (barebone, rare!) Subject: Re: Fwd: Boot Problem in Grub 1.96 ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2008 14:36:50 -0000 Am Montag, den 20.10.2008, 19:53 +0530 schrieb Donn Khanna: > I have Now Successfully installed grub version 1.96 and there's also > the menu like in 0.97 to boot. I got this menu after running > update-grub command. Now I updated the grub.cfg (similar to grub.conf > in v 0.97) as per rules in the official documentation website: You should use the SVN version which is much more recent and bugfree then the 1.96 release version from february To generate grub.cfg you can use `grub-mkconfig -o /boot/grub/grub.cfg' with SVN version or if you want to keep 1.96 release then with `update-grub' script. From MAILER-DAEMON Mon Oct 20 10:42:08 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KrvxQ-0003nP-Ct for mharc-grub-devel@gnu.org; Mon, 20 Oct 2008 10:42:08 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KrvxO-0003ms-Ie for grub-devel@gnu.org; Mon, 20 Oct 2008 10:42:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KrvxN-0003mg-4o for grub-devel@gnu.org; Mon, 20 Oct 2008 10:42:05 -0400 Received: from [199.232.76.173] (port=41756 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KrvxN-0003md-08 for grub-devel@gnu.org; Mon, 20 Oct 2008 10:42:05 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]:51012) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KrvxM-0005dQ-LV for grub-devel@gnu.org; Mon, 20 Oct 2008 10:42:05 -0400 Received: from [85.180.48.255] (e180048255.adsl.alicedsl.de [85.180.48.255]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1KrvxL1ySp-00019A; Mon, 20 Oct 2008 16:42:03 +0200 From: Felix Zielcke To: The development of GRUB 2 In-Reply-To: <1224513387.3603.11.camel@fz.local> References: <8753f9c00810200723g17a956ddk8256fdf633ad7872@mail.gmail.com> <1224513387.3603.11.camel@fz.local> Content-Type: text/plain Date: Mon, 20 Oct 2008 16:42:02 +0200 Message-Id: <1224513722.3603.13.camel@fz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19FyWEGDjGMF4CmLbWGxZWjPJctaNTd1wqM3Ie kvg20icRRst4XoAEShds2tU7h2VUd8pR6ufh5HVht1udrfQ/IH //LMTFUWgg+fm9BOljmhTorjL2X33m5 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6? (barebone, rare!) Subject: Re: Fwd: Boot Problem in Grub 1.96 ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2008 14:42:07 -0000 Am Montag, den 20.10.2008, 16:36 +0200 schrieb Felix Zielcke: > Am Montag, den 20.10.2008, 19:53 +0530 schrieb Donn Khanna: > > I have Now Successfully installed grub version 1.96 and there's also > > the menu like in 0.97 to boot. I got this menu after running > > update-grub command. Now I updated the grub.cfg (similar to grub.conf > > in v 0.97) as per rules in the official documentation website: > > You should use the SVN version which is much more recent and bugfree > then the 1.96 release version from february > To generate grub.cfg you can use `grub-mkconfig -o /boot/grub/grub.cfg' > with SVN version or if you want to keep 1.96 release then with > `update-grub' script. Oh and you can install `os-prober' so windows gets added to grub.cfg too. From MAILER-DAEMON Mon Oct 20 12:08:18 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KrxIo-0004bJ-1g for mharc-grub-devel@gnu.org; Mon, 20 Oct 2008 12:08:18 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KrxIm-0004al-RF for grub-devel@gnu.org; Mon, 20 Oct 2008 12:08:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KrxIl-0004aT-PW for grub-devel@gnu.org; Mon, 20 Oct 2008 12:08:16 -0400 Received: from [199.232.76.173] (port=44590 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KrxIl-0004aO-Ll for grub-devel@gnu.org; Mon, 20 Oct 2008 12:08:15 -0400 Received: from qb-out-1314.google.com ([72.14.204.175]:30297) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KrxIl-0002ip-NN for grub-devel@gnu.org; Mon, 20 Oct 2008 12:08:15 -0400 Received: by qb-out-1314.google.com with SMTP id f16so1745312qba.30 for ; Mon, 20 Oct 2008 09:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=A0M8e0IssY8dIeTQekcgUEqiNujwGQzzlvHr5GHeD3w=; b=fWuqvEEu+hR5SjwtsCzxDYw7Oz50bLWNV8p4Fo6ENAFIBIHmuHhyuWwu7pb3FDZBCx loAoALwa72TJaA1CkDU9BLnaZLRrCq6V+FLAmHoDt8fSu2v9GhR8HL0cdvudTM2H+iWv vtosrs1FVTi0bmDb1ikrIBMsbFRXrSOOXodpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=ug1zMQoqEy/eCtDTz5ydVyS4ZtS0TlyXAdKpRmtxXyYMYTxbgrzN8SU0B13qBj3Nh5 yu51g2ZGzJyGZ5GW3ZnwOLGrMlO882ulZw/BRZ60MzYe8wrwrmZemlogBIMvhsVsqbTA 3GnHe1VC7GvDRe2Z7dWiJG+mmsqX7kc1hDGp8= Received: by 10.141.114.15 with SMTP id r15mr4940060rvm.164.1224518893313; Mon, 20 Oct 2008 09:08:13 -0700 (PDT) Received: by 10.140.148.21 with HTTP; Mon, 20 Oct 2008 09:08:13 -0700 (PDT) Message-ID: <8753f9c00810200908v4fbea230xced4a6e759bc3ca6@mail.gmail.com> Date: Mon, 20 Oct 2008 21:38:13 +0530 From: "Donn Khanna" To: "The development of GRUB 2" In-Reply-To: <1224513722.3603.13.camel@fz.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_70144_28542667.1224518893318" References: <8753f9c00810200723g17a956ddk8256fdf633ad7872@mail.gmail.com> <1224513387.3603.11.camel@fz.local> <1224513722.3603.13.camel@fz.local> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Fwd: Boot Problem in Grub 1.96 ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2008 16:08:17 -0000 ------=_Part_70144_28542667.1224518893318 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline How to install os-prober in fedora 9. I have downloaded the package: os-prober_1.28_i386.deb On Mon, Oct 20, 2008 at 8:12 PM, Felix Zielcke wrote: > Am Montag, den 20.10.2008, 16:36 +0200 schrieb Felix Zielcke: > > Am Montag, den 20.10.2008, 19:53 +0530 schrieb Donn Khanna: > > > I have Now Successfully installed grub version 1.96 and there's also > > > the menu like in 0.97 to boot. I got this menu after running > > > update-grub command. Now I updated the grub.cfg (similar to grub.conf > > > in v 0.97) as per rules in the official documentation website: > > > > You should use the SVN version which is much more recent and bugfree > > then the 1.96 release version from february > > To generate grub.cfg you can use `grub-mkconfig -o /boot/grub/grub.cfg' > > with SVN version or if you want to keep 1.96 release then with > > `update-grub' script. > > Oh and you can install `os-prober' so windows gets added to grub.cfg > too. > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ------=_Part_70144_28542667.1224518893318 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
How to install os-prober in fedora 9.
I have downloaded the package: os-prober_1.28_i386.deb

On Mon, Oct 20, 2008 at 8:12 PM, Felix Zielcke <fzielcke@z-51.de> wrote:
Am Montag, den 20.10.2008, 16:36 +0200 schrieb Felix Zielcke:
> Am Montag, den 20.10.2008, 19:53 +0530 schrieb Donn Khanna:
> > I have Now Successfully installed grub version 1.96 and there's also
> > the menu like in 0.97 to boot. I got this menu after running
> > update-grub command. Now I updated the grub.cfg (similar to grub.conf
> > in v 0.97) as per rules in the official documentation website:
>
> You should use the SVN version which is much more recent and bugfree
> then the 1.96 release version from february
> To generate grub.cfg you can use `grub-mkconfig -o /boot/grub/grub.cfg'
> with SVN version or if you want to keep 1.96 release then with
> `update-grub' script.

Oh and you can install `os-prober' so windows gets added to grub.cfg
too.



_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

------=_Part_70144_28542667.1224518893318-- From MAILER-DAEMON Mon Oct 20 15:18:37 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Ks0Gz-00043x-AX for mharc-grub-devel@gnu.org; Mon, 20 Oct 2008 15:18:37 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ks0Gw-00041p-Js for grub-devel@gnu.org; Mon, 20 Oct 2008 15:18:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ks0Gt-0003zn-QP for grub-devel@gnu.org; Mon, 20 Oct 2008 15:18:34 -0400 Received: from [199.232.76.173] (port=50796 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ks0Gt-0003zb-92 for grub-devel@gnu.org; Mon, 20 Oct 2008 15:18:31 -0400 Received: from igw3.br.ibm.com ([32.104.18.26]:34542) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ks0Gq-0006Fu-6L for grub-devel@gnu.org; Mon, 20 Oct 2008 15:18:30 -0400 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw3.br.ibm.com (Postfix) with ESMTP id 1324E39026B for ; Mon, 20 Oct 2008 17:17:44 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9KJI8Nh2338918 for ; Mon, 20 Oct 2008 16:18:09 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9KJIMTE025880 for ; Mon, 20 Oct 2008 17:18:22 -0200 Received: from [9.18.253.165] (dyn536858.br.ibm.com [9.18.253.165]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9KJIKWW025717; Mon, 20 Oct 2008 17:18:21 -0200 From: Manoel To: grub-devel@gnu.org Content-Type: multipart/mixed; boundary="=-wsU3vnYL/1xvqQJY4rub" Date: Mon, 20 Oct 2008 17:18:21 -0200 Message-Id: <1224530301.17376.47.camel@manoel-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (tstamp-) Cc: Carlos Roberto do Nascimento Costa , Hollis Blanchard Subject: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2008 19:18:35 -0000 --=-wsU3vnYL/1xvqQJY4rub Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm working in a project to use grub2 to boot some ppc machines(p6 , p5 and so on) and we had some difficulties with a grub modules problem. Grub fails to load modules. When debugging I noted that grub try to find the headerinfo modules struc (which is identified by the magic number 0x676d696d) in the address 0x2d000 (_end + gap aligned in 4k blocks). but this address does not contains the headerinfo. So i altered the source code such as the memory is searched to find the magic number. It is then found at address 0x38f4c and then grub find some modules (but fails after) has showed in attachment grub2.txt. that address calculation led me to believe that I can tell where the struct will be on memory based in its place in the binary. I also noted that basemod ( indicates where the modules sections begin) used by grub_mkelfimage is the same calculated by grub (_end + GAP). but it seems to not store it on the necessary address. using hexedit I could see that in the address 0xCC98 (in the file generated by grub_mkelfimage) is stored the struct header info. so in resume. address where grub tries to find the header 0x2d000. address where it is actually stored 0x38f4c. address where it is in the generated file 0xCC98. So my doubts are: How this address calculation works? How can I know where the struct will be in memory based in its address in the binary? It really works or only in some old OpenFirmare version? I followed the wiki tutorial in the process. =20 That is the exit of the command: "readelf -l" (binary + modules): Elf file type is EXEC (Executable file) Entry point 0x10000 There are 4 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x0000b4 0x00010000 0x00010000 0x0cbe4 0x14098 RWE 0x10 GNU_STACK 0x00cc98 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4 NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 the exit of "readelf -a" is showed in attachment readelf.txt =20 =EF=BB=BFIf you could help me, I will appreciate it. Thanks in advance! Best regards. Abranches, Manoel R. --=-wsU3vnYL/1xvqQJY4rub Content-Disposition: attachment; filename=grub2.txt Content-Type: text/plain; name=grub2.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit cursor-on, unknown wordWelcome to GRUB! search= 0x38f4c end =0x24098 gap =0x8000 align=0x1000 base_mod=0x2d000 modinfo = 0x2d000 modinfo->magic = 0x3063ffff modinfo = 0x38f4c modinfo->magic = 0x676d696d ../kern/dl.c:527: module at 0x38f64, size 0xbc0 ../kern/dl.c:556: relocating to 0x2b8f0 ../kern/dl.c:513: flushing 0x14 bytes at 0x2b350 ../kern/dl.c:513: flushing 0x69 bytes at 0x2b3a0 ../kern/dl.c:513: flushing 0x460 bytes at 0x2b440 ../kern/dl.c:570: module name: acorn ../kern/dl.c:571: init function: 0x2b440 ../kern/dl.c:527: module at 0x39b30, size 0xefc ../kern/dl.c:556: relocating to 0x2b240 ../kern/dl.c:513: flushing 0x97 bytes at 0x2aa30 ../kern/dl.c:513: flushing 0x6ec bytes at 0x2ab00 ../kern/dl.c:570: module name: fshelp ../kern/dl.c:571: init function: 0x0 ../kern/dl.c:527: module at 0x3aa38, size 0x1aa4 ../kern/dl.c:556: relocating to 0x2a8b0 ../kern/dl.c:513: flushing 0x4 bytes at 0x29af0 ../kern/dl.c:513: flushing 0x20 bytes at 0x29b30 ../kern/dl.c:513: flushing 0x89 bytes at 0x29b80 ../kern/dl.c:513: flushing 0xbf4 bytes at 0x29c40 ../kern/dl.c:570: module name: affs ../kern/dl.c:571: init function: 0x29c40 ../kern/dl.c:527: module at 0x3c4e8, size 0x1be8 ../kern/dl.c:556: relocating to 0x29a20 ../kern/dl.c:513: flushing 0x4 bytes at 0x287f0 ../kern/dl.c:513: flushing 0x20 bytes at 0x28830 ../kern/dl.c:513: flushing 0x28 bytes at 0x28880 ../kern/dl.c:513: flushing 0x4 bytes at 0x288e0 ../kern/dl.c:513: flushing 0x108c bytes at 0x28920 ../kern/dl.c:570: module name: afs ../kern/dl.c:571: init function: 0x28920 ../kern/dl.c:527: module at 0x3e0dc, size 0xc9c ../kern/dl.c:556: relocating to 0x28720 ../kern/dl.c:513: flushing 0x4 bytes at 0x28190 ../kern/dl.c:513: flushing 0x14 bytes at 0x281d0 ../kern/dl.c:513: flushing 0x68 bytes at 0x28220 ../kern/dl.c:513: flushing 0x410 bytes at 0x282c0 ../kern/dl.c:570: module name: amiga ../kern/dl.c:571: init function: 0x282c0 ../kern/dl.c:527: module at 0x3ed84, size 0xe28 ../kern/dl.c:556: relocating to 0x280a0 ../kern/dl.c:513: flushing 0x4 bytes at 0x27a30 ../kern/dl.c:513: flushing 0x14 bytes at 0x27a70 ../kern/dl.c:513: flushing 0xfc bytes at 0x27ac0 ../kern/dl.c:513: flushing 0x458 bytes at 0x27bf0 ../kern/dl.c:570: module name: apple ../kern/dl.c:571: init function: 0x27bf0 ../kern/dl.c:527: module at 0x3fbb8, size 0xeca4 ../kern/dl.c:556: relocating to 0x27940 DEFAULT CATCH!, exception-handler=fff00300 at %SRR0: 0000000000013f88 %SRR1: 0000000000003002 Open Firmware exception handler entered from non-OF code Client's Fix Pt Regs: 00 0000000000000010 00000000018dff50 0000000000000000 0000000065765b1b 04 000000000001a944 0000000000000000 0000000000003002 0000000000000010 08 00000000018dfe08 000000000001a944 000000000000000a 0000000065765b1b 0c 0000000000000000 0000000000000000 0000000000000000 0000000000000000 10 0000000000000000 0000000000000000 0000000000000000 0000000000000000 14 0000000000c00000 0000000000000008 0000000000000000 0000000000000000 18 0000000000000000 000000000001af4c 000000000001a944 000000000003fbb8 1c 0000000000000007 000000000004881c 0000000000027940 000000000003fbb8 Special Regs: %IV: 00000300 %CR: 24000048 %XER: 00000000 %DSISR: 08000000 %SRR0: 0000000000013f88 %SRR1: 0000000000003002 %LR: 000000000001291c %CTR: 0000000000017930 %DAR: 0000000065765b1b Virtual PID = 0 PFW: Unable to send error log! ofdbg 0 > --=-wsU3vnYL/1xvqQJY4rub Content-Disposition: attachment; filename=readelf.txt Content-Type: text/plain; name=readelf.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit ELF Header: Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: PowerPC Version: 0x1 Entry point address: 0x10000 Start of program headers: 52 (bytes into file) Start of section headers: 0 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 4 Size of section headers: 40 (bytes) Number of section headers: 0 Section header string table index: 0 There are no sections in this file. There are no sections in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x0000b4 0x00010000 0x00010000 0x0cbe4 0x14098 RWE 0x10 GNU_STACK 0x00cc98 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4 NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 There is no dynamic section in this file. There are no relocations in this file. There are no unwind sections in this file. No version information found in this file. --=-wsU3vnYL/1xvqQJY4rub-- From MAILER-DAEMON Mon Oct 20 15:32:43 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Ks0Ud-0002BB-CM for mharc-grub-devel@gnu.org; Mon, 20 Oct 2008 15:32:43 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ks0Ub-0002AZ-IL for grub-devel@gnu.org; Mon, 20 Oct 2008 15:32:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ks0UZ-00029s-6i for grub-devel@gnu.org; Mon, 20 Oct 2008 15:32:41 -0400 Received: from [199.232.76.173] (port=49862 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ks0UZ-00029m-0s for grub-devel@gnu.org; Mon, 20 Oct 2008 15:32:39 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:54076) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ks0UY-0001mO-ED for grub-devel@gnu.org; Mon, 20 Oct 2008 15:32:38 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9KJWaPq007943 for ; Mon, 20 Oct 2008 15:32:36 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9KJWals058854 for ; Mon, 20 Oct 2008 15:32:36 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9KJWax4002270 for ; Mon, 20 Oct 2008 15:32:36 -0400 Received: from [9.53.41.42] (slate.austin.ibm.com [9.53.41.42]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9KJWaCc002217; Mon, 20 Oct 2008 15:32:36 -0400 From: Hollis Blanchard To: Manoel In-Reply-To: <1224530301.17376.47.camel@manoel-laptop> References: <1224530301.17376.47.camel@manoel-laptop> Content-Type: text/plain; charset=utf-8 Organization: IBM Linux Technology Center Date: Mon, 20 Oct 2008 14:32:34 -0500 Message-Id: <1224531154.15647.48.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e1.ny.us.ibm.com id m9KJWaPq007943 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Cc: grub-devel@gnu.org, Carlos Roberto do Nascimento Costa Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2008 19:32:41 -0000 On Mon, 2008-10-20 at 17:18 -0200, Manoel wrote: >=20 > I'm working in a project to use grub2 to boot some ppc machines(p6 , p5 > and so on) and we had some difficulties with a grub modules problem. > Grub fails to load modules. >=20 > When debugging I noted that grub try to find the headerinfo modules > struc (which is identified by the magic number 0x676d696d) in the > address 0x2d000 (_end + gap aligned in 4k blocks). > but this address does not contains the headerinfo. >=20 > So i altered the source code such as the memory is searched to find the > magic number. It is then found at address 0x38f4c and then grub find > some modules (but fails after) has showed in attachment grub2.txt. ... ../kern/dl.c:527: module at 0x3e0dc, size 0xc9c ../kern/dl.c:556: relocating to 0x28720 ../kern/dl.c:513: flushing 0x4 bytes at 0x28190 ../kern/dl.c:513: flushing 0x14 bytes at 0x281d0 ../kern/dl.c:513: flushing 0x68 bytes at 0x28220 ../kern/dl.c:513: flushing 0x410 bytes at 0x282c0 ../kern/dl.c:570: module name: amiga ../kern/dl.c:571: init function: 0x282c0 ../kern/dl.c:527: module at 0x3ed84, size 0xe28 ../kern/dl.c:556: relocating to 0x280a0 ../kern/dl.c:513: flushing 0x4 bytes at 0x27a30 ../kern/dl.c:513: flushing 0x14 bytes at 0x27a70 ../kern/dl.c:513: flushing 0xfc bytes at 0x27ac0 ../kern/dl.c:513: flushing 0x458 bytes at 0x27bf0 ../kern/dl.c:570: module name: apple ../kern/dl.c:571: init function: 0x27bf0 ../kern/dl.c:527: module at 0x3fbb8, size 0xeca4 ../kern/dl.c:556: relocating to 0x27940 Notice how much larger that last module is than the ones before it. That's a bit suspicious... do you have any modules that size? > that address calculation led me to believe that I can tell where the > struct will be on memory based in its place in the binary. >=20 > I also noted that basemod ( indicates where the modules sections begin) > used by grub_mkelfimage is the same calculated by grub (_end + GAP). bu= t > it seems to not store it on the necessary address. >=20 > using hexedit I could see that in the address 0xCC98 (in the file > generated by grub_mkelfimage) is stored the struct header info. Well, hmm. Given the readelf output below, file offset 0xcc98 should be loaded right at 0x2d000. Since you can see the magic number there (correct?), I can't explain why the ELF loaded places it at 0x38f4c. Can you report what memory firmware is using on this system? IIRC you can decode it from the "available" properties in the memory nodes. > so in resume. >=20 > address where grub tries to find the header 0x2d000. > address where it is actually stored 0x38f4c. > address where it is in the generated file 0xCC98. >=20 > So my doubts are: > How this address calculation works? > How can I know where the struct will be in memory based in its address > in the binary? > It really works or only in some old OpenFirmare version? >=20 >=20 > I followed the wiki tutorial in the process. =20 >=20 > That is the exit of the command: "readelf -l" (binary + modules): >=20 > Elf file type is EXEC (Executable file) > Entry point 0x10000 > There are 4 program headers, starting at offset 52 >=20 > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Alig= n > LOAD 0x0000b4 0x00010000 0x00010000 0x0cbe4 0x14098 RWE 0x10 > GNU_STACK 0x00cc98 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 > LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4 > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 >=20 >=20 > the exit of "readelf -a" is showed in attachment readelf.txt >=20 > =EF=BB=BFIf you could help me, I will appreciate it. Thanks in advance! > Best regards. > Abranches, Manoel R. --=20 Hollis Blanchard IBM Linux Technology Center From MAILER-DAEMON Tue Oct 21 12:43:33 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KsKKT-0006vw-9N for mharc-grub-devel@gnu.org; Tue, 21 Oct 2008 12:43:33 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KsKKR-0006vE-8a for grub-devel@gnu.org; Tue, 21 Oct 2008 12:43:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KsKKQ-0006uc-Cz for grub-devel@gnu.org; Tue, 21 Oct 2008 12:43:30 -0400 Received: from [199.232.76.173] (port=58842 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsKKQ-0006uR-7O for grub-devel@gnu.org; Tue, 21 Oct 2008 12:43:30 -0400 Received: from igw2.br.ibm.com ([32.104.18.25]:51166) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KsKKP-0005v1-Dq for grub-devel@gnu.org; Tue, 21 Oct 2008 12:43:30 -0400 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw2.br.ibm.com (Postfix) with ESMTP id 0DFCB17F4B5 for ; Tue, 21 Oct 2008 14:42:32 -0200 (BRDT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9LGh8r52420944 for ; Tue, 21 Oct 2008 13:43:08 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9LGhNVF022090 for ; Tue, 21 Oct 2008 14:43:23 -0200 Received: from [9.18.253.165] (dyn536858.br.ibm.com [9.18.253.165]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9LGhNMW022085 for ; Tue, 21 Oct 2008 14:43:23 -0200 From: Manoel To: The development of GRUB 2 In-Reply-To: <1224531154.15647.48.camel@localhost.localdomain> References: <1224530301.17376.47.camel@manoel-laptop> <1224531154.15647.48.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-mCp5hFLQAD08vmXoKnR6" Date: Tue, 21 Oct 2008 14:43:25 -0200 Message-Id: <1224607405.6852.33.camel@manoel-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 16:43:31 -0000 --=-mCp5hFLQAD08vmXoKnR6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Hollis, On Mon, 2008-10-20 at 14:32 -0500, Hollis Blanchard wrote:=20 > On Mon, 2008-10-20 at 17:18 -0200, Manoel wrote: > >=20 > > I'm working in a project to use grub2 to boot some ppc machines(p6 , = p5 > > and so on) and we had some difficulties with a grub modules problem. > > Grub fails to load modules. > >=20 > > When debugging I noted that grub try to find the headerinfo modules > > struc (which is identified by the magic number 0x676d696d) in the > > address 0x2d000 (_end + gap aligned in 4k blocks). > > but this address does not contains the headerinfo. > >=20 > > So i altered the source code such as the memory is searched to find t= he > > magic number. It is then found at address 0x38f4c and then grub find > > some modules (but fails after) has showed in attachment grub2.txt. >=20 > ... > ../kern/dl.c:527: module at 0x3e0dc, size 0xc9c > ../kern/dl.c:556: relocating to 0x28720 > ../kern/dl.c:513: flushing 0x4 bytes at 0x28190 > ../kern/dl.c:513: flushing 0x14 bytes at 0x281d0 > ../kern/dl.c:513: flushing 0x68 bytes at 0x28220 > ../kern/dl.c:513: flushing 0x410 bytes at 0x282c0 > ../kern/dl.c:570: module name: amiga > ../kern/dl.c:571: init function: 0x282c0 > ../kern/dl.c:527: module at 0x3ed84, size 0xe28 > ../kern/dl.c:556: relocating to 0x280a0 > ../kern/dl.c:513: flushing 0x4 bytes at 0x27a30 > ../kern/dl.c:513: flushing 0x14 bytes at 0x27a70 > ../kern/dl.c:513: flushing 0xfc bytes at 0x27ac0 > ../kern/dl.c:513: flushing 0x458 bytes at 0x27bf0 > ../kern/dl.c:570: module name: apple > ../kern/dl.c:571: init function: 0x27bf0 > ../kern/dl.c:527: module at 0x3fbb8, size 0xeca4 > ../kern/dl.c:556: relocating to 0x27940 >=20 > Notice how much larger that last module is than the ones before it. > That's a bit suspicious... do you have any modules that size? >=20 I'd like to address this issue later but their size are really messed up. Grub can find the modules (how you can see by the modules names) though. The modules should have 7k at most but grub identified them has having about 50k. I'm also curious why we must have a GAP between _end and the modules. Why do not put the modules right after the _end address. I need to look more into the source code but I noted the modules are allocated in address in a decrementing order. The next module is always loaded in a address below the previous module. I don't know if this memory is allocated by the OF or if Grub forces the address to load the modules this way. How I have said before that I will look at this issue after the modules header info location address issue is resolved. =20 > > that address calculation led me to believe that I can tell where the > > struct will be on memory based in its place in the binary. > >=20 > > I also noted that basemod ( indicates where the modules sections begi= n) > > used by grub_mkelfimage is the same calculated by grub (_end + GAP). = but > > it seems to not store it on the necessary address. > >=20 > > using hexedit I could see that in the address 0xCC98 (in the file > > generated by grub_mkelfimage) is stored the struct header info. >=20 > Well, hmm. Given the readelf output below, file offset 0xcc98 should be > loaded right at 0x2d000. Since you can see the magic number there > (correct?), I can't explain why the ELF loaded places it at 0x38f4c. Yes, the magic number is exactly at the address 0xcc98 on the file generated by the grub_mkelfimage. How can you tell the address it should appear in memory based on its address in file? Maybe it's only valid in some old OF version?=20 >=20 > Can you report what memory firmware is using on this system? IIRC you > can decode it from the "available" properties in the memory nodes. >=20 I couldn't find any apparently useful information in the memory nodes properties. I have attached it anyway, I have also attached the "/" node properties.=20 The OF version we are using is that below: PowerPC Firmware Version SF240_299 > > so in resume. > >=20 > > address where grub tries to find the header 0x2d000. > > address where it is actually stored 0x38f4c. > > address where it is in the generated file 0xCC98. > >=20 > > So my doubts are: > > How this address calculation works? > > How can I know where the struct will be in memory based in its addres= s > > in the binary? > > It really works or only in some old OpenFirmare version? > >=20 > >=20 > > I followed the wiki tutorial in the process. =20 > >=20 > > That is the exit of the command: "readelf -l" (binary + modules): > >=20 > > Elf file type is EXEC (Executable file) > > Entry point 0x10000 > > There are 4 program headers, starting at offset 52 > >=20 > > Program Headers: > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Al= ign > > LOAD 0x0000b4 0x00010000 0x00010000 0x0cbe4 0x14098 RWE 0x= 10 > > GNU_STACK 0x00cc98 0x00000000 0x00000000 0x00000 0x00000 RWE 0x= 4 > > LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x= 4 > > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x= 4 > >=20 > >=20 > > the exit of "readelf -a" is showed in attachment readelf.txt > >=20 > > =EF=BB=BFIf you could help me, I will appreciate it. Thanks in advanc= e! > > Best regards. > > Abranches, Manoel R. >=20 --=20 Best Regards, Manoel Abranches IBM Linux Technology Center Brasil --=-mCp5hFLQAD08vmXoKnR6 Content-Disposition: attachment; filename=OF-memory-properties.txt Content-Type: text/plain; name=OF-memory-properties.txt; charset=utf-8 Content-Transfer-Encoding: 7bit name memory device_type memory reg 00000000 00000000 00000000 08000000 available 00000000 00004000 00000000 00bfc000 00000000 01c00000 00000000 06400000 #address-cells 00000001 #size-cells 00000000 ibm,associativity 00000004 00000000 00000000 00000000 000000 --=-mCp5hFLQAD08vmXoKnR6 Content-Disposition: attachment; filename=OF-properties.txt Content-Type: text/plain; name=OF-properties.txt; charset=utf-8 Content-Transfer-Encoding: 7bit 0 > .properties ibm,model-class E5 ibm,pci-full-cfg 00000001 ibm,extended-clock-frequency 00000000 1f78a400 clock-frequency 1f78a400 device_type chrp #address-cells 00000002 #size-cells 00000002 ibm,max-boot-devices 00000005 ibm,fw-bytes-per-boot-device 00000100 ibm,extended-address ibm,lpar-capable ibm,converged-loc-codes ibm,eeh-default 00000001 ibm,partition-no 00000009 ibm,partition-name 706f7765 72706163 6b2d7465 73743200 ibm,platform-hardware-notification 00000001 504f5745 52355f30 30334230 33303100 ibm,aix-diagnostics name IBM,9133-55A model IBM,9133-55A compatible IBM,9133-55A ibm,aix-uid 02a1b3d6 system-id IBM,0306301FH ibm,drc-indexes 00000208 80000001 80000002 80000003 80000004 80000005 80000006 80000007 20000001 20000002 20000003 20000004 20000005 20000006 20000007 20000008 20000009 2000000a 2000000b 2000000c 2000000d 2000000e 2000000f 20000010 20000011 20000012 20000013 20000014 20000015 20000016 20000017 20000018 20000019 2000001a 2000001b 2000001c 2000001d 2000001e 2000001f 20000020 20000021 20000022 20000023 20000024 20000025 20000026 20000027 20000028 20000029 2000002a 2000002b 2000002c 2000002d 2000002e 2000002f 20000030 20000031 20000032 20000033 20000034 20000035 20000036 20000037 20000038 ... 00000824bytes total ibm,drc-types 00000208 4d454d00 4d454d00 4d454d00 4d454d00 4d454d00 4d454d00 4d454d00 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 50484200 ... 00000825bytes total ibm,drc-names 00000208 4c4d4232 004c4d42 33004c4d 4234004c 4d423500 4c4d4236 004c4d42 37004c4d 42380050 48422031 00504842 20320050 48422033 00504842 20340050 48422035 00504842 20360050 48422037 00504842 20380050 48422039 00504842 20313000 50484220 31310050 48422031 32005048 42203133 00504842 20313400 50484220 31350050 48422031 36005048 42203137 00504842 20313800 50484220 31390050 48422032 30005048 42203231 00504842 20323200 50484220 32330050 48422032 34005048 42203235 00504842 20323600 50484220 32370050 48422032 38005048 42203239 00504842 20333000 50484220 33310050 48422033 32005048 ... 00000fd0bytes total ibm,drc-power-domains 00000208 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ... 00000824bytes total --=-mCp5hFLQAD08vmXoKnR6-- From MAILER-DAEMON Tue Oct 21 13:13:06 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KsKn4-0007sP-73 for mharc-grub-devel@gnu.org; Tue, 21 Oct 2008 13:13:06 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KsKn2-0007ro-4H for grub-devel@gnu.org; Tue, 21 Oct 2008 13:13:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KsKn0-0007rU-TG for grub-devel@gnu.org; Tue, 21 Oct 2008 13:13:03 -0400 Received: from [199.232.76.173] (port=50307 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsKn0-0007rR-PN for grub-devel@gnu.org; Tue, 21 Oct 2008 13:13:02 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:57376) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KsKn0-0004bj-3u for grub-devel@gnu.org; Tue, 21 Oct 2008 13:13:02 -0400 Received: from [85.180.59.45] (e180059045.adsl.alicedsl.de [85.180.59.45]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1KsKmn0OUj-0002Jc; Tue, 21 Oct 2008 19:12:49 +0200 From: Felix Zielcke To: The development of GRUB 2 In-Reply-To: <8753f9c00810200908v4fbea230xced4a6e759bc3ca6@mail.gmail.com> References: <8753f9c00810200723g17a956ddk8256fdf633ad7872@mail.gmail.com> <1224513387.3603.11.camel@fz.local> <1224513722.3603.13.camel@fz.local> <8753f9c00810200908v4fbea230xced4a6e759bc3ca6@mail.gmail.com> Content-Type: multipart/mixed; boundary="=-K9eVsl2Z6b5TwqVEgqZb" Date: Tue, 21 Oct 2008 19:12:47 +0200 Message-Id: <1224609168.4077.14.camel@fz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-Provags-ID: V01U2FsdGVkX1+lBH2nnCDZBKJW3JLk6jW2VC4SIgLbVCwSN8h G5+7kEuDcE267hxURxmmoimGPurBWQT9KTrFwjT7K3m7WXPHgj 4qB/4DAePq+umEuJZ5dmiF0HlLs/qMV X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: Fwd: Boot Problem in Grub 1.96 ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 17:13:04 -0000 --=-K9eVsl2Z6b5TwqVEgqZb Content-Type: text/plain Content-Transfer-Encoding: 7bit Am Montag, den 20.10.2008, 21:38 +0530 schrieb Donn Khanna: > How to install os-prober in fedora 9. > I have downloaded the package: os-prober_1.28_i386.deb Hi, This is offtopic here but well okay. I forgot that os-prober is a Debian thing. .deb files are just like .rpm files but for the Debian dpkg tool, which I doubt Fedora has. Attached is now a .rpm created from the deb by using `alien'. -- Felix Zielcke --=-K9eVsl2Z6b5TwqVEgqZb Content-Disposition: attachment; filename=os-prober-1.28-2.i386.rpm Content-Type: application/x-rpm; name=os-prober-1.28-2.i386.rpm Content-Transfer-Encoding: base64 7avu2wMAAAAAAW9zLXByb2Jlci0xLjI4LTIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAUAAAAAAAAAAAAAAAAAAAAAjq3oAQAAAAAAAAAFAAAAVAAA AD4AAAAHAAAARAAAABAAAAENAAAABgAAAAAAAAABAAAD6AAAAAQAAAAsAAAAAQAAA+wAAAAHAAAA MAAAABAAAAPvAAAABAAAAEAAAAABYWM3NTdiZWI1MWMyNDcxNjg1MGEwYTQ4MzMzZWE4M2QxN2Zl N2M2MgAAAAAAAFDFGQ60FLtYY8VcAe1y2L3HGAAAnvgAAAA+AAAAB////7AAAAAQAAAAAI6t6AEA AAAAAAAAMwAAELAAAAA/AAAABwAAEKAAAAAQAAAAZAAAAAgAAAAAAAAAAQAAA+gAAAAGAAAAAgAA AAEAAAPpAAAABgAAAAwAAAABAAAD6gAAAAYAAAARAAAAAQAAA+wAAAAJAAAAEwAAAAEAAAPtAAAA CQAAAEMAAAABAAAD7gAAAAQAAADwAAAAAQAAA+8AAAAGAAAA9AAAAAEAAAPxAAAABAAAAQAAAAAB AAAD8gAAAAYAAAEEAAAAAQAAA/YAAAAGAAABCwAAAAEAAAP4AAAACQAAATIAAAABAAAD/QAAAAYA AAFCAAAAAQAAA/4AAAAGAAABSAAAAAEAAAQEAAAABAAAAVAAAAAlAAAEBgAAAAMAAAHkAAAAJQAA BAkAAAADAAACLgAAACUAAAQKAAAABAAAAngAAAAlAAAECwAAAAgAAAMMAAAAJQAABAwAAAAIAAAF 0QAAACUAAAQNAAAABAAABfgAAAAlAAAEDwAAAAgAAAaMAAAAJQAABBAAAAAIAAAHRQAAACUAAAQU AAAABgAAB/4AAAABAAAEFQAAAAQAAAgYAAAAJQAABBcAAAAIAAAIrAAAAAEAAAQYAAAABAAACLgA AAADAAAEGQAAAAgAAAjEAAAAAwAABBoAAAAIAAAJBwAAAAMAAAQoAAAABgAACRYAAAABAAAERwAA AAQAAAkgAAAAJQAABEgAAAAEAAAJtAAAACUAAARJAAAACAAACkgAAAAlAAAEWAAAAAQAAApwAAAA AQAABFkAAAAIAAAKdAAAAAEAAARcAAAABAAACnwAAAAlAAAEXQAAAAgAAAsQAAAAJQAABF4AAAAI AAAMXgAAAA8AAARiAAAABgAADV8AAAABAAAEZAAAAAYAAA2jAAAAAQAABGUAAAAGAAANqAAAAAEA AARmAAAABgAADa0AAAABAAAEawAAAAYAAA2vAAAAAQAABGwAAAAGAAANtAAAAAEAAAR0AAAABAAA DcQAAAAlAAAEdQAAAAQAAA5YAAAAJQAABHYAAAAIAAAO7AAAAAQAAAR3AAAABAAADzAAAAAlAAAE eAAAAAQAAA/EAAAAJQAABHkAAAAEAAAQWAAAABJDAG9zLXByb2JlcgAxLjI4ADIAdXRpbGl0eSB0 byBkZXRlY3Qgb3RoZXIgT1NlcyBvbiBhIHNldCBvZiBkcml2ZXMAVGhpcyBwYWNrYWdlIGRldGVj dHMgb3RoZXIgT1NlcyBhdmFpbGFibGUgb24gYSBzeXN0ZW0gYW5kIG91dHB1dHMgdGhlCnJlc3Vs dHMgaW4gYSBnZW5lcmljIG1hY2hpbmUtcmVhZGFibGUgZm9ybWF0LgoKCihDb252ZXJ0ZWQgZnJv bSBhIGRlYiBwYWNrYWdlIGJ5IGFsaWVuIHZlcnNpb24gOC43Mi4pAABI/gz0ZnoubG9jYWwAAAAA AACKFkRlYmlhbgBzZWUgL3Vzci9zaGFyZS9kb2Mvb3MtcHJvYmVyL2NvcHlyaWdodABDb252ZXJ0 ZWQvdXRpbHMAbGludXgAaTM4NgAAAAAAABAAAAAQAAAAEAAAAAWiAAAN4wAAEAAAABAAAAAECQAA EAAAAAeSAAAGvQAACPsAAAT+AAAQAAAABKoAABAAAAAENgAAEAAAAAG3AAABhAAACAQAAALHAAAD dwAAAP8AAAETAAAQowAAAX8AABAAAAAQAAAAEAAAABfqAAAAuQAAEAAAAA8MAAAQAAAAEAAAABAA Qe1B7UHtge2B7UHtQe2B7UHtge2B7YHtge1B7YHtQe2B7UHtge2B7YHtge2B7YHtge2B7YHtQe1B 7UHtgaSBpEHtgaRB7UHtQe0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEj+DPRI1vMWSNbzFUid8TpI1q3OSNbz FkjW8xZInfE5SNbzFkid8TlInfE5SJ3xOUid8TlI1vMWSJ3xOUjW8xZInfE5SNbzFkid8TpInfE6 SJ3xOkid8TpInfE6SJ3xOkid8TpInfE6SJ3xOkjW8xZI1vMWSNbzF0jW7qZInfE3SNbzFkid8TpI 1vMVSNbzFUjW8xUAAAA5MmY4YzRiN2QwNzZjMTk1YjhmNmU2MmI4N2ZhZDgxZgBmOTkyZDBhMGE5 YzhlZWNmYWEwMjViNzJlMzgyNzA2NgAAADhhZDI3Mzc5YTRhZGEwOTYyODE1ZDMzM2QzZTEwZGMz AAAxODNjMzhmMGRlYTdhMzNjMmJiMzdmNzJjMjdhNWVhMABjOTliMzgxZGE4NGFlMjBkM2E4M2E3 YzgzOGM1NzQxNAA0ZTYxMWQwNjRjZjVlZDI2NWM5M2FlYzhjNDcyNzFmNAA3NGE2ODIzYWVjMWU1 ZjJjZGViODlhM2UxN2Q4NzVhYgAANWM5YzIyNGM0ZmZjOTdiNTNjZTk2Nzg4MTI5YWUxZmEAAGI2 ODBlYzgzODVhNmMyNGRkZjMzOGQzNWJhYTg0NDdmAABkZjEzODA5N2UyYzRlMjc2OWZiM2FhMmE3 ZThhOTViYgAyMjQ2NWQyOGQxYmFhMjVkNTBjYzUwNjg4MDI2MTdlMwBiZWIwYzZlZDBiZmMyMGNi NTViNzhiYmFiMmM3NzAzZQBlYzZmNmExM2EyN2M1MzBkMDUxZjgyMjk4YWE0YjFjZgBmOGViNDcx MzQ0OTNkMmU3ZDRhNmY5MWFiYTNjMzQzYwAxZjAwNDdmMTkzNzdmNTU0MTQxOWUxNWQ1YTQxZmVh MgBhYWEwZGU1ZTk0OWI0NzhjNDg4MTk3MTJiZmQ0OWY3YgA1N2M4MDY4OGEwMjU0Y2UxMjM0NWRk MWQ5OTcyOTJmNgAwY2IyMTU5NjA3ZTJhMzg5YzljNGE3ZjgxNWY5MjA3YgAAAABiYzMyZjU0OWY0 ZTQ2ZWFmYTY2ODk3M2Y5YWZkN2YxOQBhZTQ4MmIxY2QzMmJiMzExNmMyOTM1NzQyYzIxYTMyZAAA M2M3ZGRkNDMyMWRiN2Q2ODI2NWVhMjM2MDc5M2YwMzUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAHJvb3QA cm9vdAByb290AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdAByb290AHJv b3QAcm9vdAByb290AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdAByb290 AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdABy b290AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdAByb290AHJvb3QAcm9v dAByb290AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdAByb290AHJvb3QA cm9vdAByb290AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdAByb290AHJvb3QAcm9vdAByb290AHJv b3QAcm9vdAByb290AHJvb3QAcm9vdABvcy1wcm9iZXItMS4yOC0yLnNyYy5ycG0AAP////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////9vcy1wcm9iZXIAAAAAAEAAAQAASgEAAEovYmluL3No AHJwbWxpYihDb21wcmVzc2VkRmlsZU5hbWVzKQBycG1saWIoUGF5bG9hZEZpbGVzSGF2ZVByZWZp eCkAADMuMC40LTEANC4wLTEANC40LjIuMwAAAAAAAwIAAAMCAAADAgAAAwIAAAMCAAADAgAAAwIA AAMCAAADAgAAAwIAAAMCAAADAgAAAwIAAAMCAAADAgAAAwIAAAMCAAADAgAAAwIAAAMCAAADAgAA AwIAAAMCAAADAgAAAwIAAAMCAAADAgAAAwIAAAMCAAADAgAAAwIAAAMCAAADAgAAAwIAAAMCAAAD AgAAAwIAB/oPAAf6JAAH+iUAB/onAAf6JgAH+oEAB/qQAAf6kQAH+pIAB/qWAAf6kwAH+pcAB/qU AAf6ggAH+oMAB/qOAAf6jwAH+oQAB/qHAAf6iAAH+okAB/qKAAf6hQAH+osAB/qMAAf6hgAH+o0A B/ooAAf6fQAH+n4AB/qAAAf6fwAH+nsAB/p8AAf6FQAH+hcAB/ojAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgxLjI4LTIAAAAAAAAAAAAAAAAAAQAAAAIAAAACAAAA AQAAAAMAAAAEAAAABAAAAAUAAAAFAAAABQAAAAUAAAADAAAABgAAAAYAAAAHAAAABgAAAAgAAAAI AAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAEAAAAJAAAACgAAAAsAAAALAAAACQAAAAwA AAAAAAAADQAAAA4AdXNyAGJpbgBsaW51eC1ib290LXByb2JlcgBvcy1wcm9iZXIAbGliAGxpbnV4 LWJvb3QtcHJvYmVzADUwbW91bnRlZC10ZXN0cwBtb3VudGVkADQwZ3J1YgA0MGdydWIyADUwbGls bwA5MGZhbGxiYWNrAG9zLXByb2JlcwA1MG1vdW50ZWQtdGVzdHMAaW5pdAAxMGZpbGVzeXN0ZW1z AG1vdW50ZWQAMTBmcmVlZG9zADEwcW54ADIwbWljcm9zb2Z0ADMwdXRpbGl0eQA0MGxzYgA3MGh1 cmQAODBtaW5peAA5MGxpbnV4LWRpc3RybwA5MHNvbGFyaXMAc2hhcmUAZG9jAG9zLXByb2JlcgBj aGFuZ2Vsb2cuZ3oAY29weXJpZ2h0AG9zLXByb2JlcgBjb21tb24uc2gAdmFyAGxpYgBvcy1wcm9i ZXIALwAvdXNyLwAvdXNyL2Jpbi8AL3Vzci9saWIvAC91c3IvbGliL2xpbnV4LWJvb3QtcHJvYmVz LwAvdXNyL2xpYi9saW51eC1ib290LXByb2Jlcy9tb3VudGVkLwAvdXNyL2xpYi9vcy1wcm9iZXMv AC91c3IvbGliL29zLXByb2Jlcy9pbml0LwAvdXNyL2xpYi9vcy1wcm9iZXMvbW91bnRlZC8AL3Vz ci9zaGFyZS8AL3Vzci9zaGFyZS9kb2MvAC91c3Ivc2hhcmUvZG9jL29zLXByb2Jlci8AL3Vzci9z aGFyZS9vcy1wcm9iZXIvAC92YXIvAC92YXIvbGliLwAtTzIgLWcgLW0zMiAtbWFyY2g9aTM4NiAt bXR1bmU9Z2VuZXJpYyAtZmFzeW5jaHJvbm91cy11bndpbmQtdGFibGVzAGNwaW8AZ3ppcAA5AGkz ODYAaTM4Ni1ycG0tbGludXgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD AAAAAwAAAAMAAAACAAAAAgAAAAMAAAADAAAAAgAAAAMAAAACAAAAAgAAAAIAAAACAAAAAwAAAAIA AAADAAAAAgAAAAMAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAADAAAAAwAA AAMAAAAAAAAAAQAAAAMAAAABAAAAAwAAAAMAAAADAEFTQ0lJIEVuZ2xpc2ggdGV4dABCb3VybmUg c2hlbGwgc2NyaXB0IHRleHQgZXhlY3V0YWJsZQBkaXJlY3RvcnkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAQAAAAAAAAAAAAAAAgAAAAAAAAADAAAABAAAAAUAAAAGAAAAAAAAAAcAAAAAAAAACAAAAAAA AAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEAAAAAAAAAAAAAAAEAAAAAAAAA AQAAAAEAAAABAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAEAAAABAAAAAQAAAAEAAAAB AAAAAQAAAAEAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIAAABS AAAAUgAAAFIAAABSAAAAUgAAAFIAAABSAAAAUgAAAFIAAABSAAAAUgAAAFIAAABSAAAAUgAAAFIA AABSAAAAUgAAAAAAAD8AAAAH///80AAAABAfiwgAAAAAAAID7X0HXBTJ8jBmWfVMp555WBZhkU1k EFCyKEmCCZAbdmdhZQPu7JIx5+wZzpwVc87pzjPnM+eIOeccvu6emd3ZZRfhnvd//9/3fb53wExX d1VXV1dVV1f3iL3EXmKJWCz2kuNiOfgtdpcQMrHlf+7u3nJCLJW7m713o3+7WqnHlIuFIhvwT8zC 6er+HZwe7t4yT7mbxLOCOD2NOPWk1hSnx3dwutI4PSqIEzfBKUpTqE3xesEyb+t4Je7ePjK5xI1q xwN3LR9eibQUXpFSodbnCtI0Gp0gS6tJI7SA7/Z2qIjM4AgxBEhm4FpCpCFpEJFUo1Jp1EIAwCEJ HSYgOBwt0Uev0BKpOlWWTKHlcNK1RBbG7SWSEdkiLiYCFaUilUav1pFYIZaFa0kiFb5Lpd8FcHkx 8amxcTFBoXGpCVGxFCwhE6jwLC5WWIjptHqABVTUKXQKjdqfy5NwOQo5ZocBiCxCBl44gb8AOjmJ cXkGQC6f2w7TZRBqjq1Sk45xQ4hshZTAHI0QjphMQ5CYWqPDiFwFqWuHkZmKrCyFOp3LsZVq1DrA IYIjV3AodKhjgj6gbzwKM8bFyiKewS7XaDEdQeowhZpiqlKRVor7pMi5HSCHY2srI9L0gFytXq0G lGA8WBXQYwtoSMIEudQLLAVr0wY+y5lnBhsCpN4Ze2osZJpH+DEZoSOkgF4sLc+IyNY2TUvgmfAv 0Hfqh0yjJjiEkiQ4tqosjUKt8+c50QNdPmaAsc8gcBkmUEvAn1I9kB1UBfbAlc+hesflUY1zMTt/ jCvS4dp0QieCTOIyHbYIYq2Uy2KLLi+L+JFEu/GpMWHJBUZjRxSXUzhsbdFbWAMKMhoWamqkUq2w BNrYPT4aJwgAS0HFAkMrDg6Yc5GhmEZpAmHvjCEAajhNmjHiMm9AzGGkoXzSTNczSDUtvnIz8c0t Lb4WJwCmUWN0k5gZlZbkHeMxnWLGBIAAAWBhYdBQVUm9VEoQMkJGNWmcAVSnqZ9oEtgyosriDhfz xyRmU9AO06NSE6Fg4c/BtWqMK8cVStAlncYSNNdkCoL/wP/NbKPn9+2FzBOXSQn0JCPcymkv3Evb C4MRMLETjBX4vr0wtxNAKadq9LosMKuc+FgBUgFwjDBQIKALApAVUeuVSsw1oI3EwD4WiADIBoMO EwiycJIUkDoZKMV4HTiMkMM/AfeKOByNOpXEgdrAFTIaL0IqU6E3Zgih/dESOj0YKgk0I1JcCU0Y AfVfgcRB5FzEvJUh6+KPqvMKKBh7e2dREeoX3boAUCgFmoTRGDyqlqFbNCoxotXWgLiIZf5Immh7 LDRXqtTLCIxVpMvAdVgGnk1gORkaJZEqU5CZGJlHAsOI63RaRZpeR2BgxIS0vgXaTASKRWmgD5ks +bXYOJhVWRl5pAL1FjRMowM9RVCYRo7hqG48oVUAmMCEQCwuMCIEAQtpzYEgoeYwoBU5i5yTxAKf FHNFQWkjEQnGilHwybAcw0C5HQvC2FcazA5jDzICYk08Na4ioKolpBka0AQcK2qkoLonwWR0JF2S 7IQpLiKXdEe+QcUAmghgUtD4wia4JjrLlmqNVWxReSD+BMpkpXmEBIGktEsZAmlECbkJIeAEBAzl OTEyRuJsIcvGuNEa4ziQXD7DZ9PxgFiQTdSKeHSzpsPCdBGxk+odrQ+Z37Cb9HSjQINxNfSt5Aq1 DFMqSCQiRoGy42IBbVwhcK5CB6cXdLQge5SkhnZMsJh4AgleZNcoLFuj1KvAoxOY4egP+FIBJFuq U2QTfJb+yCatso3ugxNL+UBwgUCtgZYe2Bv4QBKATFwH+OOLCTRYdnoqHFIXZTb6jRXCTkNJ4ZKF gkKBoDC9HVnYKynJl8zCpYRvSopzspPQOZnvS/3iFbK5mywRJLsWIgtOKSS2SywD0m6uDsE0zMZl KqtdguUKtVxDV6NewAroJZfXAQ5WEaVScjKAuQEaDYcDoibosYWCkKPRypAcsd4DE5kNPQdY5uCQ RLsV9lhCTEiMLyYHjIe+QAYYA6htgQ0jNSoCPAOjDVqSKQR6nUJJYgo5VU2hcwTONrKyGJSTnAxC SxhnvKkugvPY0H3UE6szgba2DBzQq1m4LgM4bcx8BD+4oI6xfiGlSaAqwQzK2FEkdIb/d2RPa8Mq wDibCSXCR0sSatuo0bkiND1YTbBboBqA04vyt4zkcYzzy7iY4TGQSAtRswz9BFJjj0VTnISDp5AR wG3QEWppHkergqpRlI1TnpnRFCvxNMB1DgdNe60m3cSBY8BIkUKt0DFem2HJgeBZSw7q2dBL6plZ q8FuUtrOHutGoBGHwgFggPwr8zAprtaooRlR5JsYmBwFGDXKC0I+EJjaQHEYAUBzejjrAN1Qn/07 C03f0nBwFGgwDmOcaGzUfE3BGE7QJKlkXFMIU3qod2XhMZADdSKjpynPFul6I1P4hpEyrIfZEmQA 5LN9pwovhllSTGvpeFDIHjxmZEiNXJcDfQJkcnCtFs8jEXmlVs+l10dsBhjIZdx0Ay5fg7thwIUM H8JlgdZ/tHY34re43jFOlx+4vinHusbC+kVDWlnFA9VW5jqGNtX/znL+31/P/zsL+u8Nd6llbQXG vcILW8srW2vr2e8KhMmylpYH+hfLg2OUt8k601vy/bjvP4rBmsVDAbNN8PqIv4PX7Z/hNY+HWoxh mMWhfSTljM3SRIt9ykeLa3loEXmIGTmG40marMGBNtanUe+pNRm91MZwg2gZ5Ef4/ZU6s6Q3hlx5 Eg4HLNtVQE9YcCwQDsoy2sH5xKNAjbKvygQLfua1waQh7w5ZM2alotYAq0UbTjlwVIE7qCNULBNH OQfAI9dq4LofTQGTuUFjZvl6hhlSoTAb1Q4VZis7ylZWgO2/Fy2zHAmjuYPYVq7QGbtCuUNnTCCL qkzFQk2cb8q1wWwNOs4YKqPqmGg1a3EyeohMlJmtVsWSNKNDilavcJUpthLS41SM7DJp/j7ByC1h dLHBWbZMO3T0NRg1t+WgIeDnqPPQGkvIoRfO5nrKtZx7VxXUma7u5dFTtCSb0+RZId3p5VPOfS3X tArQJHIXp2v1aTYV2+cqrQ3RBhRLK7hyObQTxeW5cTnIL+Hy3LlQzYEBS1UAJeYv5nAItU6bl6ol SL2StcaHTo4iXa3REggQhpLFhmgXinXBhSwvk9CqCSXXrIQweEgiIwQrnIhQcXlamlhfw9z25YHO KAlfupYvDy77tDJfqAdwsIgntCSSVGMHqACNLQXvzwWlRlD0SLWA/kRtUy+NPQMsMEQ74Dikqgi1 nuaDgX+As7ZaE9ay9S/gru1/SIK1GIg9rdMgfWBy+VKBEMgDJAAC6hmuLnAScl3CBSoduaEQEXId bdkDjF6QGQo5Cm0xcIa4I6+DIdgo8hWJ2IFGOgyA4NmhBUcnDR2nS+rFT3Hm80wCFWhVF0+v2DBE CVjdoUYcfbksGOgmgz5CzZQGPAQ1hut1GhWuU0gBT+SEllCDdaEOzyTUmFyrUQEIDcCixeBoCZUG V5LNVQlLq7ZrB39SQ0RxxR7riEszMVxJALFDfdbI5VCLYU4ZMrWLmo+l6XU0JBXag93CqCZggA90 G74gwUjTYCxvxtaAzchbVyNvnYTOfJGI4S41Hq7ob7boUDEyFLumXA4qFoFjdCCQwCh7kKMAhgCu kGGMna4BSUPxJsBQNt1qA8eExnWCiZsBlzSGCWkWTma6hPAyU7sUmyl5p9jMyD6aM4iyCPQG8e2f kMA0SJFAPZUmARZaln6qXKWR6Zn5UQ4ZRSD0HIRLfAikIEgMrulxBfJwHKkmHdHsJaGASPVauN2i zENjQ+qzsjRaHeOPlBJURBdB4lIOE5M3obyIwzFE+9mbcSKos0SGWWDklaniYM8Tc11nXM2auZvG EfArEykHxR6t0QZ/CAGj5NaJM4L8OOpYbdKpElDIjJaDtmgMRbTTQkUfaKes1L6mj1uF/AXPNNmP XGuZ+guu/99f+P/+Qil/4Z+6C7ATaGDL4TLYYwnAoMg0+jQlIeij18CFPAn0IdxfIZGxQVQLv+Nf CJ251EYUV+gsSpaIHP+vdj3QdP5/3POgVLI8/X/Y8/geE/6HXBJuEbcMj+SfWn6Gp98zrvL0H25b YZP/kWk1ta1eFbKt3vK0f2Mt7iFWKpSa/9pa3KDuofFA29xcjtFOmJoJo5WARiBVo1bmwQdcJiNk qSxQMUdGyHEgSamsRplXxsaZN6ZImLdGZIbG2EjBW2QIGH8AdocLU5GSuTDkyOS0wPf26BUQakAo wmVMHQoEKtCIHsshqBwNoO2VuJRSgjR2FpgLpS3tMaSUcxTArkGFrpYJDX6JOUvM5NNU80HTbVuK iRLDxpQJcIHxybcty+nAilA7VCaFlpBqtHBzVZ2Psx2m0g4R/Y42dEYCS83/UtXYZbQCMkv8g4ww jJmpAmN3SavBzJwnWokxTVAyVFYDGp0/A2alLRY8m4UOWBFKRPiP/T0zh8+QUkprRikrAYhuCdNo MboxF2TQqEGjt5kR1UZXzNYwkXhmUwsWGoyv6RzjmstO6QmH0qkZq2U68xBW44zjlZqFFqVWbJBa eyw0m9BSEVrg5ciBpwIz7gzzKRtX6glSiDxIM2XBY/XNXG2wDLEl/WE2LObKhGUqLWgVHrtv7Jwk qKFT4cqu4l53RFi8Pxez9ef+EP+ZJ6G9Z60h2sBwjefEaERIB5/loajwdDruwNYLtCMSQhg9TjDh yDxVmkYJ/FCANZPt2fGcIOHwLdqNMUXGwkZpQgqdUd9y2RUKYI/sKUD/IjqFu7Q3VQ7a6GH9Pm2M Swwzf/hWIpLses5MCiRQc2h1gMHlgZFOpPkt85QCgAQJoCQxQIyQGSMvttnpeGk+MaNfykczRWTJ RSN0UhGU1O+EPowgjHtmFO+KuWemCP8jz8zEL3Ov2P6ynCinXyaviF/mI5bjSmUaWDfZmO0xh9Hv 4QIDzUq4OkMrPtArmD+YSQqxSI0mE6WkZasgjqTc/BQMbuXCSnDKwpQu0BZycV2AqCEJh1JFoFRO DKwGpXQCIWUiYApYDnqhE/67DiKVQMLa9LZ8qoi9KciH23Tm9UxOUaA9OqlGRoAZANkC1QpYs6Ht YIpF+cwfuRRXjK9ZT7kY16QQTFQqpoP+mZTlgjIuC45rfG/YR6fdRJoY9kofNWRwOCCAgXeGyWCw dabFhl5TgR+mt8zog9UhsH2YkmQyWBj0JgylrQNqGcgYrOxvSNVmmmO0FJe060U3ZmfHNWQdocxw IyztudlhgkjT9yyvDQkbSgwvAxnNyKT83BQRVSPZWcTlG9wgWi2LmTQi6tms70ZUlvrN7oHBuzSh 34LPyTIINO0MkDU2sX0/Y14djz2evvQjPQgGB5DyOs1knmvcYkeyLqZ35VlckZTONrJla02GZNMF Q8XpLItAU/pMz7ZRB9ygZuYxYGYxaW/XfycHSmJhX92QcGa2dveuWFzcHcf/+d6+Mentx+Ue0frZ NLPo+0eH/uu5R/ZYhpzMUupJjFWGjr4gAvA0oONwEgIJsQRtHvwDU+IwOUZDcSWHgI2A9RCmI5RK aoWtkNNennEBjTJzwByA9VNYKbBKPA8WoZWw8QmshI0PYCVM5/XQm0TG1uR6kkhTZpqucxEL1Do5 KXBLt55bb8DKIKRx0RW5psc+rEEzlBlyXUzGgAJideWH5HvR7h8jhGB0qOrGAeRyKp7uaZZtRerT qPQpQ5Jl+RO3LOZefSfjSsMkAaXlWcD9vySZ6j/PjvqhyVEm+pP4d3KjJD5l6U9o28zokFdMj7t5 llOPe32PDpFEzFJh5j5+FJ5JAMHSEqX0HJ4NhgzqOUqJtyXggR60EYMRWq1GS1JbNiqNDCHjcMIi IkPje8QnhEbF+zsSuTpXDPxwA+ZBQRJaoN5ywX+9wX8qUgakOlsOlCRUKpgKUJmLFCCjcvuoc90x vZx05FAbYolpQGL0zHaHHkwNEoMHuXBMrVfBU6AaOYt8jEoXIGEEwR4DWqsArCcJFxIsK9UyXJtX JKABhFgEPKAERBMdUskg8CwooOAPKbWkASIMFjo6jUZo0jkuj/UEEcD24W8DCi7HYKEIzKIRoyg0 aAd7LNiAFVercYFCDRbA0G5owHIDDBEQbQInFaCvcAoBqoxHYDV6HamQIXMjEyiExnNkJg2Zn3Ol 1JQMQ5QBjipwNQML2kwxOQ0hJ5HaZvWa0Y6B0dGBqV0SI0IT/CVYSGhQRGB0alhcTHRCaHSIvxpM ZOrclbXTu9ShLBM6gXdIMgPEZekgWtXIiCxQiAlwSwd3DYeROGWTTYWYUDFSZaTAmR09oR8YyUaQ pofJQH/S4eFjVl+M9U32m9CBKBgQwXJwNToyl0kA/wOdoYOHgqBBhKMHh86Fch4UKMUFmK90Degp jtwIJBw4PB+V96MHWKfRSzPKEFLL59C93f8lvSotS59ZzjX1rtgdKpI0r3LqVs9y0ALVq5YggEpj 6dVyeLgmHjFzJMeVCk/w3KiTdHD/GkwZUqeXyymvEp7YUjvq4D4MECmkCjh0wgHl+wGJxpBu5WNM zraECrSEBSa4uWKssAYQVoxSxpZgJZ6lYJ3N4GAwH8FirKNa0ArD2H47jLLHsCqaEaw4nquIUuVC oLC5cC7TbyF7cLVMCH4b17sYhqKZYK0rRdn7amBVUtErLAwwPiQmng9gDKtGiS/91peHgHylGbgC LAcxjHZhkOdKP0lKxeS8vSsmS97u5ZQl1/LJEjB9/3vkCNph45izTiRCGekS3d29LBExAadExbRK +WQFdAnwRiSkz5B9XygAEhOBMOIDJeUWChOZ8KmQTHiLyysT3uWRCVexSiHVauDRRzPfLQQd+gJj AVR+FANjOEGPY1INUPVSNAQm5/CF/125soVeXyG9niyleqITwuLNxMq23PrMtvzqzBaukQvphXLp GonxoaYVMHvgqKZn6GAiE007x9ayRoyKL5+Q22NdFcAeiyI16vQMjVYNpR5uJaQq1Klw8UNHZ1Xp WrTDAy26hWKmDIhvqWKpDANqlefEfm+owzdelqVO9+d2U6hlmhzSjCbMSanBZYQWbl6R4IXOn4YD 1EOxFnWPFUUnuAvFVKaqGQFqnVJmlXi1jjq1CNU9grFMT3SCiEZUigQYBvUv3TsheM1sDhrTAcBL dhBVBbSDAikPmMdEBYUIeJIbvucic0RVKcRypJhAiXbvSClpqQ58ba2KitSQhipEbhZY0xYYcRdh bcGzodkivuHeL56hIsDRx/SyIZNT9lpCpcmG0bdgXKtV4OkEFkddIwOmI4w6EWqYBccxJJDBjTeh UEjFNtDWsIqkt0pYXaKL/E27RZ+fdfR3xARymPWl06LnZC2d8WWPhZJSHLmmeRjcOyKVOJmB1mKY CTYIDLEBjvhzezGJZCYgJjuTycng/+CHI9+fRhSsUcJj6GjKKZWaHELWzpDPAoMl8GYOkgINlEoJ FBMCal+LS1EaiRNYnWCJCWECbz4mxeGKCsxktDeo01C1MnB1OnLJYbYM1LFoL4xOvWN296nNLExN JwzaM3nryFUHNRVaNlYhtRiC4s1iNo9mhGVecxleU4slwHFHX0cM/s9444tjUi9ckB8o6CkW+GBt nPiiVEEKPSLUBMiHO64Ar+k2QhkTjY7KMOkd1iDZ6oE5TGwPFKAAOGCG3HUZ3BZnT1K4/ue58lnE UO1T9TAPYa7IE/wH0LkJJYZZT7dqj/l4iHy8RVGERZWTQ9PI0oqYBRikdErpRnZlK+qRQW6ujHxy owj2di/yIjhWvRQeqsznGNyUAoPJKPLlFUCc6DcELmLcFdpZMfFN8Ar5Jq7SH7r2cRPDC18UujyL fgldhjll5GDZQA3B+4sIqQZmy/D/F7kjyLuwLb93YVse78LZDKyCayXIRKBxEmkOsq7dQJd9GX1r FAcQ58oIlKwH0MCrYXAsQ5MD9RhQR0oCh9EH+nolxBUUtwNaWam04HHIwOs0hUYIRtNguJPhLHKy ACgD9kZI5FIZKDACYw2GMfFmk8qkk7GsvTtqasFiuvR/aGqZrgU9KjS33Ly8fuRa0F2sJNNM5lUC DP7DwFZkfBBGh2qFFbiPzyxHAowRlR5Bp0S4cQFTybRUuYJQMjfloe14Lp1xCV7TuV/I7vTi8tA7 aLaYfXPaaPmjW0GMWeG9uCL2IQQuT2R6JgFmHcFUHxodoIzKuSHTBFoCSDBJcFkBVQadebINlAoa HMiFsSsMfEhEfEJcRFBqXGhkaGB8KJ9jtI0MFmOb5WkoOCYkNDowCrQEty0IUqpVZNGZJNYrhYTG B8dFxCZExESzKWBVN0lpKl+jJpRwjE6v5VaN5aX7zbgnrJqYEwPH5xp2/kqDUdt9peYpNZXLIj4i xCgLGDqfwuILqs6ij2qOm6jOVGty1GAmcCuoDVhpBbAPTEQAZcxY0QNpFdIDYrm8nHrArTx6wEuc odfKbP7hHZzlmPPGWAucdyShBQaaFAGtLuWytjOpUkgK2lVih2Kof1ZHoKMeZTpaGIDw6EQRLGXG ALbONaTLmUuS6ZhIKxank7j9iLwIZky8xWjT6l8eE+N+PrVFZryOjRoM9JbL3kTq3r07dXAIWTUM +uZw0xqm6rX//kBFwfYsjxQqMguelW+cPCsyThIx7vbPz56UHicfMZX3KFOQOq3GfO/TYE/pq7Eh ELwxlXJKf+h4wn1MeIIPJR7A1TAulerhaS/KbUtXAP+YdQIMJUFS58BYrh98CUYabmrijC+Htpbg LYwYrpVmKKCTpwfjR7mJSpkAdU1IalywCJiMAnxhmILJbJqDptIIHViZClkbwToDpRlwxwnLUKRn MButTHaLCu54Mn2g9uM5VLaLFNIiV2jhKXjm4kglkyPKIgiFKAHJBPsSWwXK7IFZc1C+Ud6qzBkA O5vubpXK/TBVYdB1oDa8UqEqM7V9jAEJQQBcxpLxnLK0YE0hx+gCDOqmSCQXTg4kPxklBztJAaFW UPBhtMkei4uNAl6vFoynzFSgMBWeh+HwplPUUxwshWSg34x/g2m0sDrc/tCCkWBeo/gDtfsHyAdO NdrmZvhryz4dzpCFK3WU0Fuw7XTfAyMTIilzZ+g97FkZbfAt41Lh6QppGYiiYLlVLKa1raBIU+LS zFhcDVOGy8DEBrOK0GJbVvDi2syyOKjNtM48Vk2rjUszymxdmlFG86y61tons74rA/Gx35EB8zas 4FJmlzUukdlxVjGwa1ppXIoDjWu9dWmghrTavElda4zSazVlcgmWW2eRSW0rKAh1Oq6VEWUgCVWH QwiraMxbsIIoW6EuC0tX+sCFRRQmda20nwPNS1qZ7OoGQYLK4FipNqzgygKWwjqa2MgQqxjYNa00 ji4YB3aqDAzxECRYo7KKplQbVnDptHpSpyiLZwkUhFVM5i1YQaTJImA2iHU8MQAgOtAqGrP61uaj Rg13FLPLQhTMwFifmaVasWpfTM2hRRNDgZRhZczasIJLTsg02rL6FYYArOIxq28Fi6nVt4AljpB1 xHVWsZjVt4IlXh8fWpZ0g2IWBvqCVExirQUrWNIJtU6jKQNPOAKw2hez+lZFLg24I2XKGwQoQ9hM 6lvBkkfAPSSZJr0MRD0QTIgm3Squ0q1YUwt6LTziV7aJTjAAWVcOpduxplGBCdGXZUtjEYB1vWpa 3wqWTHiDB1BW1v3uzhSEVTzmLVjT4dCVg1dBl4EqnoGx4OUbyrCynfxSePiWKCLhmjIrMx2Is7Jc hJjjZ5L46VNZJAa1NUWZsc8KktQT3FLijyvBgsOol5gXxia4VhSeVp+OK1HfylB6BiCsbHfRQmvW ZERGqPCyfMbOgpDQKFxrYdToknIszkyR0IOGApeMY2rSG66eiifS0sBeuVFhTdvvh0+YSKNtOUON 5YufyCoW5/KS/8j9PR8xqVHiWgVpEjcJ1OkIVZbOmCsNzyxTcFRwg0oyRQfhqERXtFcBasJAAAxI 0akJ1AyjkrZZNzygA4QoAoJcUzloLk3I+TeCnnK2RqGOiJSKshlpqEDMM55ih2VhoAtFEYFurv8k pkbljf0Ld3Ob5d4iDpvl2nrJ/qX7ucUWcItkGqk5/vKe5/CqIH7cCn7WV7BM5iWV6ifB3cv6DhdB 4J7UtCTwf3aewwIdIinMTCGUmnRhej6MabYeVRP+sqlcZWHSI3VJ2Lqvc4ozcquMniWNOJPStc2o N1d2Tru8Nv03l59+qi5Y59Ancm1TT0VS3oKisUVrXyXqvSIOtRg3pErVhp25M1I2r961rHfv04e0 O2O3ej/NqbG+YZfFi8ePCvnicrhw0amsT53na/q9Dxz+rf7qklNLXOJvza99JGRxz8+iXd8iChdW GxzZYMKhHcNHdS8O+zmzR81pJQVfu95fNB6vf92pvkrbNPy94Pek0/s4QYWTQrc0rqVI4Omc1fq+ Au4s57UXRm6+s7HBt7gRO0b0OXY6baXnopPfnJoQPSddjdV8Fd5KKNzUeu3J6PBCp6y1jbu5bp0w 4fi++GOpn+3jRnVfnDJr9Vfh3sRps0cGpiYvjaw98Nc21QfliafWrXLSdmjg8z1188M9TtdIfBWz ctOtMa77l972GzmYvz4y+KVDdr2lQYEfdQ59n+zI/RB9d+Ma10YPo9XrQkYQq7y2JBZrRx0r7tfj jl/Mhi5y4VfP6WMcvzyoxO3r3CjEr+E3l4Zt01q/rHNvAb59+ETP+teTd/R9VeWIbqlns7tJR/w4 +sHHHCUuVa+ufqmVrKk+TMFJHnAkssGeRO5Hf2fytx2xQ93XiM7oXGfO6jGvtyDgy8j25wWnqgZ3 nOirGPrqZm6A3yD3BZ9OjW7tfmF58l8R7R8ebfo4VHm/01Tu3lcXo87OTx5RJ+DQZNdb2SvjXsqC 54/fyz3zwLVX0z7KSVyfjyVz+51SvRt2nZg9Mpd/eMzQOSMXjW64Zyz+OmxEckSVGG9PB7/kZoMj Fx7VDzi29HWb4/ptXRS7e2/v6ixNWTV5TWfCd/8fo04pY7ade6N2n9/56r4h3baJ8VbpQyYGPlXe mjT7wOJaN4dvdSXi/pR/XuMdqtstquUQkJzX5NzwZtPCasY4OZwNLRq35M0J1yur9PNz7fIbJH21 OZ/yu/ht5I5gp4T9T0+ET8w+39I/4/G9ZuOG1eGcWufRsenS5iefxeC/JreU5L/IGXJOXEe3zK5y 0+bRa4fHT9PMm8fbvUg3bbTn8XHnnXfIOzd+dGGN3OY3bpshU4MODe8/7unw04va1B3vFVv9yavm s9OOdVs3wyH/7EliwuQhHik/nTiQ3jB85JQxvn02B81w6RaxY21zFbdujXsN93x7NvTI5O77c7Pt v7ZZsH73Y5sjOw6XxJ9sPapb75subrPrDn31wmZK0yubjz6vdOQzTzglzbZI8Ftm/YnnQutuHup/ acHFoH7Nl5/a0H368azQ8x2iB2V4N6pWlQgfunjF7x4a16+tls+L2ZLbtLi+InHk5nsneu16UvS1 8MX8hodHl+yq0fydMvnXJu0bz1AOar/26MqB6R1LpPO7dTwYeyFxdYLdtV3vX769dfHOhzt/7Cr0 +/Y67GDtBrI8l1qTlQoBJ1E/SHBZvD2xceubqbedTqlT7jn3WiRcOGt7yz++1Pz0Oryk/pXLzT+2 rfR4u/fRjSc7h7Qv7rWiUe/bdy5v6T7q3ZxeKR4NJZ4LeVXE35KVbs0nTe574XU7u5fun/OP9HvS 82vLfV9/5V571Hzd50mC1kfrh3xrVPWdoL23kzSguOboc6meJy9Mal6yoKT9t+PfXj071tXv9KjQ x7bDjoRs7bmsxfLKw+dW2vtLVdd9nnaPq/eI5U7urznewdfFNthh6WC/kR42ugWiL+t7xt7yq53Y NUF4KWuYQ/jWjU9n+6xYei3i78bxd5UtFzT41XGdf/LAp933+xw9eG7T+6gJzvs4eY5vZrTPbtVk oFPshj1tuQWjfF5Er5TtfuTQwyVwyV/6yF+i6voLx0Tter3eIXxL3oB686L67kt05O2/qtQejql0 bXDjTaNfDS862z6q0xaiVqe6i2cH77aX/9rkVR+bcRm7B34NbHVzxdGXXf4OzMnH3e8tiB7mEVjb 2X5G38uDf3c+s9zds3eN1nNjOFVfDH78fvCrxCkOfQ52txn0ZOrkRjL7J79IZvayz5y92n1tU4Gw s3SD28HmuY2f/tHjUOqVXRc+/eZ9MiWtlnDhgXTpmolVKo+bdmLNs7wWZ/xm1diTN+fMlT9W370R eHDntrFux6u3PBw76ZR24bAFUr9dNc4/EjTYGuBT+ZXTy19OSk/verPo/O9z5mw9aPcw/q7n7O5r I3njr8/d+qShN/Z6297sB/b9h/WuoqyXdImzpI9tSSj2bscvHNvkyUl12mm7nCTmf9p+puqZNsEK myu/297+e7ONx87bk+sdI7wCZS/GZnglpXDf93ETjx/8q+/t2557d3l1d2/zNMV+8cY76Xt2uAzU rwpNj6h77eDowLCp+h2VyPX9ez1q9eBiwoemh6a927ApYPfTSz2U7Sbp5/7hN6z/oU19z91tNnba iGje3MS4GnnNTh1r085h2JV6M+vddT/XJKyyTcsr9casrTZ4zFuf9jv3TKv7rt20aliDut1qzlnC azlhk61nfQfF4BXxX2yOrxOnhHifEogctkx3m8YpIVp8xPr8rV35MkEyqCfWfZ6ed79aRufkPzd3 +Ka94J/cdtrWRU5Sj6kNlcl4W0/ZeOyib32bCV+aRDSMva53rX/9RW8v/2FV/as0HLqzh83wDrtK Zo6/fONb5xFtPxHPHpZ8uENuHlHS7bf+T1KaPE7dMW7UX/vX9qvsknpN37hnkycxzWpUH5AyYeXd 3k8rbc/07cxrtnDN4CY9ouas41x527PJ5dQ2vVbWWjiiZ78bQx9LNo+sXLfX1LjbsZce7W0fPG/p 63k/6WLm/KzO6TflYOPhZMqq2ILlsdpOJVMVq4LHhr25NvbehJSrrgm7f5Y49Ezan1vzzbhJnsne ezw2pV19O2R/3xabPL07V3u61DHZf92gzgWd5kde2hyt9rERD1CMTZ23NqORzrNksiJo6/6SxFcT ir8uLa68Xf10Lpc43SMr6GT9JI+pG4UT7/edPb/e1jnLO46su7dax5KzLz0qpcRxw6qlc/50btQ1 T3anZP/BoEbVAnzJ5yVbG+QW+t5c4a9Y2FBdC9u9YdHErxcDe8zIq/t7caO2QS8Obnm0POKvyuOb vaw6udmhKLsDCTW3tO3beJ9MNGaNHbfJhLgGK1dvzdq0rXigzYWxw7vU7xo1ef6uqh18BrR1XX5r SN9BbRZ5961e5e1s/3526tGY9G1jXJfW8LhA0n/w876ZzWM2SewXHO857MzyPtltREMPD7zWunXB s/Zjtg3wWPwkVfLx61vhrjBV6LnfCqKwYWHJl3YePjI5Uk08ffTnl6FVix8MfXdqaMima83G/1zv zoXky6+DHSY8Wz1g2J1JjU60nzXqCHm76bYV0ZJPd3j2NVVDPXMWNIyVdVpC3I27kZemnBA0BW/W W9B4/b4LC3X3ag18cqJap89pSc+2PG2SW+ld/SfNB65L2BTyl3TcllHPh1T1afCr5s+oHv2nYVux pheDRvv1/PDz4Gfv9390viSVfuENHdSrqK+ob/HkpS/IFEHamZ2znNQDO476eVMxvjFmoazLzaFS 14Snbt6DMEmVnA/HJF97trv0sSDB/wu3Wg1RJ0Xros4Pxq7u8Hzv/tRdmw/zh+wV2J/4q9KA9Mx9 grP1+rzyvHR1du2znX7y7+1YuO3z9CdvOjvcqPdrl3nVJ/f98uH+ismP3qXX/S328OrJg/xuhx6I Pnaz537+ouhGsx7n1Pt0evfrFZdXNM1OWh15cYvwaIeVR6VEy9f78qYk9RgUcKjZ0UvErACnzKvc nv3vc5RjfGXi6qtifQ402j1b0NVHnPnxU7uRAUWZa+99cQxqGdS6cnvn4Jqy+6LYyy28Doyrf+zt 4OJdRdJj3mvlykrfDgXe6PemzoZPTq+WuHumtx+cc6Xbm8nhdaqGT3Fu2efAxe7LnP5q8MAv1Nfx z+ojsjzTExtlvg/r5vfK/+0fdU4cl68PbNl1ScQkQZxy+Mf0u85r9QMb93P6fWnS4I+j2n1I2LI3 p9eyTZva838Tbqw2duhNhxkbnYPjX7zdnHPs0oLFPye79znQf31Ax0opD7ulejU4F7Q7Xal0b1Yw 6MFrl/vtL9kPvGTfocb+0x8y/n5avyQ4aWWHC/XehtccuO+2Z+euLU+O77H0yYrlojOfP60bsSb/ xawVL2YvDtLXyfKaodt3JKqruDgtrcbb2OJdx+e0cGk7vtpP/odSuh5+rli2+UqLiT6nU65n3Kl7 tkqrBWHyxCKbHh17z6wZcvaGcmz7nme98+u5ZZxYmVLSNWVCRvI4t4jVDys9iKu8eeISn6K6z1pf Lfxl5ohX2ju3H56okTVOsT15z7NbfT8lH7Wbdaf3zs2+KSv1swMuFR0IEEVlxNWLvPsFb9e19bnJ Ssfs0c5HFnn3Cn+gyE/rdy9kxqMzXSTh4U4lF/KrVMp0ip33fPnLh3eO117adFPJRZk4RFllzxJx 2xbHUvbnjCX2zhjtOyfh0BlVu3qTfns5rNJY4uzw4QGLrnhuJq4FK88e18b+fOrolE1Nm/i84KS+ PP8k5FLe1YafWlW5Juq3pfo10TVlp2K8rkraZeO4C+GxGq3ITu996UZEvfZ8+xP4i7ar4ydmdnmz ZdeE7L6asW94mx9mb08qfn5y2cnaN6651HOzi8iqs37nAbX9E8d6yrb7n1Qb/2H6qNoaTp3fwpLV iubTzyRum5x9++a0ppuO6IevdGqUPSSZp7zaI3yV94Gzj/3c8xP5Wo7H+YxRZ6ZENzihze546tdC z+ajMzsoazfeNwYwfVm2fNvKNvbrBm57ONR70yzHbXa4x92g/CM/z9h/KLKBst7NvFktvZL+fPVb ceumxSs+Sy4cdisO9Pg4yyb9nv34KX0LRr9rvRc7UJ+YxZ8+8dpTadjJP5bfTxiukLYflNd+7lDl ZadtrVvMdCWXzOtZYhu1M21WQ7eht86kTOh8ueHCqYNc8lqFHy7cs6c9b8KMke+nuA853MzzUaOO zlfOdj6068HItCMD189/6vLwQdJsF9Hrq9IxZ1q/n/Bk8IHghr6xJ+ULbzwOtC/SCmJ6D577cdOT uk/7dR3l/rFL8Wh37ergR59qrpPEXX0yVPBk7563c3NXZfi/aZSR0tHu+RA8dLvDlRYFmxtu+tm/ aqxoRJOdvTX+t3tP3mIjSWvYvCQ64DPvWu+inakTG3D6N3zbeMRP0x72cWzl0DPj0qbwAWfaRl1z y+y+Opx0mZVt09npeODQXv0Kk07sVyaNPjr40TpV9NXg1LZdDp2MdVq1IkC3ZXLBTKc86YQX0lWa g0fudrjnoX0T4R+2QPLzvdH5/CtX/Masmdx475YT5xfvW3J7zKmaR+Iq+w1ZdfHkTFXj/JKNGTun X182teGQ5gvlrjvCZHM4zWZf4j/dWdBv04ekBWMPtxzc1rHHmSNNJfOXcWI+30graLt5mOe1vUfj 966t+eeG9Fc3F+r7Nzv605AxtYqnJ5y0a9zg6tp618+srpZhOyzeKy9raWRcy+n8dm6bvdTbsprJ aw599nO/b6GxY953n3Ku9aeLL6YePn5zUnSdDWsP3rh5uuszWZfhqSS/RNNi88dn7/r5cQ58Cbl8 THTAvfujE89T28miWg1e0anw/JJ70U4tCic+GHjKxcYj6K+bj+9XT1DMaDJx3YvxV949GMd/XavE hl/tcz88d2mbyjWjFvZyHsw/r76fMEVUafo9m+lRT6+8dLlX/Wlgo/yuWxf5hF+/ueTLg4v3J32b Gln92LwR+qZxo2dd1x3mRkceEH1xWv78kN/JdyNkkZPP5Hboqjiyavf7m08720deCZhT7xf/m1Uc mzf72KBoU1Twvjp+0/c2/GN+H25O9U3jd/qm1m+nfNlpfU2HsUVNzkneB9/dvumqe32dcE2DqdFn N5T8tWeRdFGSo+DOuqgWl7r6bZ51dOCMzfuLzxQduNWpR6Pcjp/THwzrJ4/aTbzqebrR8eMD5377 ZXnP/L81NX3m+wqw4+67RLefY3YnFPknSmYvq52XUnnf2eq/X3t/s57jlDq/Nn8gmf+0wf30wpLD ztO9frnstqr4z0+SLy/HPqxzNv/vjeo9E5dt/bik7rbsq27Nnky7eZH3fJ40fsazjfbHXPfcveZ0 6NbIEsfkLrou030eDuxUrYXwzYItP7t0mC4eu0/CvdK4M9FzelwbxzOBx4ju9W6qp2u8m2+/pui8 8MLEnVmjby7dktSsXdsPPY8JDw3SvatXsr3VxCHffg2YvaF5v+ctS2bo+ftWbz717NVfb2yeXMCu XXBr8fxFq0ZH9r5t7jLs8ucJV4JaBNun3X4b5n35496fTj3i3Gn+8YWtV6vjbYSLM6LXj2hjHzfG +6e2oTEf9zx4fPsGPyW1sP+JIMJ+7O+7W2zLPDb1yzfNjiVOl+Sbqh6dN/fw6eTbF3bcki/xtPee vPvOzZ+wZpUHyB+v6f0gJbvYzmf2serjhKurBwbrCv5W/j3bZuCe57GhvvdunfCee2+9j3rulsDj gY+VD6OrTn64yf7xuN/f70hefH7prqiYbR7F4/Lyk2YFj3hSv0fA01vBXzy6d23aZJt7r1SuwIt3 ZP4VWQ3eQTy4vVvvQxunzNn9rueYTx+3zrVvbsPpX92p2tfAm6373LjsO+jO46Xcx3YTdNrQBV3v NO+4qXXJOA/Oi1u3Hp6+s2+9SNSrl/8fO96/f3BrT0Hc6m8fPwxrIro+54+CQxMygqc2/6uw3vSb 3QtE7T4qNwpGX9o7a3O3E75+0UPjOC+mXIpo97xIdmiX2D0xKzzRafeHEseaielZW5Mvjbi4/N6g A8EXf334aZ79eWHdNk8O9/MeB9a5yYfEZzzGxW2vkb+8x/L2+7V9Alo8rrfuBTZ1Q/jHVh69TvUa vchV1/jQeP/cX7b8fnnt/Z9dVgf5nlFFrOvAP7s37vGjM87T1q+4qN4iyX7YbKKfwjavw6F7LWZ9 bKrRHvtaueTCT01iun1uKmrX/k6Jo8OcIyUTnf0WbJ0TMUIzZvrCGZkzP20P9QgXRt3rn4LLXE5s vDo2cX6Tcbwle8/XU626c/RvvxZ/B17o2uSXFp1iR6ybJoj7NCs2L3rNbx/xmLPTFmydN2zS9JnO rQZsuaY623fBJ5Wtepyd61/3atzmVr+9baPbrbz7C/2bVLv+6I+NNY92XR+FN39zriTveajtxj7r ztZf5Xu9Xc4NrvMI3+xm6a9jjt1u16za6YhE0YR8h1nfzuxa8ORTw2EP91V+0WNlEyfCe3ETZc83 DVos+71zRiB5NUy3XLgqzVcDBuht9uNGLQuGPPiaW9j3w+djh750bxq1+EK35rE7JrRzH3HN4/mu rpIZ595tXyHN/3pb7dMm9oZPyInZo7IOzIyevsRjevX1N06u/jq8y8r0NZUSBg9af67/p+jMPsXi CwOu1HlwaVHLutOvdiW61JrV8OiEEp/wt/7NiEc89Yr6lz4uPXdj24GST+G7RxF9q/T72N8tsv/r a5rfs7O759fw3Os6r8rJXc9SW8bJg/s8yCyeXax/5BbdJXJvaNSkMc73J754tuvvOYUb7oYPCzgb e/TN3OH+WR9sWz348pubOGrTkj0rPxxr29tTkNN4xbiY4IOvRT3sbNx+eryndcyb4OV3Xwxf1j/T k/9+UdvLYZt3fgtZ3fVNrU7jnoeOP33Jd+KH4cdjNySl52ccnUM6fppVW5Hs/mCmx0/5cvdBh/76 +DipqHrQqeZY0nLfuiNmHHq87dbUma0wzY7b+7PwurVvz9cmjhpwo2+tycuI0bVzto/doz/bfFnN PkeLXbanrD7Zdp+oTYjL64Z7uo7MuPHs+PSTf+oy5956eFCX/PyRNPLd40D+u59d1gYddz0bssqn ytojLUce/9JjT1xR3/il10cev/7gadHpuCmFnp8uz27tFafePO3++5Xj3/wm6F737ZcISXpe+rtl gXMbdO+vnu81u8F4j4CDvW4KUpXOdU5/+GVvcOCwZb2HPd9fwy1pya0pi0823o93cJnlsEgx1Pbd kIOF6s79vEe+d3vT4NTkl8K9mrisE+Izd1dtDfJ/8mmH15MCv0e/nH1rf04ye9zl9Y9yPvZXqdaG rlqd2HNnaNjJ9V4qj6jjsfb2nzbYn/3qElOUfOhFD981D4q3XPvj0cQCbKZu6tlxq/xbL5oivv70 +J5ugXf3nAm6gvtttE2sNOdN7yHL9jzc27ma75SRC/TTwhPfLliw63Ydv7S9dYvbadxavLjcmHet y6xK95+0Cvj78UgiB5sVs6vDsRW1e06f8uiaV6uinQXnXvdp1KLyirhaUZr0Vy+WpAj2VJnR5V6C 6/rqyipnN0Y/+bBrxrflVzpp6w3Fb3T72H/ZfOedz6v0GlC5dyIvo77djtYFj13q1T+8tXPjA8dH HwiY0Vv3in+/74q1nLVql24bWz8LeT99zYEYcuc8n0Z5ux/cOCv6lCUd7jw6TGs3QLXOm0vcvhab VQt3yd2yunvb+a0DO/eoHy74ffSiZ7XXFLxc8PeoZr+H7R/vXGlfs+rnh28IC7q68OzezS9CVKuc vAY0CPglNWCQZMepn45i1T/dVfjN9J14tKDX68iX95pdWvhzVW2UIOXY7G6rmjYp/Kv3ur0Lpv7B qX2rvqqpTJfqt/mo+N30STfPanvMTPf/yfnJw8L4ZsO9rtwdVpg858TiL5LmNrGufNfwR1V6nHW4 fPLJpp03+s3+s5bTx8E99wfZmO+FyL+/B4H2Buk9hTSff5YDb3EPQpOVp4Xn4QFNwczf8ES4Ozx8 20lDZuhxrHMO/OSHWgaeiTysI0GSmF4tI7TUl0wIrYqEFxPAh/DoRCw8NlLI4cSoMToDlz7h5IJu MsjKMwEl1IQWV2Kx+jR4T3KkQkqoSepCWebWKni0j0U9tTsoUFKQpAghM+dn2r90p42nJX5a3lfy kpZzTKn9JLlhz+57Yyoukwbj7ingCX2hY6pOlSVTaNFBMAwznsgx+diy6Z4oczGRKhPuEFu5ZJDa OiVy4Te7MJPG4Klouiq8uAjgN1Io7I7+8bl0fZ0Wz8K4WhUm0Moxc5pCu0ckYB0TY7GI6ASsSyJ4 SAiNi0I16Zs+rJIAsaJyuYKDfhRxONT2rlzD8ILa5M3SEnJFLjyPCt5Q27ysr1MXsIGKMK6lG5YQ BGnpo6N8jgnL6eZNma1Fx/w5rC7Rl8EaoJnzePCwuEDuatYf43Y13S3TcedY7qgUsAGOk4EnmFlX wQiZ0g5rmFLOfLTClEUSLhYQYJ1N7I7S1/OW4jJ4htiKRKUKnJwoQrC2mITPF5U1HAGlPihuFELA GkoAVdnfgSqzI0i2OFYYwXQCfcpDqUmnR8d45xjgPrz9Fl0pzBPzYfJLBwSM7uUzgmNc9MIXo4vh TYzsUvhMXcVPlaMDy2wA9MJQzP4uGQ1AvfKlKTD0h4K3x8gMhaoCN9jBO9A46C5JSokwl3FbUyMG AJokDGNfj49SPzCsiDoRyTqXbPJhNQk8XsUV9GGnIfXxhy84rLvz6dShPugbFTAbyJ76xAV1GoP6 gJM6D12SzrEFIiSQ0CeiqYQuXh9MoIBKQcLjGj+2AG+epb5IzXynxfKHE8y+j0Dz2HhXOU/Ch59g Ql9hQLfOMRhQ0kqZTdNn4dFd/PRleFx7Ln3/na8tx/xKPDNSaGJ4Egq/pdv8oQibf3qbosgsSceW vvIXJeqwvy4Bigyf3Oayj/rQ321GyWem6TnoQ2padOCfumwUDo7ZcSoh/aFviJPnxOKXH1aqZWYc uXQjXD7rYkLjYVq6OZM7NhiO0WXMBzR1GtRX+iqTBObOP+At5cj1SiwDfcUMCJgCXV+Qrse1OOAA uvCFqgKP9FFnx+gPw6XBA1s5BDqDJQMTTK1TKEE5mZemyaWqUKygP5YJZDRSJEgUGq8IyTWyFGZ6 IWjT60JIFWBeqlKmzPI3gAIFx2UVquibbko1BGGYZMBcYNpxbTrBKreGhwEEaEphKdUIhYO6sITd SKmaBmjW93cE9Ef72ISwviIg4Rre0GNHv2JnONK9rlgzxkpmzTH9q1BzrEqG5miNIWFf+8+NDAwK jfTnlv6uPGIO+paNyXyBbj2V22Y8MUmn7sFrjFm3WjBUMclxbPQm9wPwmVuRI0NSIyOC4gLjeqTG BiZ09OcZBw/jsQaOuhAftculL4k2+Xo7so1u7D4ZVAd1G72Rd0B/ohYZDc1uxkAmsGuQUAn9cTlG tGyRWWXfaUy1xXCI/YE66wOQmBgRUkH+wyrlZr9er5D9YO4ngoZgs/9LmQ/ZY8p7uo6JMbGlLoil p70dvGKQIpNrflk37cBa+TQhPVz07dymYwUsYtnDRKlu+mtZKureYSJXQaKBB2YdLFO5Zv0uEx9D 43fQGi8NZ1+0TnURKRDud8fUfFCNBFobGWPrmPHCc9S+6fXjrHvF6ZukvjMILEXI7qFpRQuDy/RA TN8VTE8RAw8NdYD3wl6bSzzKmfvqUcG8W1Z8ACwaTOIBVB7rv4ATN8EJDaxpjrFbOWMhFcTL/vZF qQUSOx5Tnn/lhTP/Z7g7ICEuMCIyNM7Ozg7G1v4P+/qVo/ieAAA= --=-K9eVsl2Z6b5TwqVEgqZb-- From MAILER-DAEMON Tue Oct 21 14:40:08 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KsM9I-0006GY-Jy for mharc-grub-devel@gnu.org; Tue, 21 Oct 2008 14:40:08 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KsM9H-0006GH-AE for grub-devel@gnu.org; Tue, 21 Oct 2008 14:40:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KsM9E-0006Fa-OV for grub-devel@gnu.org; Tue, 21 Oct 2008 14:40:06 -0400 Received: from [199.232.76.173] (port=33022 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsM9E-0006FX-IB for grub-devel@gnu.org; Tue, 21 Oct 2008 14:40:04 -0400 Received: from 197.red-80-32-81.staticip.rima-tde.net ([80.32.81.197]:38516 helo=mail.pina.cat) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KsM9E-0004BB-22 for grub-devel@gnu.org; Tue, 21 Oct 2008 14:40:04 -0400 Received: from pinux (250.61.221.87.dynamic.jazztel.es [87.221.61.250]) by mail.pina.cat (Postfix) with ESMTP id 6917D28904CA0 for ; Tue, 21 Oct 2008 20:40:00 +0200 (CEST) Received: by pinux (Postfix, from userid 1000) id 68A711AD29; Tue, 21 Oct 2008 20:39:59 +0200 (CEST) Date: Tue, 21 Oct 2008 20:39:59 +0200 From: Carles Pina i Estany To: The development of GRUB 2 Message-ID: <20081021183959.GA12487@pina.cat> References: <20080920203745.GA27562@pina.cat> <20080924103424.GK6973@thorin> <20080924160724.GA10087@pina.cat> <20080924163322.GA31610@thorin> <20080924165056.GA24548@pina.cat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080924165056.GA24548@pina.cat> User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] Menu control for NPAGE and PPAGE X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 18:40:07 -0000 Hello, On Sep/24/2008, Carles Pina i Estany wrote: > On Sep/24/2008, Robert Millan wrote: > > On Wed, Sep 24, 2008 at 06:07:24PM +0200, Carles Pina i Estany wrote: > > > > > > New patch is attached. I also improved some other thing. > > > > > > Feedback is welcomed :-) > > > > There seems to be an off-by-one problem. Try with the attached grub.cfg. > > should be fine now, sorry. pinging... somebody has had time to check it? -- Carles Pina i Estany GPG id: 0x17756391 http://pinux.info From MAILER-DAEMON Tue Oct 21 16:52:18 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KsODB-0001gV-OH for mharc-grub-devel@gnu.org; Tue, 21 Oct 2008 16:52:17 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KsOD9-0001fq-6F for grub-devel@gnu.org; Tue, 21 Oct 2008 16:52:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KsOD7-0001fP-Fs for grub-devel@gnu.org; Tue, 21 Oct 2008 16:52:14 -0400 Received: from [199.232.76.173] (port=44908 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsOD7-0001fM-78 for grub-devel@gnu.org; Tue, 21 Oct 2008 16:52:13 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:38120) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KsOD6-0002vx-Pv for grub-devel@gnu.org; Tue, 21 Oct 2008 16:52:12 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9LKq9TO003591 for ; Tue, 21 Oct 2008 16:52:09 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9LKqAeX104034 for ; Tue, 21 Oct 2008 16:52:10 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9LKq9Xu008652 for ; Tue, 21 Oct 2008 16:52:09 -0400 Received: from [9.53.41.42] (slate.austin.ibm.com [9.53.41.42]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9LKq9qE008630; Tue, 21 Oct 2008 16:52:09 -0400 From: Hollis Blanchard To: Manoel Content-Type: text/plain Organization: IBM Linux Technology Center Date: Tue, 21 Oct 2008 15:52:03 -0500 Message-Id: <1224622323.31194.81.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Cc: grub-devel , Carlos Roberto do Nascimento Costa Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 20:52:16 -0000 Please CC me, since I'm no longer subscribed to grub-devel. > From: Manoel > To: The development of GRUB 2 > Subject: Re: PPC64 > Date: Tue, 21 Oct 2008 14:43:25 -0200 > > Hi Hollis, > > On Mon, 2008-10-20 at 14:32 -0500, Hollis Blanchard wrote: > > On Mon, 2008-10-20 at 17:18 -0200, Manoel wrote: > > > > > > I'm working in a project to use grub2 to boot some ppc machines(p6 , p5 > > > and so on) and we had some difficulties with a grub modules problem. > > > Grub fails to load modules. > > > > > > When debugging I noted that grub try to find the headerinfo modules > > > struc (which is identified by the magic number 0x676d696d) in the > > > address 0x2d000 (_end + gap aligned in 4k blocks). > > > but this address does not contains the headerinfo. > > > > > > So i altered the source code such as the memory is searched to find the > > > magic number. It is then found at address 0x38f4c and then grub find > > > some modules (but fails after) has showed in attachment grub2.txt. > > > > ... > > ../kern/dl.c:527: module at 0x3e0dc, size 0xc9c > > ../kern/dl.c:556: relocating to 0x28720 > > ../kern/dl.c:513: flushing 0x4 bytes at 0x28190 > > ../kern/dl.c:513: flushing 0x14 bytes at 0x281d0 > > ../kern/dl.c:513: flushing 0x68 bytes at 0x28220 > > ../kern/dl.c:513: flushing 0x410 bytes at 0x282c0 > > ../kern/dl.c:570: module name: amiga > > ../kern/dl.c:571: init function: 0x282c0 > > ../kern/dl.c:527: module at 0x3ed84, size 0xe28 > > ../kern/dl.c:556: relocating to 0x280a0 > > ../kern/dl.c:513: flushing 0x4 bytes at 0x27a30 > > ../kern/dl.c:513: flushing 0x14 bytes at 0x27a70 > > ../kern/dl.c:513: flushing 0xfc bytes at 0x27ac0 > > ../kern/dl.c:513: flushing 0x458 bytes at 0x27bf0 > > ../kern/dl.c:570: module name: apple > > ../kern/dl.c:571: init function: 0x27bf0 > > ../kern/dl.c:527: module at 0x3fbb8, size 0xeca4 > > ../kern/dl.c:556: relocating to 0x27940 > > > > Notice how much larger that last module is than the ones before it. > > That's a bit suspicious... do you have any modules that size? > > > > I'd like to address this issue later but their size are really messed > up. Grub can find the modules (how you can see by the modules names) > though. The modules should have 7k at most but grub identified them has > having about 50k. That is really strange. I wonder if you have an ABI issue like sizeof(long)... how is the grub-mkimage tool compiled? Please make sure it's 32-bit. The grub binary that executes at boot should also 32-bit. > I'm also curious why we must have a GAP between _end and the modules. > Why do not put the modules right after the _end address. We put the modules into a separate PT_LOAD ELF segment, and these must be aligned. One other possibility is that your firmware doesn't like the way grub-mkimage throws out the section table on the ELF file. You could try changing that behavior. I suppose you could also try to extend the existing PT_LOAD segment instead of creating a new one, but architecturally creating a new segment for the modules is much nicer. > I need to look more into the source code but I noted the modules are > allocated in address in a decrementing order. The next module is always > loaded in a address below the previous module. I don't know if this > memory is allocated by the OF or if Grub forces the address to load the > modules this way. > How I have said before that I will look at this issue after the modules > header info location address issue is resolved. > > > > that address calculation led me to believe that I can tell where the > > > struct will be on memory based in its place in the binary. > > > > > > I also noted that basemod ( indicates where the modules sections begin) > > > used by grub_mkelfimage is the same calculated by grub (_end + GAP). but > > > it seems to not store it on the necessary address. > > > > > > using hexedit I could see that in the address 0xCC98 (in the file > > > generated by grub_mkelfimage) is stored the struct header info. > > > > Well, hmm. Given the readelf output below, file offset 0xcc98 should be > > loaded right at 0x2d000. Since you can see the magic number there > > (correct?), I can't explain why the ELF loaded places it at 0x38f4c. > > Yes, the magic number is exactly at the address 0xcc98 on the file > generated by the grub_mkelfimage. How can you tell the address it should > appear in memory based on its address in file? Maybe it's only valid in > some old OF version? Look at the segment list again: > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x0000b4 0x00010000 0x00010000 0x0cbe4 0x14098 RWE 0x10 > GNU_STACK 0x00cc98 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 > LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4 > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 Offset tells you where in the file each segment begins. FileSiz is how many bytes to read from the file. VirtAddr/PhysAddr is where in memory to copy it, and MemSiz is how many bytes the segment will occupy in memory. (If MemSiz > FileSiz, the trailing bytes are zero.) 0x38f4c, where you found the header, is about 50KB inside the second LOAD segment (which was added by grub-mkimage and contains the modules). Either the firmware's ELF loader did something bad loading the file, or grub-mkimage did something bad constructing the file. Since you said you can manually verify that file offset 0xcc98 does in fact contain the magic number, and we can all see that it *should* be loaded at 0x2d000, that makes it seem like the loader did something wrong. Can you report the bug to the firmware team, supply the broken binary, and see if they'll take a look at it? By the way, what filesystem is GRUB located on, and how big is the partition? Historically IBM firmware has had bugs loading from many filesystems, but I think FAT12 is OK as long as it's on a small partition. > > Can you report what memory firmware is using on this system? IIRC you > > can decode it from the "available" properties in the memory nodes. > > > I couldn't find any apparently useful information in the memory nodes > properties. I have attached it anyway, I have also attached the "/" node > properties. I didn't get these. You'll need to refer to the PowerPC and CHRP bindings to IEEE 1275 to interpret the /memory/available properties. I don't remember the field widths off the top of my head, but they are basically a list of pairs that denote regions of memory available to applications. I was just wondering if maybe firmware was occupying the memory specified in the ELF header for the modules segment, and was doing something stupid after that. -- Hollis Blanchard IBM Linux Technology Center From MAILER-DAEMON Tue Oct 21 18:05:06 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KsPLe-0005xc-Ho for mharc-grub-devel@gnu.org; Tue, 21 Oct 2008 18:05:06 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KsPLb-0005wR-SR for grub-devel@gnu.org; Tue, 21 Oct 2008 18:05:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KsPLa-0005vS-1g for grub-devel@gnu.org; Tue, 21 Oct 2008 18:05:03 -0400 Received: from [199.232.76.173] (port=40109 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsPLZ-0005vL-SQ for grub-devel@gnu.org; Tue, 21 Oct 2008 18:05:01 -0400 Received: from c60.cesmail.net ([216.154.195.49]:38648) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1KsPLZ-0003L9-1x for grub-devel@gnu.org; Tue, 21 Oct 2008 18:05:01 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 21 Oct 2008 18:04:58 -0400 Received: from [192.168.0.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id F40DE618FDE; Tue, 21 Oct 2008 18:04:58 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 , Hollis Blanchard In-Reply-To: <1224622323.31194.81.camel@localhost.localdomain> References: <1224622323.31194.81.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-kaRMnp+GgfxSmZ6DQAlQ" Date: Tue, 21 Oct 2008 18:04:57 -0400 Message-Id: <1224626697.3267.19.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: Manoel , Carlos Roberto do Nascimento Costa Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 22:05:04 -0000 --=-kaRMnp+GgfxSmZ6DQAlQ Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello! I just want to post some PowerPC related information in this thread without delving deep into this discussion. GRUB_MOD_GAP is needed to work around a bug on PowerMac G3 (Blue&White). Without the gap, images created by grub-mkimage would not load. OpenFirmware would report: "CLAIM failed". I believe grub-mkimage doesn't generate valid ELF files, but they are "good enough" for OpenFirmware. But only with the gap. I have never tried compiling GRUB on 64-bit PowerPC. However, I tried cross-compiling it on x86_64 for PowerPC and found a bug in grub-mkimage, which I fixed. Look for GRUB_TARGET_SIZEOF_LONG in ChangeLog. Once this bug is fixed, it should be safe to remove all references host_m32 from configure.ac. However, I left it in place because I didn't have a 64-bit PowerPC to test. util/ieee1275/grub-install.in is not suitable for PowerPC. It assumes that /boot is on the HFS boot partition. It's not the case for Fedora and perhaps any distro. The HFS boot partition is not mounted and should be accessed by hfstools. The modules should be installed under /boot/grub. The path to /boot/grub should be embedded into the core image. We have support for embedding the default module path now. We need a better script that would not put all modules on the short HFS boot partition. Considering that the SPARC port is defunct, I would just rewrite util/ieee1275/grub-install.in. I'm attaching two scripts I'm using to test PowerPC grub on x86_64. One is building the tools for the host architecture, the other builds them for PowerPC and uses qemu to run them. The paths should be adjusted, obviously. -- Regards, Pavel Roskin --=-kaRMnp+GgfxSmZ6DQAlQ Content-Disposition: attachment; filename=grub-ppc Content-Type: application/x-shellscript; name=grub-ppc Content-Transfer-Encoding: 7bit #!/bin/sh set -e CROSS_PATH=/home/proski/src/buildroot/build_powerpc/staging_dir/usr/bin PATH=$CROSS_PATH:$PATH ./configure --with-platform=ieee1275 --target=powerpc-linux make -j2 ./grub-mkrescue --grub-mkimage=./grub-mkelfimage --pkglibdir=. grub.iso qemu-system-ppc -nographic -cdrom grub.iso -boot d --=-kaRMnp+GgfxSmZ6DQAlQ Content-Disposition: attachment; filename=grub-ppc-native Content-Type: application/x-shellscript; name=grub-ppc-native Content-Transfer-Encoding: 7bit #!/bin/sh set -e CROSS_PATH=/home/proski/src/buildroot/build_powerpc/staging_dir/usr/bin CROSS_LIB=/home/proski/src/buildroot/project_build_powerpc/uclibc/root PATH=$CROSS_PATH:$PATH ./configure --with-platform=ieee1275 --build=`sh config.guess` \ --host=powerpc-linux make -j2 ./grub-mkrescue --pkglibdir=. \ --grub-mkimage="qemu-ppc -L $CROSS_LIB ./grub-mkimage" grub.iso qemu-system-ppc -nographic -cdrom grub.iso -boot d --=-kaRMnp+GgfxSmZ6DQAlQ-- From MAILER-DAEMON Tue Oct 21 18:09:15 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KsPPf-0007vM-02 for mharc-grub-devel@gnu.org; Tue, 21 Oct 2008 18:09:15 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KsPPd-0007uc-47 for grub-devel@gnu.org; Tue, 21 Oct 2008 18:09:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KsPPc-0007uQ-HM for grub-devel@gnu.org; Tue, 21 Oct 2008 18:09:12 -0400 Received: from [199.232.76.173] (port=52718 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsPPc-0007uM-Cq for grub-devel@gnu.org; Tue, 21 Oct 2008 18:09:12 -0400 Received: from c60.cesmail.net ([216.154.195.49]:21546) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1KsPPb-00069w-J3 for grub-devel@gnu.org; Tue, 21 Oct 2008 18:09:11 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 21 Oct 2008 18:09:08 -0400 Received: from [192.168.0.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id 9577A618FDE for ; Tue, 21 Oct 2008 18:09:08 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: <20081021183959.GA12487@pina.cat> References: <20080920203745.GA27562@pina.cat> <20080924103424.GK6973@thorin> <20080924160724.GA10087@pina.cat> <20080924163322.GA31610@thorin> <20080924165056.GA24548@pina.cat> <20081021183959.GA12487@pina.cat> Content-Type: text/plain Date: Tue, 21 Oct 2008 18:09:07 -0400 Message-Id: <1224626947.3267.21.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [PATCH] Menu control for NPAGE and PPAGE X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 22:09:13 -0000 On Tue, 2008-10-21 at 20:39 +0200, Carles Pina i Estany wrote: > Hello, > > On Sep/24/2008, Carles Pina i Estany wrote: > > > On Sep/24/2008, Robert Millan wrote: > > > On Wed, Sep 24, 2008 at 06:07:24PM +0200, Carles Pina i Estany wrote: > > > > > > > > New patch is attached. I also improved some other thing. > > > > > > > > Feedback is welcomed :-) > > > > > > There seems to be an off-by-one problem. Try with the attached grub.cfg. > > > > should be fine now, sorry. > > pinging... somebody has had time to check it? I can commit it if there are no objections and my testing finds no problems. -- Regards, Pavel Roskin From MAILER-DAEMON Tue Oct 21 18:40:22 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KsPtl-00085u-Sg for mharc-grub-devel@gnu.org; Tue, 21 Oct 2008 18:40:21 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KsPtk-00085i-M8 for grub-devel@gnu.org; Tue, 21 Oct 2008 18:40:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KsPth-000846-AI for grub-devel@gnu.org; Tue, 21 Oct 2008 18:40:20 -0400 Received: from [199.232.76.173] (port=53185 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsPth-000841-2Q for grub-devel@gnu.org; Tue, 21 Oct 2008 18:40:17 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:43728) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KsPtc-0000ga-Cv; Tue, 21 Oct 2008 18:40:12 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9LMeAIA001619; Tue, 21 Oct 2008 18:40:10 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9LMe9r0026884; Tue, 21 Oct 2008 16:40:09 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9LMe96B017964; Tue, 21 Oct 2008 16:40:09 -0600 Received: from [9.53.41.42] (slate.austin.ibm.com [9.53.41.42]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9LMe9K2017948; Tue, 21 Oct 2008 16:40:09 -0600 From: Hollis Blanchard To: Pavel Roskin In-Reply-To: <1224626697.3267.19.camel@dv> References: <1224622323.31194.81.camel@localhost.localdomain> <1224626697.3267.19.camel@dv> Content-Type: text/plain Organization: IBM Linux Technology Center Date: Tue, 21 Oct 2008 17:40:06 -0500 Message-Id: <1224628806.31194.99.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Cc: The development of GRUB 2 , Carlos Roberto do Nascimento Costa , Manoel Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 22:40:20 -0000 On Tue, 2008-10-21 at 18:04 -0400, Pavel Roskin wrote: > > util/ieee1275/grub-install.in is not suitable for PowerPC. It worked great for me. :) > It assumes that /boot is on the HFS boot partition. I documented the partitioning assumptions it uses: http://grub.enbug.org/TestingOnPowerPC > It's not the case for Fedora > and perhaps any distro. The HFS boot partition is not mounted and > should be accessed by hfstools. The modules should be installed > under /boot/grub. The path to /boot/grub should be embedded into the > core image. We have support for embedding the default module path now. > We need a better script that would not put all modules on the short HFS > boot partition. Considering that the SPARC port is defunct, I would > just rewrite util/ieee1275/grub-install.in. The "boot partition" is an unnecessary hack instituted by a particularly opinionated ybin developer, and a great inconvenience. It's ridiculous to have scripts to copy and convert yaboot.conf files into a "secret" partition, especially since the bootloader is perfectly capable of discovering files at run time (unlike lilo, where the ybin model came from). Also, have you looked at those scripts? On IBM POWER servers, there is no HFS partition at all. Instead, there is a "raw" partition onto which you dd an ELF file. Firmware loads the whole thing into memory and jumps at offset 0. Traditionally, yaboot is installed there, and when it runs it does a shoddy job of trying to walk the (DOS) partition table, searching for /etc/yaboot.conf. Once GRUB replaces yaboot/ybin we can happily wave both of these anachronisms goodbye. Firmware on both systems is fully capable of loading ELF files from a filesystem, and since it's on a filesystem there is no need to embed anything or search anywhere: all files (grub.cfg and the modules) should be placed adjacent to the executable. As for embedding the path in the executable itself, that's a nice idea until you copy the executable to another system or move your hard disk to another system where devices have different Open Firmware paths and aliases. Another big pain point is building bootable CDs, since these also unfortunately cannot make assumptions about the Open Firmware devices available. Just put all the files in the same directory on a real filesystem and be happy. I know I am. :) -- Hollis Blanchard IBM Linux Technology Center From MAILER-DAEMON Wed Oct 22 07:28:19 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Ksbsx-00083y-2l for mharc-grub-devel@gnu.org; Wed, 22 Oct 2008 07:28:19 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ksbsu-00083g-Ry for grub-devel@gnu.org; Wed, 22 Oct 2008 07:28:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ksbsr-00083T-UY for grub-devel@gnu.org; Wed, 22 Oct 2008 07:28:15 -0400 Received: from [199.232.76.173] (port=47651 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ksbsr-00083H-Ln for grub-devel@gnu.org; Wed, 22 Oct 2008 07:28:13 -0400 Received: from fg-out-1718.google.com ([72.14.220.152]:20291) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ksbsp-0007wL-7U for grub-devel@gnu.org; Wed, 22 Oct 2008 07:28:14 -0400 Received: by fg-out-1718.google.com with SMTP id l26so313927fgb.30 for ; Wed, 22 Oct 2008 04:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=azA02aihz43DCxddr6iX26LHStDg+ZmnR1T/KAomlsc=; b=pKB9t4JmPRkWctrurajBsVUoG6S4VSNaSvmCWjd8CCcruJdXaBQczrSVTGj8JnLjjD O86PRxhXgTtrtcmAsVW5wdRnlKkkm5QVB8BRVBlKnBb9c9fGZXiTVc2xfy3ehweDW1oU 4vN5yw9qE74tfagPrG1ei3DmCvMGA71h6aA0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=OkDq0lYK+n5a9d71VVUL1MVmFKii63mqafD5tTL0LoP2Iavr5fvkgqHJQW9BV6ObCK j6Aq2Ure35dDVwvudIUG3LLl2849zvDKN37sQLxgog3mg3jdD0i4CEWV3PSKydf7VeAE 7d9xPHWzaI1o7GU8pYUUZoI4qgsHIlNdzVmTk= Received: by 10.86.82.6 with SMTP id f6mr835029fgb.66.1224674885606; Wed, 22 Oct 2008 04:28:05 -0700 (PDT) Received: from posto1e113 (fw-priv.eseig.wan.ipp.pt [193.136.56.222]) by mx.google.com with ESMTPS id d6sm13887893fga.2.2008.10.22.04.28.03 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Oct 2008 04:28:04 -0700 (PDT) From: =?iso-8859-1?Q?Jos=E9_Campos?= To: Date: Wed, 22 Oct 2008 12:34:24 +0100 Message-ID: <002a01c9343a$241456b0$6c3d0410$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C93442.85D8BEB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack0OiHfAOROlkzdQIKrZZg2UPUMNA== Content-Language: pt X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: grub2 background_image difficulty X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2008 11:28:17 -0000 Esta é uma mensagem com várias partes no formato MIME. ------=_NextPart_000_002B_01C93442.85D8BEB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have both windows and linux(fedora core8) installed on. I have also installed grub2(v1.96, source compiled by me) as the boot loader. =20 I just can=92t load any image as background as you can see on grub.cfg bellow(perhaps some non necessary commands). Images are on partition(sda3) within images directory, the .mod files = and grub.cfg are as well on the sda3. ################################ set default=3D0 set timeout=3D5 insmod linux insmod terminal insmod boot insmod gfxterm insmod vbe insmod vga set gfxmode=3D640x480 insmod png set root=3D(hd0,3) if background_image /grub/images/ESEIG.png ; then set menu_color_normal=3Dwhite/black set menu_color_highlight=3Dwhite/green else set menu_color_normal=3Dred/black set menu_color_highlight=3Dred/green fi terminal gfxterm menuentry "GNU/Linux, linux 2.6.25-14.fc9.i686" { linux (hd0,3)/vmlinuz-2.6.25-14.fc9.i686 root=3D/dev/sda5 ro=20 initrd (hd0,3)/initrd-2.6.25-14.fc9.i686.img } menuentry "Windows XP Proffessional" { set root=3D(hd0,1) chainloader +1 } ################################ =20 Appreciate any help =20 Jose Campos =20 =20 ------=_NextPart_000_002B_01C93442.85D8BEB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have both windows and linux(fedora core8) = installed on.


I have also installed grub2(v1.96, source = compiled by me) as the boot loader.
        =

I just can’t load any image as background as you can = see on grub.cfg bellow(perhaps some non necessary = commands).

Images are on partition(sda3) within images directory, = =A0the .mod files and grub.cfg are as well on the sda3.

################################

set default=3D0
set timeout=3D5

insmod linux
insmod terminal
insmod boot

insmod gfxterm
insmod vbe
insmod vga
set gfxmode=3D640x480
insmod png

set root=3D(hd0,3)
if background_image = /grub/images/ESEIG.png ; then
   set = menu_color_normal=3Dwhite/black
   set = menu_color_highlight=3Dwhite/green
else
   set = menu_color_normal=3Dred/black
   set = menu_color_highlight=3Dred/green
fi

terminal gfxterm

menuentry "GNU/Linux, linux 2.6.25-14.fc9.i686" {
   linux (hd0,3)/vmlinuz-2.6.25-14.fc9.i686 root=3D/dev/sda5 ro 
   initrd (hd0,3)/initrd-2.6.25-14.fc9.i686.img
}
menuentry "Windows XP = Proffessional" {
   set = root=3D(hd0,1)
   chainloader +1
}

################################

 

Appreciate any help

 

Jose Campos

 

 

------=_NextPart_000_002B_01C93442.85D8BEB0-- From MAILER-DAEMON Wed Oct 22 07:31:30 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Ksbw1-0000zr-Ra for mharc-grub-devel@gnu.org; Wed, 22 Oct 2008 07:31:29 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ksbw0-0000zI-0I for grub-devel@gnu.org; Wed, 22 Oct 2008 07:31:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ksbvy-0000y3-FB for grub-devel@gnu.org; Wed, 22 Oct 2008 07:31:27 -0400 Received: from [199.232.76.173] (port=47768 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ksbvy-0000xx-7b for grub-devel@gnu.org; Wed, 22 Oct 2008 07:31:26 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:62353) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ksbvy-0000mm-8x for grub-devel@gnu.org; Wed, 22 Oct 2008 07:31:26 -0400 Received: from [85.180.53.167] (e180053167.adsl.alicedsl.de [85.180.53.167]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1Ksbvw1f3Z-0006vt; Wed, 22 Oct 2008 13:31:24 +0200 From: Felix Zielcke To: The development of GRUB 2 In-Reply-To: <002a01c9343a$241456b0$6c3d0410$@com> References: <002a01c9343a$241456b0$6c3d0410$@com> Content-Type: text/plain; charset=utf-8 Date: Wed, 22 Oct 2008 13:31:22 +0200 Message-Id: <1224675082.4106.0.camel@fz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V01U2FsdGVkX1/gTa4upsD158xfL/rGqrEO1aLizoZibBfvLZM jWcnb5CxtoxmlALC0HgO6qWG8CAxXW4BAOq8UBl1OBm9IfFREd QvruJjF4UvZcnBPzZOffbZry3MBMCPc X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: grub2 background_image difficulty X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2008 11:31:28 -0000 Am Mittwoch, den 22.10.2008, 12:34 +0100 schrieb Jos=C3=A9 Campos: > I have both windows and linux(fedora core8) installed on. >=20 >=20 > I have also installed grub2(v1.96, source compiled by me) as the boot > loader. Hello, Don't use the 1.96 release from february but trunk SVN version. There were many bugfixes since then and I think even in the png module something was fixed in the last months. --=20 Felix Zielcke From MAILER-DAEMON Wed Oct 22 07:36:03 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Ksc0R-0003hk-46 for mharc-grub-devel@gnu.org; Wed, 22 Oct 2008 07:36:03 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ksc0P-0003gi-PE for grub-devel@gnu.org; Wed, 22 Oct 2008 07:36:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ksc0O-0003eP-5p for grub-devel@gnu.org; Wed, 22 Oct 2008 07:36:01 -0400 Received: from [199.232.76.173] (port=40536 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ksc0O-0003eK-34 for grub-devel@gnu.org; Wed, 22 Oct 2008 07:36:00 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:58933) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ksc0N-0002UZ-Pm for grub-devel@gnu.org; Wed, 22 Oct 2008 07:36:00 -0400 Received: from [85.180.53.167] (e180053167.adsl.alicedsl.de [85.180.53.167]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1Ksc0L2jvF-0007B7; Wed, 22 Oct 2008 13:35:58 +0200 From: Felix Zielcke To: The development of GRUB 2 In-Reply-To: <002a01c9343a$241456b0$6c3d0410$@com> References: <002a01c9343a$241456b0$6c3d0410$@com> Content-Type: text/plain; charset=utf-8 Date: Wed, 22 Oct 2008 13:35:56 +0200 Message-Id: <1224675356.4106.4.camel@fz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V01U2FsdGVkX1/m/77F6O7qlwOqu717YKplL1UHLVXsprE8dg7 FqDn9V4DB0MeBiyfqKQD/fYTbgdehADxFSblRZQxgLW737IeKh KU6fQpa6L0GS8E730f/p+qy6YFDoFIg X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: grub2 background_image difficulty X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2008 11:36:02 -0000 Am Mittwoch, den 22.10.2008, 12:34 +0100 schrieb Jos=C3=A9 Campos: > set root=3D(hd0,3) > if background_image /grub/images/ESEIG.png ; then > set menu_color_normal=3Dwhite/black > set menu_color_highlight=3Dwhite/green > else > set menu_color_normal=3Dred/black > set menu_color_highlight=3Dred/green > fi >=20 > terminal gfxterm Oh and I think the problem is that you set `terminal gfxterm' after the image is loaded and not before. The update-grub script (or grub-mkconfig now in trunk SVN) normally generates it that way. For example here a snippet from my debian config: ### BEGIN /etc/grub.d/00_header ### set default=3D0 set timeout=3D5 set root=3D(hd0,2) search --fs-uuid --set 1867fa8e-a3f0-422d-912e-7d07556d633c if font /usr/share/grub/ascii.pff ; then set gfxmode=3D640x480 insmod gfxterm insmod vbe terminal gfxterm fi ### END /etc/grub.d/00_header ### ### BEGIN /etc/grub.d/05_debian_theme ### set root=3D(hd0,2) search --fs-uuid --set 1867fa8e-a3f0-422d-912e-7d07556d633c insmod png if background_image /boot/grub/debian-blueish-wallpaper-640x480.png ; then set color_normal=3Dblack/black set color_highlight=3Dmagenta/black else set menu_color_normal=3Dcyan/blue set menu_color_highlight=3Dwhite/blue fi ### END /etc/grub.d/05_debian_theme ### From MAILER-DAEMON Thu Oct 23 01:26:23 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KssiF-0007XZ-8d for mharc-grub-devel@gnu.org; Thu, 23 Oct 2008 01:26:23 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KssiD-0007WY-R2 for grub-devel@gnu.org; Thu, 23 Oct 2008 01:26:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KssiC-0007V8-19 for grub-devel@gnu.org; Thu, 23 Oct 2008 01:26:21 -0400 Received: from [199.232.76.173] (port=36025 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KssiB-0007Uz-Pl for grub-devel@gnu.org; Thu, 23 Oct 2008 01:26:19 -0400 Received: from c60.cesmail.net ([216.154.195.49]:46750) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1KssiB-0000Jx-Cp for grub-devel@gnu.org; Thu, 23 Oct 2008 01:26:19 -0400 Received: from unknown (HELO delta2) ([192.168.1.50]) by c60.cesmail.net with ESMTP; 23 Oct 2008 01:26:01 -0400 Received: from pool-96-227-17-203.phlapa.east.verizon.net (pool-96-227-17-203.phlapa.east.verizon.net [96.227.17.203]) by webmail.spamcop.net (Horde MIME library) with HTTP; Thu, 23 Oct 2008 01:25:58 -0400 Message-ID: <20081023012558.mlk1yefps0ws4k4c-cebfxv@webmail.spamcop.net> Date: Thu, 23 Oct 2008 01:25:58 -0400 From: Pavel Roskin To: The development of GRUB 2 , Hollis Blanchard References: <1224622323.31194.81.camel@localhost.localdomain> <1224626697.3267.19.camel@dv> <1224628806.31194.99.camel@localhost.localdomain> In-Reply-To: <1224628806.31194.99.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: Manoel , Carlos Roberto do Nascimento Costa Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 05:26:22 -0000 Quoting Hollis Blanchard : > On Tue, 2008-10-21 at 18:04 -0400, Pavel Roskin wrote: >> >> util/ieee1275/grub-install.in is not suitable for PowerPC. > > It worked great for me. :) OK, I should have said that it's not suitable as a drop-in replacement =20 for yaboot on PowerMACs. >> It assumes that /boot is on the HFS boot partition. > > I documented the partitioning assumptions it uses: > http://grub.enbug.org/TestingOnPowerPC Actually, that page doesn't mention grub-install at all. It suggests =20 merging all modules with the core and installing it on the boot =20 partition. >> It's not the case for Fedora >> and perhaps any distro. The HFS boot partition is not mounted and >> should be accessed by hfstools. The modules should be installed >> under /boot/grub. The path to /boot/grub should be embedded into the >> core image. We have support for embedding the default module path now. >> We need a better script that would not put all modules on the short HFS >> boot partition. Considering that the SPARC port is defunct, I would >> just rewrite util/ieee1275/grub-install.in. > > The "boot partition" is an unnecessary hack instituted by a particularly > opinionated ybin developer, and a great inconvenience. It's ridiculous > to have scripts to copy and convert yaboot.conf files into a "secret" > partition, especially since the bootloader is perfectly capable of > discovering files at run time (unlike lilo, where the ybin model came > from). Also, have you looked at those scripts? I don't quite understand what you mean here. I don't care where =20 yaboot looks for its configuration files. I mean that GRUB should not =20 rely on the kernel support for HFS and that the HFS boot partition =20 should be used sparingly (it's a separate question whether yaboot does =20 the best effort, but yaboot is small). > On IBM POWER servers, there is no HFS partition at all. Instead, there > is a "raw" partition onto which you dd an ELF file. Firmware loads the > whole thing into memory and jumps at offset 0. Traditionally, yaboot is > installed there, and when it runs it does a shoddy job of trying to walk > the (DOS) partition table, searching for /etc/yaboot.conf. > > Once GRUB replaces yaboot/ybin we can happily wave both of these > anachronisms goodbye. Firmware on both systems is fully capable of > loading ELF files from a filesystem, and since it's on a filesystem > there is no need to embed anything or search anywhere: all files > (grub.cfg and the modules) should be placed adjacent to the executable. Actually, I would prefer all files that don't have to be on HFS or on =20 the raw partition to be on the native partition, so that they can be =20 easily accessed. That includes grub.cfg. > As for embedding the path in the executable itself, that's a nice idea > until you copy the executable to another system or move your hard disk > to another system where devices have different Open Firmware paths and > aliases. Another big pain point is building bootable CDs, since these > also unfortunately cannot make assumptions about the Open Firmware > devices available. We can use UUIDs now. That should alleviate most issues. > Just put all the files in the same directory on a real filesystem and be > happy. I know I am. :) I'm afraid I'm missing something. Anyway, I think it's too much to ask from users to change the existing =20 partitioning or mount points. GRUB can be more compatible with both =20 its i386 implementation and with yaboot by keeping modules in =20 /boot/grub on ext2 or another native filesystem and placing the =20 minimal core to the machine specific boot partition (whether it's HFS =20 or raw or something else). The goal of my previous message was to list the issues I ran into. =20 Inability to use grub-install as is was one of them, and it has not =20 been addressed. --=20 Regards, Pavel Roskin From MAILER-DAEMON Thu Oct 23 11:11:05 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kt1q5-0008RW-2n for mharc-grub-devel@gnu.org; Thu, 23 Oct 2008 11:11:05 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kt1q2-0008PJ-9k for grub-devel@gnu.org; Thu, 23 Oct 2008 11:11:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kt1pz-0008NF-FN for grub-devel@gnu.org; Thu, 23 Oct 2008 11:11:01 -0400 Received: from [199.232.76.173] (port=38110 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kt1pz-0008Mx-6O for grub-devel@gnu.org; Thu, 23 Oct 2008 11:10:59 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]:49659) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kt1pq-0001nR-MT; Thu, 23 Oct 2008 11:10:51 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9NF8JIV027318; Thu, 23 Oct 2008 11:08:19 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9NF6tGm141818; Thu, 23 Oct 2008 09:06:59 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9NF6rXf019120; Thu, 23 Oct 2008 09:06:53 -0600 Received: from [9.53.41.42] (slate.austin.ibm.com [9.53.41.42]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9NF6pho018723; Thu, 23 Oct 2008 09:06:52 -0600 From: Hollis Blanchard To: Pavel Roskin In-Reply-To: <20081023012558.mlk1yefps0ws4k4c-cebfxv@webmail.spamcop.net> References: <1224622323.31194.81.camel@localhost.localdomain> <1224626697.3267.19.camel@dv> <1224628806.31194.99.camel@localhost.localdomain> <20081023012558.mlk1yefps0ws4k4c-cebfxv@webmail.spamcop.net> Content-Type: text/plain Organization: IBM Linux Technology Center Date: Thu, 23 Oct 2008 10:06:49 -0500 Message-Id: <1224774409.16720.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Cc: The development of GRUB 2 , Carlos Roberto do Nascimento Costa , Manoel Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 15:11:02 -0000 On Thu, 2008-10-23 at 01:25 -0400, Pavel Roskin wrote: > Quoting Hollis Blanchard : > > On IBM POWER servers, there is no HFS partition at all. Instead, there > > is a "raw" partition onto which you dd an ELF file. Firmware loads the > > whole thing into memory and jumps at offset 0. Traditionally, yaboot is > > installed there, and when it runs it does a shoddy job of trying to walk > > the (DOS) partition table, searching for /etc/yaboot.conf. > > > > Once GRUB replaces yaboot/ybin we can happily wave both of these > > anachronisms goodbye. Firmware on both systems is fully capable of > > loading ELF files from a filesystem, and since it's on a filesystem > > there is no need to embed anything or search anywhere: all files > > (grub.cfg and the modules) should be placed adjacent to the executable. > > Actually, I would prefer all files that don't have to be on HFS or on > the raw partition to be on the native partition, so that they can be > easily accessed. That includes grub.cfg. FWIW, I ran for years with an HFS partition "natively" mounted on /boot/grub, and I never experienced any instability. Do you have reason (other than hearsay) to mistrust the Linux HFS driver? > > As for embedding the path in the executable itself, that's a nice idea > > until you copy the executable to another system or move your hard disk > > to another system where devices have different Open Firmware paths and > > aliases. Another big pain point is building bootable CDs, since these > > also unfortunately cannot make assumptions about the Open Firmware > > devices available. > > We can use UUIDs now. That should alleviate most issues. Agreed. > > Just put all the files in the same directory on a real filesystem and be > > happy. I know I am. :) > > I'm afraid I'm missing something. > > Anyway, I think it's too much to ask from users to change the existing > partitioning or mount points. GRUB can be more compatible with both > its i386 implementation and with yaboot by keeping modules in > /boot/grub on ext2 or another native filesystem and placing the > minimal core to the machine specific boot partition (whether it's HFS > or raw or something else). Actually I don't remember if I had to change the partitioning scheme at all: isn't GRUB + modules small enough to fit into the typical "ybin boot partition"? I don't think asking the user to add an entry to /etc/fstab is an onerous restriction. After all, they are trying to replace their distribution's bootloader in the first place, so they almost certainly have some familiarity with the boot process. Once distributions use GRUB2 of course, no user intervention would be required. My basic point is that requiring grub-install and this mystical "hidden partition in the mist" is just silly. It's completely unnecessary on systems with filesystem support in firmware, and it's silly to artificially limit those systems by imposing historical x86 restrictions onto them. -- Hollis Blanchard IBM Linux Technology Center From MAILER-DAEMON Thu Oct 23 12:52:22 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kt3Q6-0003MX-D4 for mharc-grub-devel@gnu.org; Thu, 23 Oct 2008 12:52:22 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kt3Q4-0003Lh-Pp for grub-devel@gnu.org; Thu, 23 Oct 2008 12:52:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kt3Q2-0003K7-SN for grub-devel@gnu.org; Thu, 23 Oct 2008 12:52:20 -0400 Received: from [199.232.76.173] (port=35253 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kt3Q2-0003Jy-DD for grub-devel@gnu.org; Thu, 23 Oct 2008 12:52:18 -0400 Received: from c60.cesmail.net ([216.154.195.49]:41982) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1Kt3Q2-0000fS-1v for grub-devel@gnu.org; Thu, 23 Oct 2008 12:52:18 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 23 Oct 2008 12:52:13 -0400 Received: from [192.168.0.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id 7B7D7618FDE; Thu, 23 Oct 2008 12:52:13 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 , Hollis Blanchard In-Reply-To: <1224774409.16720.22.camel@localhost.localdomain> References: <1224622323.31194.81.camel@localhost.localdomain> <1224626697.3267.19.camel@dv> <1224628806.31194.99.camel@localhost.localdomain> <20081023012558.mlk1yefps0ws4k4c-cebfxv@webmail.spamcop.net> <1224774409.16720.22.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 23 Oct 2008 12:52:11 -0400 Message-Id: <1224780731.17766.23.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: Manoel , Carlos Roberto do Nascimento Costa Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 16:52:21 -0000 On Thu, 2008-10-23 at 10:06 -0500, Hollis Blanchard wrote: > On Thu, 2008-10-23 at 01:25 -0400, Pavel Roskin wrote: > > Actually, I would prefer all files that don't have to be on HFS or on > > the raw partition to be on the native partition, so that they can be > > easily accessed. That includes grub.cfg. > > FWIW, I ran for years with an HFS partition "natively" mounted > on /boot/grub, and I never experienced any instability. Do you have > reason (other than hearsay) to mistrust the Linux HFS driver? HFS support is marked experimental in Linux 2.6.27, unlike HFSPLUS. I'm not sure about the quality of fsck.hfs. However, it's not that I distrust any drivers or utilities. The HFS driver may be missing from the kernel. It doesn't even have to be a Linux kernel. > > Anyway, I think it's too much to ask from users to change the existing > > partitioning or mount points. GRUB can be more compatible with both > > its i386 implementation and with yaboot by keeping modules in > > /boot/grub on ext2 or another native filesystem and placing the > > minimal core to the machine specific boot partition (whether it's HFS > > or raw or something else). > > Actually I don't remember if I had to change the partitioning scheme at > all: isn't GRUB + modules small enough to fit into the typical "ybin > boot partition"? It would fit. But it's better to keep modules and grub.cfg on a filesystem that is easier to access. > I don't think asking the user to add an entry to /etc/fstab is an > onerous restriction. After all, they are trying to replace their > distribution's bootloader in the first place, so they almost certainly > have some familiarity with the boot process. Once distributions use > GRUB2 of course, no user intervention would be required. > > My basic point is that requiring grub-install and this mystical "hidden > partition in the mist" is just silly. It's completely unnecessary on > systems with filesystem support in firmware, and it's silly to > artificially limit those systems by imposing historical x86 restrictions > onto them. I can imagine that there are some real issues why the HFS boot partition is not mounted. HFS may lack some security mechanisms that other filesystems have. It may not have a good fsck. Anyway, whatever the reasons, I don't think switching from yaboot to GRUB would change those reasons. For GRUB to be a compelling replacement, it would be beneficial if it could fit the existing systems. -- Regards, Pavel Roskin From MAILER-DAEMON Thu Oct 23 14:02:03 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kt4VX-00082b-6l for mharc-grub-devel@gnu.org; Thu, 23 Oct 2008 14:02:03 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kt4VV-00081x-Ut for grub-devel@gnu.org; Thu, 23 Oct 2008 14:02:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kt4VT-00081Z-Jk for grub-devel@gnu.org; Thu, 23 Oct 2008 14:02:01 -0400 Received: from [199.232.76.173] (port=56480 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kt4VT-00081W-Gg for grub-devel@gnu.org; Thu, 23 Oct 2008 14:01:59 -0400 Received: from igw2.br.ibm.com ([32.104.18.25]:50987) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kt4VS-0002ou-Iq for grub-devel@gnu.org; Thu, 23 Oct 2008 14:01:59 -0400 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw2.br.ibm.com (Postfix) with ESMTP id DBB3D17F489 for ; Thu, 23 Oct 2008 15:58:59 -0200 (BRDT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9NHxfx11380404 for ; Thu, 23 Oct 2008 14:59:41 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9NHxuKw022741 for ; Thu, 23 Oct 2008 15:59:57 -0200 Received: from [9.18.200.7] ([9.18.200.7]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9NHxtoQ022687; Thu, 23 Oct 2008 15:59:56 -0200 From: Manoel To: The development of GRUB 2 In-Reply-To: <1224622323.31194.81.camel@localhost.localdomain> References: <1224622323.31194.81.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 23 Oct 2008 16:00:02 -0200 Message-Id: <1224784802.9254.56.camel@manoel-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Cc: Carlos Roberto do Nascimento Costa , Hollis Blanchard Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 18:02:02 -0000 On Tue, 2008-10-21 at 15:52 -0500, Hollis Blanchard wrote: > Please CC me, since I'm no longer subscribed to grub-devel. > > > From: Manoel > > To: The development of GRUB 2 > > Subject: Re: PPC64 > > Date: Tue, 21 Oct 2008 14:43:25 -0200 > > > > Hi Hollis, > > > > On Mon, 2008-10-20 at 14:32 -0500, Hollis Blanchard wrote: > > > On Mon, 2008-10-20 at 17:18 -0200, Manoel wrote: > > > > > > > > I'm working in a project to use grub2 to boot some ppc machines(p6 , p5 > > > > and so on) and we had some difficulties with a grub modules problem. > > > > Grub fails to load modules. > > > > > > > > When debugging I noted that grub try to find the headerinfo modules > > > > struc (which is identified by the magic number 0x676d696d) in the > > > > address 0x2d000 (_end + gap aligned in 4k blocks). > > > > but this address does not contains the headerinfo. > > > > > > > > So i altered the source code such as the memory is searched to find the > > > > magic number. It is then found at address 0x38f4c and then grub find > > > > some modules (but fails after) has showed in attachment grub2.txt. > > > > > > ... > > > ../kern/dl.c:527: module at 0x3e0dc, size 0xc9c > > > ../kern/dl.c:556: relocating to 0x28720 > > > ../kern/dl.c:513: flushing 0x4 bytes at 0x28190 > > > ../kern/dl.c:513: flushing 0x14 bytes at 0x281d0 > > > ../kern/dl.c:513: flushing 0x68 bytes at 0x28220 > > > ../kern/dl.c:513: flushing 0x410 bytes at 0x282c0 > > > ../kern/dl.c:570: module name: amiga > > > ../kern/dl.c:571: init function: 0x282c0 > > > ../kern/dl.c:527: module at 0x3ed84, size 0xe28 > > > ../kern/dl.c:556: relocating to 0x280a0 > > > ../kern/dl.c:513: flushing 0x4 bytes at 0x27a30 > > > ../kern/dl.c:513: flushing 0x14 bytes at 0x27a70 > > > ../kern/dl.c:513: flushing 0xfc bytes at 0x27ac0 > > > ../kern/dl.c:513: flushing 0x458 bytes at 0x27bf0 > > > ../kern/dl.c:570: module name: apple > > > ../kern/dl.c:571: init function: 0x27bf0 > > > ../kern/dl.c:527: module at 0x3fbb8, size 0xeca4 > > > ../kern/dl.c:556: relocating to 0x27940 > > > > > > Notice how much larger that last module is than the ones before it. > > > That's a bit suspicious... do you have any modules that size? > > > > > > > I'd like to address this issue later but their size are really messed > > up. Grub can find the modules (how you can see by the modules names) > > though. The modules should have 7k at most but grub identified them has > > having about 50k. > > That is really strange. I wonder if you have an ABI issue like > sizeof(long)... how is the grub-mkimage tool compiled? Please make sure > it's 32-bit. The grub binary that executes at boot should also 32-bit. They are all 32-bit. I'll look deeper in this issue later. > > > I'm also curious why we must have a GAP between _end and the modules. > > Why do not put the modules right after the _end address. > > We put the modules into a separate PT_LOAD ELF segment, and these must > be aligned. > > One other possibility is that your firmware doesn't like the way > grub-mkimage throws out the section table on the ELF file. You could try > changing that behavior. > > I suppose you could also try to extend the existing PT_LOAD segment > instead of creating a new one, but architecturally creating a new > segment for the modules is much nicer. > I talked with some folks at #pppc64 on freenode an they suggest that the OF is loading things in the wrong place could a problem with my load-base: real-base c00000 c00000 virt-base ffffffff ffffffff real-size 1000000 1000000 virt-size ffffffff ffffffff load-base 4000 4000 they suggested to change load-base from 4000 to 200000 but I hava yet to try it. They also said that the note section can override load-base (and maybe we have some problem there?) I'm now reading PARP documentation to learn more about OF behavior. I thought these machine were CHRP but they are actually PARP (is that right?). Son only today I was able to get the correct documentation. > > I need to look more into the source code but I noted the modules are > > allocated in address in a decrementing order. The next module is always > > loaded in a address below the previous module. I don't know if this > > memory is allocated by the OF or if Grub forces the address to load the > > modules this way. > > How I have said before that I will look at this issue after the modules > > header info location address issue is resolved. > > > > > > that address calculation led me to believe that I can tell where the > > > > struct will be on memory based in its place in the binary. > > > > > > > > I also noted that basemod ( indicates where the modules sections begin) > > > > used by grub_mkelfimage is the same calculated by grub (_end + GAP). but > > > > it seems to not store it on the necessary address. > > > > > > > > using hexedit I could see that in the address 0xCC98 (in the file > > > > generated by grub_mkelfimage) is stored the struct header info. > > > > > > Well, hmm. Given the readelf output below, file offset 0xcc98 should be > > > loaded right at 0x2d000. Since you can see the magic number there > > > (correct?), I can't explain why the ELF loaded places it at 0x38f4c. > > > > Yes, the magic number is exactly at the address 0xcc98 on the file > > generated by the grub_mkelfimage. How can you tell the address it should > > appear in memory based on its address in file? Maybe it's only valid in > > some old OF version? > > Look at the segment list again: > > Program Headers: > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > LOAD 0x0000b4 0x00010000 0x00010000 0x0cbe4 0x14098 RWE 0x10 > > GNU_STACK 0x00cc98 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 > > LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4 > > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 this line look somehow wrong. NOTE will be loaded at the address 0? and will occupy no memory? that is the same as don't having NOTE at all right? > Offset tells you where in the file each segment begins. FileSiz is how > many bytes to read from the file. VirtAddr/PhysAddr is where in memory > to copy it, and MemSiz is how many bytes the segment will occupy in > memory. (If MemSiz > FileSiz, the trailing bytes are zero.) > > 0x38f4c, where you found the header, is about 50KB inside the second > LOAD segment (which was added by grub-mkimage and contains the modules). > Either the firmware's ELF loader did something bad loading the file, or > grub-mkimage did something bad constructing the file. > > Since you said you can manually verify that file offset 0xcc98 does in > fact contain the magic number, and we can all see that it *should* be > loaded at 0x2d000, that makes it seem like the loader did something > wrong. > > Can you report the bug to the firmware team, supply the broken binary, > and see if they'll take a look at it? > I'll do that. > By the way, what filesystem is GRUB located on, and how big is the > partition? Historically IBM firmware has had bugs loading from many > filesystems, but I think FAT12 is OK as long as it's on a small > partition. > We are doing boot through network so we can test easier, and so far we are only concerned about the initial parts (to find and load modules). > > > Can you report what memory firmware is using on this system? IIRC you > > > can decode it from the "available" properties in the memory nodes. > > > > > I couldn't find any apparently useful information in the memory nodes > > properties. I have attached it anyway, I have also attached the "/" node > > properties. > > I didn't get these. > I got documentation about the CHRP binding and it tells about a memory-controller node, but it doesn't exist (maybe cause it is actually PARP). I'll try to find something about it in PARP documentation. > You'll need to refer to the PowerPC and CHRP bindings to IEEE 1275 to > interpret the /memory/available properties. I don't remember the field > widths off the top of my head, but they are basically a list of length> pairs that denote regions of memory available to applications. > > I was just wondering if maybe firmware was occupying the memory > specified in the ELF header for the modules segment, and was doing > something stupid after that. > look likes it, maybe it cant load the section where it should then it loads it elsewhere, but even so, grub should be able to load all modules once I find where it starts. Grub is able to successfully load some modules (first 6) and then crashes when getting the module name of the 7th one. Forcing grub to stop in the 6th module they appear listed in the lsmod command (but I can't tell about it's functionality). Looking better at the booting the size problem only occurs in the last module (which crashes grub). So either mkelfimage is doing something wrong or OF is corrupting the address where its size is stored. I'll look more into int after the header address issue is done. -- Best Regards, Manoel Abranches IBM Linux Technology Center Brasil From MAILER-DAEMON Thu Oct 23 15:09:08 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kt5YS-0006ze-Bm for mharc-grub-devel@gnu.org; Thu, 23 Oct 2008 15:09:08 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kt5YQ-0006zZ-8s for grub-devel@gnu.org; Thu, 23 Oct 2008 15:09:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kt5YN-0006yF-N5 for grub-devel@gnu.org; Thu, 23 Oct 2008 15:09:04 -0400 Received: from [199.232.76.173] (port=39443 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kt5YN-0006y6-JP for grub-devel@gnu.org; Thu, 23 Oct 2008 15:09:03 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:51846) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kt5YN-0007gd-JM for grub-devel@gnu.org; Thu, 23 Oct 2008 15:09:03 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id m9NJ5hm2028875 for ; Thu, 23 Oct 2008 15:05:43 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9NJ8wBJ135780 for ; Thu, 23 Oct 2008 15:08:58 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9NJ8vxe010911 for ; Thu, 23 Oct 2008 15:08:57 -0400 Received: from [9.53.41.42] (slate.austin.ibm.com [9.53.41.42]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9NJ8vQJ010881; Thu, 23 Oct 2008 15:08:57 -0400 From: Hollis Blanchard To: Manoel In-Reply-To: <1224784802.9254.56.camel@manoel-laptop> References: <1224622323.31194.81.camel@localhost.localdomain> <1224784802.9254.56.camel@manoel-laptop> Content-Type: text/plain Organization: IBM Linux Technology Center Date: Thu, 23 Oct 2008 14:08:55 -0500 Message-Id: <1224788935.16720.38.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Cc: The development of GRUB 2 , Carlos Roberto do Nascimento Costa Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 19:09:06 -0000 On Thu, 2008-10-23 at 16:00 -0200, Manoel wrote: > > I talked with some folks at #pppc64 on freenode an they suggest that > the > OF is loading things in the wrong place could a problem with my > load-base: > > real-base c00000 c00000 > virt-base ffffffff ffffffff > real-size 1000000 1000000 > virt-size ffffffff ffffffff > load-base 4000 4000 > > they suggested to change load-base from 4000 to 200000 but I hava yet > to try it. They also said that the note section can override > load-base (and maybe we have some problem there?) It's possible. See below. > I'm now reading PARP documentation to learn more about OF behavior. I > thought these machine were CHRP but they are actually PARP (is that > right?). Son only today I was able to get the correct documentation. PAPR was based on the older CHRP specification. > > Look at the segment list again: > > > Program Headers: > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > LOAD 0x0000b4 0x00010000 0x00010000 0x0cbe4 0x14098 RWE 0x10 > > > GNU_STACK 0x00cc98 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 > > > LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4 > > > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 > > > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 > this line look somehow wrong. NOTE will be loaded at the address 0? > and will occupy no memory? that is the same as don't having NOTE at > all right? NOTE is interpreted by the loader (firmware), but not actually loaded into memory. This is a binary structure that can be used to set some of the environment variables you mention above. The NOTE segment (segment, not section) is created by util/elf/grub-mkimage.c . You can see that load-base is set to 0x4000 in that code. Since your text starts at 0x10000, that means your binary can be at most 0xc000 bytes (48KB) large before it overlaps the text area. That isn't necessarily a problem; firmware is probably using memmove() (which handles overlapping areas) to load the segments into place. It's probably worth trying a different load-base to see if that could be the problem here. -- Hollis Blanchard IBM Linux Technology Center From MAILER-DAEMON Fri Oct 24 08:10:22 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtLUk-0003PF-KD for mharc-grub-devel@gnu.org; Fri, 24 Oct 2008 08:10:22 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtLUi-0003Oh-W8 for grub-devel@gnu.org; Fri, 24 Oct 2008 08:10:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtLUi-0003OC-2D for grub-devel@gnu.org; Fri, 24 Oct 2008 08:10:20 -0400 Received: from [199.232.76.173] (port=55968 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtLUh-0003O6-Tq for grub-devel@gnu.org; Fri, 24 Oct 2008 08:10:19 -0400 Received: from igw2.br.ibm.com ([32.104.18.25]:57968) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KtLUh-0002OT-Dj for grub-devel@gnu.org; Fri, 24 Oct 2008 08:10:19 -0400 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw2.br.ibm.com (Postfix) with ESMTP id C817117F5CA for ; Fri, 24 Oct 2008 10:09:16 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9OC9wnT1220846 for ; Fri, 24 Oct 2008 09:09:58 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9OCACYH004047 for ; Fri, 24 Oct 2008 10:10:13 -0200 Received: from [9.18.200.108] ([9.18.200.108]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9OCA7G8003872; Fri, 24 Oct 2008 10:10:08 -0200 From: Manoel To: Hollis Blanchard In-Reply-To: <1224788935.16720.38.camel@localhost.localdomain> References: <1224622323.31194.81.camel@localhost.localdomain> <1224784802.9254.56.camel@manoel-laptop> <1224788935.16720.38.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 24 Oct 2008 10:10:15 -0200 Message-Id: <1224850215.7358.12.camel@manoel-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Cc: The development of GRUB 2 , Carlos Roberto do Nascimento Costa Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 12:10:21 -0000 I changed the load-base to 0x200000 in the note segment that mkelfimage creates. After that grub2 found the modules info header in the correct position (as stated in the program header) and was able to load all modules correctly. Maybe the Open Firmware detected the overlapping and tried to load the segment in another place, and for some reason the data write was corrupted. Sounds like a OF's bug and I'll report it as you suggested. To me the correct behavior would be load things in place and correctly even with overlapping memory. And about the note section, what is the point in create it with hardcoded variables? I don't see a reason to have this note segment unless the user want to use different variables values than the configured in OF. Thanks for the help so far, it was very useful. On Thu, 2008-10-23 at 14:08 -0500, Hollis Blanchard wrote: > On Thu, 2008-10-23 at 16:00 -0200, Manoel wrote: > > > > I talked with some folks at #pppc64 on freenode an they suggest that > > the > > OF is loading things in the wrong place could a problem with my > > load-base: > > > > real-base c00000 c00000 > > virt-base ffffffff ffffffff > > real-size 1000000 1000000 > > virt-size ffffffff ffffffff > > load-base 4000 4000 > > > > they suggested to change load-base from 4000 to 200000 but I hava yet > > to try it. They also said that the note section can override > > load-base (and maybe we have some problem there?) > > It's possible. See below. > > > I'm now reading PARP documentation to learn more about OF behavior. I > > thought these machine were CHRP but they are actually PARP (is that > > right?). Son only today I was able to get the correct documentation. > > PAPR was based on the older CHRP specification. > > > > Look at the segment list again: > > > > Program Headers: > > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > > LOAD 0x0000b4 0x00010000 0x00010000 0x0cbe4 0x14098 RWE 0x10 > > > > GNU_STACK 0x00cc98 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 > > > > LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4 > > > > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 > > > > > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 > > this line look somehow wrong. NOTE will be loaded at the address 0? > > and will occupy no memory? that is the same as don't having NOTE at > > all right? > > NOTE is interpreted by the loader (firmware), but not actually loaded > into memory. This is a binary structure that can be used to set some of > the environment variables you mention above. > > The NOTE segment (segment, not section) is created by > util/elf/grub-mkimage.c . You can see that load-base is set to 0x4000 in > that code. Since your text starts at 0x10000, that means your binary can > be at most 0xc000 bytes (48KB) large before it overlaps the text area. > That isn't necessarily a problem; firmware is probably using memmove() > (which handles overlapping areas) to load the segments into place. > > It's probably worth trying a different load-base to see if that could be > the problem here. > -- Best Regards, Manoel Abranches IBM Linux Technology Center Brasil From MAILER-DAEMON Fri Oct 24 09:02:57 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtMJd-0007yw-65 for mharc-grub-devel@gnu.org; Fri, 24 Oct 2008 09:02:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtMJb-0007yP-89 for grub-devel@gnu.org; Fri, 24 Oct 2008 09:02:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtMJZ-0007yD-AM for grub-devel@gnu.org; Fri, 24 Oct 2008 09:02:53 -0400 Received: from [199.232.76.173] (port=39302 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtMJY-0007yA-QD for grub-devel@gnu.org; Fri, 24 Oct 2008 09:02:52 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]:1375) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KtMJY-0002rQ-FW for grub-devel@gnu.org; Fri, 24 Oct 2008 09:02:52 -0400 Received: by ug-out-1314.google.com with SMTP id z36so201598uge.17 for ; Fri, 24 Oct 2008 06:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=RDYYWjHttooH4b7fBw1/ILMz54duDChcT7bHKeRhOto=; b=cb1gLw7lVp7S+R1KCQmGwB95xGgkLAruAggh4uiBiGgu6xma0DzYloINJaSpn8PX2X XjCY+1Zf8M763deEQ4mtxYnADwxW8ldzyovNPtgWZy+ruJp7pnTuRharnTxQEnadJb60 1YyRcHGL5PXzDxsVzH6psbyzQBCRQRCO0YSiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=WYCxW7yjodRa74wgi9wgUHmdZiQtwx2iG7db4ZY5BuWnHXiCizRApX0Te/ZzA36ec+ +opx+2vST1bLIUMs8M/S5quzMctX64yCe5x7bJC/O3HsBOs3O9NFPH/g+pJPYb8pmho1 POAXHu05OEmYYX5AHY+itI0F19fspgAMOapf0= Received: by 10.86.89.1 with SMTP id m1mr286582fgb.16.1224853370725; Fri, 24 Oct 2008 06:02:50 -0700 (PDT) Received: from posto1e113 (fw-priv.eseig.wan.ipp.pt [193.136.56.222]) by mx.google.com with ESMTPS id l12sm564916fgb.6.2008.10.24.06.02.48 (version=SSLv3 cipher=RC4-MD5); Fri, 24 Oct 2008 06:02:49 -0700 (PDT) From: =?utf-8?Q?Jos=C3=A9_Campos?= To: "'The development of GRUB 2'" References: <002a01c9343a$241456b0$6c3d0410$@com> <1224675082.4106.0.camel@fz.local> In-Reply-To: <1224675082.4106.0.camel@fz.local> Date: Fri, 24 Oct 2008 14:09:11 +0100 Message-ID: <001f01c935d9$b7095fb0$251c1f10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack0OdxESCxDhcQ0TYeJBT/l9FYKLwBn39dQ Content-Language: pt X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: svn timed out X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 13:02:55 -0000 Hello, When i try to trunk svn version off grub2 I receive the following = message like bellow: #### [root@Apolo ~]# svn co svn://svn.savannah.gnu.org/grub/trunk/grub2 svn: Can't connect to host 'svn.savannah.gnu.org': Connection timed out #### Can you help me. Thanks -----Mensagem original----- De: grub-devel-bounces+jjscampos=3Dgmail.com@gnu.org = [mailto:grub-devel-bounces+jjscampos=3Dgmail.com@gnu.org] Em nome de = Felix Zielcke Enviada: quarta-feira, 22 de Outubro de 2008 12:31 Para: The development of GRUB 2 Assunto: Re: grub2 background_image difficulty Am Mittwoch, den 22.10.2008, 12:34 +0100 schrieb Jos=C3=A9 Campos: > I have both windows and linux(fedora core8) installed on. >=20 >=20 > I have also installed grub2(v1.96, source compiled by me) as the boot > loader. Hello, Don't use the 1.96 release from february but trunk SVN version. There were many bugfixes since then and I think even in the png module something was fixed in the last months. --=20 Felix Zielcke _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel From MAILER-DAEMON Fri Oct 24 09:57:27 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtNAN-0000tr-Cl for mharc-grub-devel@gnu.org; Fri, 24 Oct 2008 09:57:27 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtNAL-0000qy-3R for grub-devel@gnu.org; Fri, 24 Oct 2008 09:57:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtNAJ-0000o3-F6 for grub-devel@gnu.org; Fri, 24 Oct 2008 09:57:24 -0400 Received: from [199.232.76.173] (port=54850 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtNAJ-0000ni-7y for grub-devel@gnu.org; Fri, 24 Oct 2008 09:57:23 -0400 Received: from igw3.br.ibm.com ([32.104.18.26]:52068) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KtNAJ-0003AT-1A for grub-devel@gnu.org; Fri, 24 Oct 2008 09:57:23 -0400 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw3.br.ibm.com (Postfix) with ESMTP id 7D20139022C for ; Fri, 24 Oct 2008 11:56:27 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9ODuvsg2474094 for ; Fri, 24 Oct 2008 10:56:57 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9ODvDj8017044 for ; Fri, 24 Oct 2008 11:57:13 -0200 Received: from [9.18.200.108] ([9.18.200.108]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9ODv7b5016878 for ; Fri, 24 Oct 2008 11:57:08 -0200 From: Manoel To: The development of GRUB 2 In-Reply-To: <001f01c935d9$b7095fb0$251c1f10$@com> References: <002a01c9343a$241456b0$6c3d0410$@com> <1224675082.4106.0.camel@fz.local> <001f01c935d9$b7095fb0$251c1f10$@com> Content-Type: text/plain; charset=utf-8 Date: Fri, 24 Oct 2008 11:57:15 -0200 Message-Id: <1224856636.7358.20.camel@manoel-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (tstamp-) Subject: Re: svn timed out X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 13:57:25 -0000 You should use this svn co svn://svn.sv.gnu.org/grub/trunk/grub2=20 On Fri, 2008-10-24 at 14:09 +0100, Jos=C3=A9 Campos wrote: > Hello, >=20 > When i try to trunk svn version off grub2 I receive the following messa= ge like bellow: >=20 > #### >=20 > [root@Apolo ~]# svn co svn://svn.savannah.gnu.org/grub/trunk/grub2 > svn: Can't connect to host 'svn.savannah.gnu.org': Connection timed out >=20 > #### >=20 > Can you help me. >=20 > Thanks >=20 > -----Mensagem original----- > De: grub-devel-bounces+jjscampos=3Dgmail.com@gnu.org [mailto:grub-devel= -bounces+jjscampos=3Dgmail.com@gnu.org] Em nome de Felix Zielcke > Enviada: quarta-feira, 22 de Outubro de 2008 12:31 > Para: The development of GRUB 2 > Assunto: Re: grub2 background_image difficulty >=20 > Am Mittwoch, den 22.10.2008, 12:34 +0100 schrieb Jos=C3=A9 Campos: > > I have both windows and linux(fedora core8) installed on. > >=20 > >=20 > > I have also installed grub2(v1.96, source compiled by me) as the boot > > loader. >=20 > Hello, >=20 > Don't use the 1.96 release from february but trunk SVN version. > There were many bugfixes since then and I think even in the png module > something was fixed in the last months. >=20 --=20 Best Regards, Manoel Abranches IBM Linux Technology Center Brazil From MAILER-DAEMON Fri Oct 24 10:30:54 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtNgk-0004rH-3y for mharc-grub-devel@gnu.org; Fri, 24 Oct 2008 10:30:54 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtNgi-0004qM-1e for grub-devel@gnu.org; Fri, 24 Oct 2008 10:30:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtNgg-0004pj-9N for grub-devel@gnu.org; Fri, 24 Oct 2008 10:30:51 -0400 Received: from [199.232.76.173] (port=59377 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtNgg-0004pg-3X for grub-devel@gnu.org; Fri, 24 Oct 2008 10:30:50 -0400 Received: from fg-out-1718.google.com ([72.14.220.154]:40494) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KtNgf-0005oC-Gx for grub-devel@gnu.org; Fri, 24 Oct 2008 10:30:50 -0400 Received: by fg-out-1718.google.com with SMTP id l26so1013927fgb.30 for ; Fri, 24 Oct 2008 07:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=7kmyYYTLzVg+kOg80npY29W+25hHly/tcUVihJq1DoE=; b=Lq/KXV6rVAGW0voE4TyZ1mzL0g+8wmtliP1xacLcdh1+p0fIxznTnRVqmf0Btj9B95 Dfyi4kVb1NUpPDvIXZmbO6mZTlYjh2LtmIsGk+oWaK6O9FX/NJDFsUVXaAYpJL8Nyeyt YI8u/ga928qrgKldhTA2YT31/wgCnW4jFYCBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; b=n78rxyQZ2h8Shp5UqihkDdPVCzedW3/eMApVf5DZUBR4Xct4eZgygtRRnm/hKcNQ/8 lERe/yFaq2rTssy+o/Hi9Wqow8f9QxZpglENv/9a93BRsUiDnCeJnkBpLlyin6MSoqk3 S8QTiNPL7tYKBTpyTNkfFNvUOHpPqfnGcbbqk= Received: by 10.181.61.9 with SMTP id o9mr828986bkk.86.1224858647878; Fri, 24 Oct 2008 07:30:47 -0700 (PDT) Received: from posto1e113 (fw-priv.eseig.wan.ipp.pt [193.136.56.222]) by mx.google.com with ESMTPS id 3sm644443fge.3.2008.10.24.07.30.45 (version=SSLv3 cipher=RC4-MD5); Fri, 24 Oct 2008 07:30:47 -0700 (PDT) From: =?utf-8?Q?Jos=C3=A9_Campos?= To: "'The development of GRUB 2'" Date: Fri, 24 Oct 2008 15:37:08 +0100 Message-ID: <002301c935e6$0063f1f0$012bd5d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack14ILKgpZmjzAVTqSNlTBzXqvHNgABGuZw Content-Language: pt X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: FW: svn timed out X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 14:30:52 -0000 Hello Just try the command you mentioned and got the same error: ### [root@Apolo ~]# svn co svn://svn.sv.gnu.org/grub/trunk/grub2=20 svn: Can't connect to host 'svn.sv.gnu.org': Connection timed out [root@Apolo ~]# ### Sorry, perhaps I'm doing something wrong... I' have already stop = iptables... Appreciate any help. Jos=C3=A9 Campos -----Mensagem original----- De: grub-devel-bounces+jjscampos=3Dgmail.com@gnu.org = [mailto:grub-devel-bounces+jjscampos=3Dgmail.com@gnu.org] Em nome de = Manoel Enviada: sexta-feira, 24 de Outubro de 2008 14:57 Para: The development of GRUB 2 Assunto: Re: svn timed out You should use this svn co svn://svn.sv.gnu.org/grub/trunk/grub2=20 On Fri, 2008-10-24 at 14:09 +0100, Jos=C3=A9 Campos wrote: > Hello, >=20 > When i try to trunk svn version off grub2 I receive the following = message like bellow: >=20 > #### >=20 > [root@Apolo ~]# svn co svn://svn.savannah.gnu.org/grub/trunk/grub2 > svn: Can't connect to host 'svn.savannah.gnu.org': Connection timed = out >=20 > #### >=20 > Can you help me. >=20 > Thanks >=20 > -----Mensagem original----- > De: grub-devel-bounces+jjscampos=3Dgmail.com@gnu.org = [mailto:grub-devel-bounces+jjscampos=3Dgmail.com@gnu.org] Em nome de = Felix Zielcke > Enviada: quarta-feira, 22 de Outubro de 2008 12:31 > Para: The development of GRUB 2 > Assunto: Re: grub2 background_image difficulty >=20 > Am Mittwoch, den 22.10.2008, 12:34 +0100 schrieb Jos=C3=A9 Campos: > > I have both windows and linux(fedora core8) installed on. > >=20 > >=20 > > I have also installed grub2(v1.96, source compiled by me) as the = boot > > loader. >=20 > Hello, >=20 > Don't use the 1.96 release from february but trunk SVN version. > There were many bugfixes since then and I think even in the png module > something was fixed in the last months. >=20 --=20 Best Regards, Manoel Abranches IBM Linux Technology Center Brazil _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel From MAILER-DAEMON Fri Oct 24 10:52:41 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtO1p-0000wJ-HK for mharc-grub-devel@gnu.org; Fri, 24 Oct 2008 10:52:41 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtO1n-0000vs-Nr for grub-devel@gnu.org; Fri, 24 Oct 2008 10:52:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtO1m-0000vL-6i for grub-devel@gnu.org; Fri, 24 Oct 2008 10:52:39 -0400 Received: from [199.232.76.173] (port=49875 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtO1m-0000vI-02 for grub-devel@gnu.org; Fri, 24 Oct 2008 10:52:38 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]:34320) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KtO1l-0005EJ-Pl for grub-devel@gnu.org; Fri, 24 Oct 2008 10:52:38 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9OEqY9U007276 for ; Fri, 24 Oct 2008 10:52:34 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9OEpcRT093464 for ; Fri, 24 Oct 2008 10:51:38 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9OEpcOi026119 for ; Fri, 24 Oct 2008 10:51:38 -0400 Received: from [9.53.41.42] (slate.austin.ibm.com [9.53.41.42]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9OEpb6Y026076; Fri, 24 Oct 2008 10:51:37 -0400 From: Hollis Blanchard To: Manoel In-Reply-To: <1224850215.7358.12.camel@manoel-laptop> References: <1224622323.31194.81.camel@localhost.localdomain> <1224784802.9254.56.camel@manoel-laptop> <1224788935.16720.38.camel@localhost.localdomain> <1224850215.7358.12.camel@manoel-laptop> Content-Type: text/plain Organization: IBM Linux Technology Center Date: Fri, 24 Oct 2008 09:51:35 -0500 Message-Id: <1224859895.9634.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Cc: The development of GRUB 2 , Carlos Roberto do Nascimento Costa Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 14:52:40 -0000 Traditionally, firmware has refused to load an ELF file without a NOTE segment. I feel like I heard that actually changed recently (maybe in the p5 timeframe), but I never investigated further. You could easily test by running grub-mkimage without the -n switch. -- Hollis Blanchard IBM Linux Technology Center On Fri, 2008-10-24 at 10:10 -0200, Manoel wrote: > I changed the load-base to 0x200000 in the note segment that mkelfimage > creates. After that grub2 found the modules info header in the correct > position (as stated in the program header) and was able to load all > modules correctly. > Maybe the Open Firmware detected the overlapping and tried to load the > segment in another place, and for some reason the data write was > corrupted. > Sounds like a OF's bug and I'll report it as you suggested. To me the > correct behavior would be load things in place and correctly even with > overlapping memory. > > And about the note section, what is the point in create it with > hardcoded variables? I don't see a reason to have this note segment > unless the user want to use different variables values than the > configured in OF. > > > Thanks for the help so far, it was very useful. > On Thu, 2008-10-23 at 14:08 -0500, Hollis Blanchard wrote: > > On Thu, 2008-10-23 at 16:00 -0200, Manoel wrote: > > > > > > I talked with some folks at #pppc64 on freenode an they suggest that > > > the > > > OF is loading things in the wrong place could a problem with my > > > load-base: > > > > > > real-base c00000 c00000 > > > virt-base ffffffff ffffffff > > > real-size 1000000 1000000 > > > virt-size ffffffff ffffffff > > > load-base 4000 4000 > > > > > > they suggested to change load-base from 4000 to 200000 but I hava yet > > > to try it. They also said that the note section can override > > > load-base (and maybe we have some problem there?) > > > > It's possible. See below. > > > > > I'm now reading PARP documentation to learn more about OF behavior. I > > > thought these machine were CHRP but they are actually PARP (is that > > > right?). Son only today I was able to get the correct documentation. > > > > PAPR was based on the older CHRP specification. > > > > > > Look at the segment list again: > > > > > Program Headers: > > > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > > > LOAD 0x0000b4 0x00010000 0x00010000 0x0cbe4 0x14098 RWE 0x10 > > > > > GNU_STACK 0x00cc98 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 > > > > > LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4 > > > > > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 > > > > > > > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 > > > this line look somehow wrong. NOTE will be loaded at the address 0? > > > and will occupy no memory? that is the same as don't having NOTE at > > > all right? > > > > NOTE is interpreted by the loader (firmware), but not actually loaded > > into memory. This is a binary structure that can be used to set some of > > the environment variables you mention above. > > > > The NOTE segment (segment, not section) is created by > > util/elf/grub-mkimage.c . You can see that load-base is set to 0x4000 in > > that code. Since your text starts at 0x10000, that means your binary can > > be at most 0xc000 bytes (48KB) large before it overlaps the text area. > > That isn't necessarily a problem; firmware is probably using memmove() > > (which handles overlapping areas) to load the segments into place. > > > > It's probably worth trying a different load-base to see if that could be > > the problem here. > > From MAILER-DAEMON Fri Oct 24 12:12:53 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtPHR-0000tw-1D for mharc-grub-devel@gnu.org; Fri, 24 Oct 2008 12:12:53 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtPHP-0000tg-Vl for grub-devel@gnu.org; Fri, 24 Oct 2008 12:12:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtPHL-0000sb-S7 for grub-devel@gnu.org; Fri, 24 Oct 2008 12:12:51 -0400 Received: from [199.232.76.173] (port=36493 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtPHL-0000sP-Ml for grub-devel@gnu.org; Fri, 24 Oct 2008 12:12:47 -0400 Received: from fg-out-1718.google.com ([72.14.220.157]:58180) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KtPHL-00019B-LT for grub-devel@gnu.org; Fri, 24 Oct 2008 12:12:48 -0400 Received: by fg-out-1718.google.com with SMTP id l26so1044675fgb.30 for ; Fri, 24 Oct 2008 09:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=2se+f9GV/Wpogys8tZKdrbTOTQVhJ/eWCEWyURBrJG8=; b=GvDmxFlQIUxZqTHcnjG6z+dqshKuxCuw7cVpFm4z8ha+WYLbwFm4X1emYsX9l7hQaJ BIQITsfnwNWTBZgRVlAtGewn8hvQSc8wLfOMQ/BYXVBT/JaZrLnlDBCJG/rVxYk9KoRg Ay3/yDhlOi85dKE9+d9GHALJwMUWPzB9Uefuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=n1GRst/p8yEd8vYlvg09s8Bd85gm+FbY9Y3QsiaCWZchLoDlXKiQX6ymQSnaAa3UL/ CujE+BZe7UHatALj2m14tBAN0UNE4hWRs5Ovmt9SGkwVxBqrhLkysKjGlVNL9LlRMhQi +nkLT09F61/s6VL8Va77+aioBfY+89HxIUWRA= Received: by 10.181.197.2 with SMTP id z2mr909762bkp.65.1224864763943; Fri, 24 Oct 2008 09:12:43 -0700 (PDT) Received: from posto1e113 (fw-priv.eseig.wan.ipp.pt [193.136.56.222]) by mx.google.com with ESMTPS id 4sm955805fge.8.2008.10.24.09.12.41 (version=SSLv3 cipher=RC4-MD5); Fri, 24 Oct 2008 09:12:42 -0700 (PDT) From: =?utf-8?Q?Jos=C3=A9_Campos?= To: "'The development of GRUB 2'" References: <002a01c9343a$241456b0$6c3d0410$@com> <1224675356.4106.4.camel@fz.local> In-Reply-To: <1224675356.4106.4.camel@fz.local> Date: Fri, 24 Oct 2008 17:19:05 +0100 Message-ID: <002401c935f4$3dd8cac0$b98a6040$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack0Om99MzlsKe1RTmKk5sDY6B864gBuBsQw Content-Language: pt X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: RE: grub2 background_image difficulty X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 16:12:52 -0000 Hello, thanks I already done trunk the svn version by using: svn co = http://svn... Now I have one more question. About the font o load on your sample grub.cfg. Where or how do I get the = ascii.pff font file? Thanks for your help. Jos=C3=A9 Campos -----Mensagem original----- De: grub-devel-bounces+jjscampos=3Dgmail.com@gnu.org = [mailto:grub-devel-bounces+jjscampos=3Dgmail.com@gnu.org] Em nome de = Felix Zielcke Enviada: quarta-feira, 22 de Outubro de 2008 12:36 Para: The development of GRUB 2 Assunto: Re: grub2 background_image difficulty Am Mittwoch, den 22.10.2008, 12:34 +0100 schrieb Jos=C3=A9 Campos: > set root=3D(hd0,3) > if background_image /grub/images/ESEIG.png ; then > set menu_color_normal=3Dwhite/black > set menu_color_highlight=3Dwhite/green > else > set menu_color_normal=3Dred/black > set menu_color_highlight=3Dred/green > fi >=20 > terminal gfxterm Oh and I think the problem is that you set `terminal gfxterm' after the image is loaded and not before. The update-grub script (or grub-mkconfig now in trunk SVN) normally generates it that way. For example here a snippet from my debian config: ### BEGIN /etc/grub.d/00_header ### set default=3D0 set timeout=3D5 set root=3D(hd0,2) search --fs-uuid --set 1867fa8e-a3f0-422d-912e-7d07556d633c if font /usr/share/grub/ascii.pff ; then set gfxmode=3D640x480 insmod gfxterm insmod vbe terminal gfxterm fi ### END /etc/grub.d/00_header ### ### BEGIN /etc/grub.d/05_debian_theme ### set root=3D(hd0,2) search --fs-uuid --set 1867fa8e-a3f0-422d-912e-7d07556d633c insmod png if background_image /boot/grub/debian-blueish-wallpaper-640x480.png ; = then set color_normal=3Dblack/black set color_highlight=3Dmagenta/black else set menu_color_normal=3Dcyan/blue set menu_color_highlight=3Dwhite/blue fi ### END /etc/grub.d/05_debian_theme ### _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel From MAILER-DAEMON Fri Oct 24 12:24:19 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtPSV-0005za-E0 for mharc-grub-devel@gnu.org; Fri, 24 Oct 2008 12:24:19 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtPST-0005x9-20 for grub-devel@gnu.org; Fri, 24 Oct 2008 12:24:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtPSQ-0005ty-Qc for grub-devel@gnu.org; Fri, 24 Oct 2008 12:24:16 -0400 Received: from [199.232.76.173] (port=59555 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtPSP-0005tf-TY for grub-devel@gnu.org; Fri, 24 Oct 2008 12:24:13 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]:62395) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KtPSP-0005D4-R0 for grub-devel@gnu.org; Fri, 24 Oct 2008 12:24:14 -0400 Received: from [85.180.49.109] (e180049109.adsl.alicedsl.de [85.180.49.109]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1KtPSC48D0-0000Wl; Fri, 24 Oct 2008 18:24:01 +0200 From: Felix Zielcke To: The development of GRUB 2 In-Reply-To: <002401c935f4$3dd8cac0$b98a6040$@com> References: <002a01c9343a$241456b0$6c3d0410$@com> <1224675356.4106.4.camel@fz.local> <002401c935f4$3dd8cac0$b98a6040$@com> Content-Type: text/plain; charset=utf-8 Date: Fri, 24 Oct 2008 18:23:59 +0200 Message-Id: <1224865439.4012.1.camel@fz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V01U2FsdGVkX1/iicgyjURYWkuqpJIF5/9tPqSebDJ6GWAa/LE smDqyj7gpqNBfM2LrELFfx0gQ/4Ewak6EIXQ9Er1Z9TVwaNM2/ DB6V9xqMRdFIyuI1VRAQfa6n7yRC4/i X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6? (barebone, rare!) Subject: RE: grub2 background_image difficulty X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 16:24:17 -0000 Am Freitag, den 24.10.2008, 17:19 +0100 schrieb Jos=C3=A9 Campos: > Now I have one more question. > About the font o load on your sample grub.cfg. Where or how do I get the = ascii.pff font file? >=20 Hi, you need /usr/share/unifont/unifont.hex file which is in Debian etch and Ubuntu in `unifont-bin' package and for Debian lenny/sid it's `unifont'. For the other distros I don't know. --=20 Felix Zielcke From MAILER-DAEMON Fri Oct 24 13:30:12 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtQUF-0000QC-Sr for mharc-grub-devel@gnu.org; Fri, 24 Oct 2008 13:30:11 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtQUD-0000MG-Nk for grub-devel@gnu.org; Fri, 24 Oct 2008 13:30:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtQUB-0000J0-Un for grub-devel@gnu.org; Fri, 24 Oct 2008 13:30:09 -0400 Received: from [199.232.76.173] (port=58442 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtQUB-0000Id-R0 for grub-devel@gnu.org; Fri, 24 Oct 2008 13:30:07 -0400 Received: from mu-out-0910.google.com ([209.85.134.191]:36326) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KtQUA-000850-RJ for grub-devel@gnu.org; Fri, 24 Oct 2008 13:30:07 -0400 Received: by mu-out-0910.google.com with SMTP id i2so683415mue.6 for ; Fri, 24 Oct 2008 10:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=2QVTkrKQfl3jqaW63BAtZFpz4FRY/7ewmpq/85AX1aQ=; b=JqVFROyZE1A9K5A6PmbDdI0JPG+v5Hr2adaI7HAYtbsccZD7wu1AjiCth2tC037ydi D2356VL0qMc148cX2UObfm+TZqL74A9Ahp0sn1dEDBAnQHCS3tegTVlcJ9wwsOEzSLGg hg6QxFIUora20Anl/RiJ9N5I+YrF1OURXz94U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=Mhj+EPBcDduU95foA5peVLtKxucvI38vFD7MwMoEJyEhyyAyFBpVtKBMaGJ4a6pBgw LsMGit0KkrMVjMfDAHFkSnnU+r22U62nQYNmrRF51whgPJrRgcow0b+ExXcB9MQ+AZAF wCp8FDdx9WKzOsgFrsNlsl3MXg9QPIFS1NWm4= Received: by 10.181.146.14 with SMTP id y14mr992006bkn.16.1224869404818; Fri, 24 Oct 2008 10:30:04 -0700 (PDT) Received: from posto1e113 (fw-priv.eseig.wan.ipp.pt [193.136.56.222]) by mx.google.com with ESMTPS id 12sm971563fgg.0.2008.10.24.10.30.01 (version=SSLv3 cipher=RC4-MD5); Fri, 24 Oct 2008 10:30:02 -0700 (PDT) From: =?iso-8859-1?Q?Jos=E9_Campos?= To: "'The development of GRUB 2'" Date: Fri, 24 Oct 2008 18:36:25 +0100 Message-ID: <000001c935ff$0b612be0$222383a0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C93607.6D2593E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack1/wlZJxvrFtUBS62M9cGTXCaTBw== Content-Language: pt X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Can't Load image with background_image X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 17:30:10 -0000 Esta é uma mensagem com várias partes no formato MIME. ------=_NextPart_000_0001_01C93607.6D2593E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, all =20 I already can load a pff font file. =20 But can not load any image (png or tga). Even if I press = =91c=92 on grub boot start and enter the lines my self, I receive the following = : Error: No video mode activated When I try: background_image /grub/ESEIG.png =20 Follow all the command inserted on grub Minimal = BASH-like line editor: font /grub/unifont.pff set gfxmode=3D640x400 insmod gfxterm insmod vbe insmod png terminal gfxterm =20 background_image /grub/ESEIG.png =E7 error where =20 =20 Many thanks. Nice weekend to all. =20 Jos=E9 Campos ------=_NextPart_000_0001_01C93607.6D2593E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Hello, all

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I already can load a pff font file.

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 But can not = load any image (png or tga). Even if I press ‘c’ on grub boot start and = enter the lines my self, I receive the following :

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Error: No video mode activated

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 When I try: background_image /grub/ESEIG.png

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Follow all = the command inserted on grub Minimal BASH-like line editor:

=A0=A0=A0=A0=A0 font = /grub/unifont.pff

=A0 =A0=A0=A0 set = gfxmode=3D640x400

insmod gfxterm

insmod vbe

insmod png

terminal = gfxterm

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = background_image /grub/ESEIG.png=A0 =E7 error where

 

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Many thanks. = Nice weekend to all.

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Jos=E9 = Campos

------=_NextPart_000_0001_01C93607.6D2593E0-- From MAILER-DAEMON Fri Oct 24 17:53:33 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtUb7-0001PU-KP for mharc-grub-devel@gnu.org; Fri, 24 Oct 2008 17:53:33 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtUb6-0001Os-3S for grub-devel@gnu.org; Fri, 24 Oct 2008 17:53:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtUb3-0001Me-Nv for grub-devel@gnu.org; Fri, 24 Oct 2008 17:53:31 -0400 Received: from [199.232.76.173] (port=35624 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtUb3-0001MR-H7 for grub-devel@gnu.org; Fri, 24 Oct 2008 17:53:29 -0400 Received: from igw2.br.ibm.com ([32.104.18.25]:46095) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KtUb2-0003Eq-8f for grub-devel@gnu.org; Fri, 24 Oct 2008 17:53:29 -0400 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw2.br.ibm.com (Postfix) with ESMTP id D7C1D17F4B2 for ; Fri, 24 Oct 2008 19:52:13 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9OLqvcB4149412 for ; Fri, 24 Oct 2008 18:52:57 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9OLrDiJ028302 for ; Fri, 24 Oct 2008 19:53:13 -0200 Received: from [9.18.199.59] ([9.18.199.59]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9OLrDkv028269; Fri, 24 Oct 2008 19:53:13 -0200 From: Manoel To: Hollis Blanchard In-Reply-To: <1224788935.16720.38.camel@localhost.localdomain> References: <1224622323.31194.81.camel@localhost.localdomain> <1224784802.9254.56.camel@manoel-laptop> <1224788935.16720.38.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 24 Oct 2008 19:53:21 -0200 Message-Id: <1224885201.7358.53.camel@manoel-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Cc: The development of GRUB 2 , Carlos Roberto do Nascimento Costa Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 21:53:32 -0000 Changing the load-base worked in the P5 machine but when I tested in the P6 machine I got the following message: Relocation overflow In function grub_arch_dl_relocate_symbols. It means that I'm lacking memory? On Thu, 2008-10-23 at 14:08 -0500, Hollis Blanchard wrote: > On Thu, 2008-10-23 at 16:00 -0200, Manoel wrote: > > > > I talked with some folks at #pppc64 on freenode an they suggest that > > the > > OF is loading things in the wrong place could a problem with my > > load-base: > > > > real-base c00000 c00000 > > virt-base ffffffff ffffffff > > real-size 1000000 1000000 > > virt-size ffffffff ffffffff > > load-base 4000 4000 > > > > they suggested to change load-base from 4000 to 200000 but I hava yet > > to try it. They also said that the note section can override > > load-base (and maybe we have some problem there?) > > It's possible. See below. > > > I'm now reading PARP documentation to learn more about OF behavior. I > > thought these machine were CHRP but they are actually PARP (is that > > right?). Son only today I was able to get the correct documentation. > > PAPR was based on the older CHRP specification. > > > > Look at the segment list again: > > > > Program Headers: > > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > > LOAD 0x0000b4 0x00010000 0x00010000 0x0cbe4 0x14098 RWE 0x10 > > > > GNU_STACK 0x00cc98 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 > > > > LOAD 0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4 > > > > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 > > > > > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4 > > this line look somehow wrong. NOTE will be loaded at the address 0? > > and will occupy no memory? that is the same as don't having NOTE at > > all right? > > NOTE is interpreted by the loader (firmware), but not actually loaded > into memory. This is a binary structure that can be used to set some of > the environment variables you mention above. > > The NOTE segment (segment, not section) is created by > util/elf/grub-mkimage.c . You can see that load-base is set to 0x4000 in > that code. Since your text starts at 0x10000, that means your binary can > be at most 0xc000 bytes (48KB) large before it overlaps the text area. > That isn't necessarily a problem; firmware is probably using memmove() > (which handles overlapping areas) to load the segments into place. > > It's probably worth trying a different load-base to see if that could be > the problem here. > -- Best Regards, Manoel Abranches IBM Linux Technology Center Brazil From MAILER-DAEMON Sat Oct 25 10:33:54 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtkDB-0000NN-Tm for mharc-grub-devel@gnu.org; Sat, 25 Oct 2008 10:33:53 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtkD9-0000Ma-R2 for grub-devel@gnu.org; Sat, 25 Oct 2008 10:33:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtkD8-0000MC-S4 for grub-devel@gnu.org; Sat, 25 Oct 2008 10:33:51 -0400 Received: from [199.232.76.173] (port=58569 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtkD8-0000M1-K2 for grub-devel@gnu.org; Sat, 25 Oct 2008 10:33:50 -0400 Received: from wr-out-0506.google.com ([64.233.184.236]:26526) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KtkD8-0003vD-5e for grub-devel@gnu.org; Sat, 25 Oct 2008 10:33:50 -0400 Received: by wr-out-0506.google.com with SMTP id c30so481884wra.14 for ; Sat, 25 Oct 2008 07:33:49 -0700 (PDT) Received: by 10.151.38.11 with SMTP id q11mr2876582ybj.244.1224945229401; Sat, 25 Oct 2008 07:33:49 -0700 (PDT) Received: by 10.150.191.2 with HTTP; Sat, 25 Oct 2008 07:33:49 -0700 (PDT) Message-ID: Date: Sat, 25 Oct 2008 15:33:49 +0100 From: "Matt Sturgeon" Sender: capt.gen@bberry.biz To: grub-devel@gnu.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13604_33517057.1224945229369" X-Google-Sender-Auth: 6d7f10389775939c X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: GRUB 2 release? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2008 14:33:52 -0000 ------=_Part_13604_33517057.1224945229369 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline when will GRUB 2 be released as stable edition, and will there be an installer? a good idea for an installer would be a live-CD with a text based installer - ubuntu's alternate installer has a good example of a text-based installer (You select an option from isolinux.cfg - the boot menu - then it loads a text-based installer, without even using a kernel). ------=_Part_13604_33517057.1224945229369 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline when will GRUB 2 be released as stable edition, and will there be an installer?
a good idea for an installer would be a live-CD with a text based installer - ubuntu's alternate installer has a good example of a text-based installer (You select an option from isolinux.cfg - the boot menu - then it loads a text-based installer, without even using a kernel). ------=_Part_13604_33517057.1224945229369-- From MAILER-DAEMON Sat Oct 25 12:21:36 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtltP-0006j6-Sk for mharc-grub-devel@gnu.org; Sat, 25 Oct 2008 12:21:35 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtltN-0006iU-4O for grub-devel@gnu.org; Sat, 25 Oct 2008 12:21:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtltI-0006ht-ES for grub-devel@gnu.org; Sat, 25 Oct 2008 12:21:32 -0400 Received: from [199.232.76.173] (port=41831 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtltI-0006hq-8U for grub-devel@gnu.org; Sat, 25 Oct 2008 12:21:28 -0400 Received: from mtiwmhc12.worldnet.att.net ([204.127.131.116]:45542) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KtltI-0006fc-1b for grub-devel@gnu.org; Sat, 25 Oct 2008 12:21:28 -0400 Received: from who8 (h-69-3-194-218.nycmny83.dynamic.covad.net[69.3.194.218]) by worldnet.att.net (mtiwmhc12) with SMTP id <2008102516212611200o5pmqe>; Sat, 25 Oct 2008 16:21:26 +0000 From: "Gregg C Levine" To: "'The development of GRUB 2'" Date: Sat, 25 Oct 2008 12:21:27 -0400 Message-ID: <33A9D2741DB24A5A90897DF26C83C3F9@who8> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 Thread-Index: Ack2rrcMdqmSUYh7Snyd87ld6zad4AADGWUg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: Importance: Normal X-detected-operating-system: by monty-python.gnu.org: NetCache Data OnTap 5.x Subject: RE: GRUB 2 release? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2008 16:21:33 -0000 Hello! That's the beauty of open source. If you, yourself, want to create just = such an installer, and even a live-CD wrapped around your favorite = distribution, then go ahead. Simply announce it here after you've worked out the bugs; = and when you do see those bugs before you are ready for a release, just = describe them here. As far as I know an actual release isn't in the works yet for what's currently stored in SVN, everyone else is still working on such things = as networking. -- Gregg C Levine hansolofalcon@worldnet.att.net "The Force will be with you always." Obi-Wan Kenobi =A0 -----Original Message----- From: grub-devel-bounces+hansolofalcon=3Dworldnet.att.net@gnu.org [mailto:grub-devel-bounces+hansolofalcon=3Dworldnet.att.net@gnu.org] On = Behalf Of Matt Sturgeon Sent: Saturday, October 25, 2008 10:34 AM To: grub-devel@gnu.org Subject: GRUB 2 release? when will GRUB 2 be released as stable edition, and will there be an installer? a good idea for an installer would be a live-CD with a text based = installer - ubuntu's alternate installer has a good example of a text-based = installer (You select an option from isolinux.cfg - the boot menu - then it loads = a text-based installer, without even using a kernel).=20 From MAILER-DAEMON Sat Oct 25 12:24:42 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtlwQ-0007Ng-MD for mharc-grub-devel@gnu.org; Sat, 25 Oct 2008 12:24:42 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtlwO-0007LJ-MD for grub-devel@gnu.org; Sat, 25 Oct 2008 12:24:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtlwN-0007KO-UN for grub-devel@gnu.org; Sat, 25 Oct 2008 12:24:40 -0400 Received: from [199.232.76.173] (port=41898 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtlwN-0007KJ-Q5 for grub-devel@gnu.org; Sat, 25 Oct 2008 12:24:39 -0400 Received: from 166-70-186-42.ip.xmission.com ([166.70.186.42]:52566 helo=onyx.sharktooth.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KtlwN-00005W-Jo for grub-devel@gnu.org; Sat, 25 Oct 2008 12:24:39 -0400 Received: from ut51-217.dsl.relia.net ([72.250.217.51] helo=[192.168.1.183]) by onyx.sharktooth.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Ktl5f-000NwI-JQ for grub-devel@gnu.org; Sat, 25 Oct 2008 09:30:12 -0600 Message-ID: <49033FA8.5010106@joe-lewis.com> Date: Sat, 25 Oct 2008 09:47:52 -0600 From: Joe Lewis User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: grub-devel@gnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 72.250.217.51 X-SA-Exim-Mail-From: joe@joe-lewis.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on onyx.sharktooth.org) X-detected-operating-system: by monty-python.gnu.org: FreeBSD 6.x (1) X-Greylist: delayed 2177 seconds by postgrey-1.27 at monty-python; Sat, 25 Oct 2008 12:24:38 EDT Subject: Question about static compiling X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2008 16:24:41 -0000 Hello, folks; I joined this list as I have been unable to find a solution that I agree with on a simple question. This should be short, and an answer should help others to find solutions through searching. My simple question is - how do I compile a static form of grub2? The background - I am trying to create my own LFS system on a dual quad-core Xeon (x86_64), and the LFS turns out to be a pure-64 bit environment. I am unable to compile grub, as it requires a 32 bit libc, and everything I find about grub shows I will have to use a statically compiled version. My research (mailing list, google, etc) only revealed setting the enviroment variable for the CFLAGS with a -static, but that STILL resulted in the binaries holding a reference to /lib/ld-linux.so, which doesn't exist in a true 64 bit environment - it is /lib/ld-linux-x86_64.so . And, since it is a 64 bit environment, the "static" binaries complain about a corrupt shared object if one just slaps a symlink in there (I've tried everything I can think of). I finally hit a wall, and I do not know where to look next. Has anyone built grub2 on another platform for use in an LFS pure-64 bit environment? Has anyone successfully compiled grub2 in a 64 bit environment (I doubt this, but it doesn't hurt to ask) ? I'd be willing to act as a guinea pig if anyone has some patches to test with, etc. I had the svn version of 1886. Many thanks for taking the time to read this, Joe From MAILER-DAEMON Sat Oct 25 13:03:46 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtmYE-0000if-Er for mharc-grub-devel@gnu.org; Sat, 25 Oct 2008 13:03:46 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtmYC-0000hz-UH for grub-devel@gnu.org; Sat, 25 Oct 2008 13:03:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtmYC-0000hk-EI for grub-devel@gnu.org; Sat, 25 Oct 2008 13:03:44 -0400 Received: from [199.232.76.173] (port=55069 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtmYC-0000he-6X for grub-devel@gnu.org; Sat, 25 Oct 2008 13:03:44 -0400 Received: from hs-out-0708.google.com ([64.233.178.246]:36690) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KtmYB-0005Q4-J0 for grub-devel@gnu.org; Sat, 25 Oct 2008 13:03:43 -0400 Received: by hs-out-0708.google.com with SMTP id 55so466307hsc.10 for ; Sat, 25 Oct 2008 10:03:42 -0700 (PDT) Received: by 10.151.112.17 with SMTP id p17mr8354996ybm.29.1224954222049; Sat, 25 Oct 2008 10:03:42 -0700 (PDT) Received: by 10.150.191.2 with HTTP; Sat, 25 Oct 2008 10:03:42 -0700 (PDT) Message-ID: Date: Sat, 25 Oct 2008 18:03:42 +0100 From: "Matt Sturgeon" Sender: capt.gen@bberry.biz To: "The development of GRUB 2" In-Reply-To: <33A9D2741DB24A5A90897DF26C83C3F9@who8> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14164_3004248.1224954222039" References: <33A9D2741DB24A5A90897DF26C83C3F9@who8> X-Google-Sender-Auth: 1991de8637604287 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: GRUB 2 release? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2008 17:03:45 -0000 ------=_Part_14164_3004248.1224954222039 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline How is GRUB 2 installed at the moment? could you tell me in basic and detail if you know both. 2008/10/25 Gregg C Levine > Hello! > That's the beauty of open source. If you, yourself, want to create just > such > an installer, and even a live-CD wrapped around your favorite distribution, > then go ahead. Simply announce it here after you've worked out the bugs; > and > when you do see those bugs before you are ready for a release, just > describe > them here. > > As far as I know an actual release isn't in the works yet for what's > currently stored in SVN, everyone else is still working on such things as > networking. > -- > Gregg C Levine hansolofalcon@worldnet.att.net > "The Force will be with you always." Obi-Wan Kenobi > > -----Original Message----- > From: grub-devel-bounces+hansolofalcon=worldnet.att.net@gnu.org > [mailto:grub-devel-bounces+hansolofalcon > =worldnet.att.net@gnu.org] On Behalf > Of Matt Sturgeon > Sent: Saturday, October 25, 2008 10:34 AM > To: grub-devel@gnu.org > Subject: GRUB 2 release? > > when will GRUB 2 be released as stable edition, and will there be an > installer? > a good idea for an installer would be a live-CD with a text based installer > - ubuntu's alternate installer has a good example of a text-based installer > (You select an option from isolinux.cfg - the boot menu - then it loads a > text-based installer, without even using a kernel). > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ------=_Part_14164_3004248.1224954222039 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline How is GRUB 2 installed at the moment?

could you tell me in basic and detail if you know both.

2008/10/25 Gregg C Levine <hansolofalcon@worldnet.att.net>
Hello!
That's the beauty of open source. If you, yourself, want to create just such
an installer, and even a live-CD wrapped around your favorite distribution,
then go ahead. Simply announce it here after you've worked out the bugs; and
when you do see those bugs before you are ready for a release, just describe
them here.

As far as I know an actual release isn't in the works yet for what's
currently stored in SVN, everyone else is still working on such things as
networking.
--
Gregg C Levine hansolofalcon@worldnet.att.net
"The Force will be with you always." Obi-Wan Kenobi
 
-----Original Message-----
From: grub-devel-bounces+hansolofalcon=worldnet.att.net@gnu.org
[mailto:grub-devel-bounces+hansolofalcon=worldnet.att.net@gnu.org] On Behalf
Of Matt Sturgeon
Sent: Saturday, October 25, 2008 10:34 AM
To: grub-devel@gnu.org
Subject: GRUB 2 release?

when will GRUB 2 be released as stable edition, and will there be an
installer?
a good idea for an installer would be a live-CD with a text based installer
- ubuntu's alternate installer has a good example of a text-based installer
(You select an option from isolinux.cfg - the boot menu - then it loads a
text-based installer, without even using a kernel).



_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

------=_Part_14164_3004248.1224954222039-- From MAILER-DAEMON Sat Oct 25 13:14:33 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Ktmie-0007Cq-S6 for mharc-grub-devel@gnu.org; Sat, 25 Oct 2008 13:14:32 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ktmid-0007Bc-82 for grub-devel@gnu.org; Sat, 25 Oct 2008 13:14:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ktmib-00079j-ER for grub-devel@gnu.org; Sat, 25 Oct 2008 13:14:30 -0400 Received: from [199.232.76.173] (port=52410 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ktmib-00079c-9e for grub-devel@gnu.org; Sat, 25 Oct 2008 13:14:29 -0400 Received: from igw2.br.ibm.com ([32.104.18.25]:38210) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ktmia-0003ex-IV for grub-devel@gnu.org; Sat, 25 Oct 2008 13:14:29 -0400 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw2.br.ibm.com (Postfix) with ESMTP id 04D2717F42E for ; Sat, 25 Oct 2008 15:13:21 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9PHE6OB4173970 for ; Sat, 25 Oct 2008 14:14:06 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9PHENSE001678 for ; Sat, 25 Oct 2008 15:14:23 -0200 Received: from [9.8.1.106] ([9.8.1.106]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9PHEM7n001673 for ; Sat, 25 Oct 2008 15:14:22 -0200 From: Manoel To: The development of GRUB 2 In-Reply-To: <49033FA8.5010106@joe-lewis.com> References: <49033FA8.5010106@joe-lewis.com> Content-Type: text/plain Date: Sat, 25 Oct 2008 15:14:22 -0200 Message-Id: <1224954862.8384.1.camel@manoel-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: Re: Question about static compiling X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2008 17:14:31 -0000 Even if are using a 64-bit system you can still have 32-bit libraries. I'm not sure about it bur I think the configure script will take care of all flags for you. On Sat, 2008-10-25 at 09:47 -0600, Joe Lewis wrote: > Hello, folks; > > I joined this list as I have been unable to find a solution that I agree > with on a simple question. This should be short, and an answer should > help others to find solutions through searching. My simple question is > - how do I compile a static form of grub2? > > The background - I am trying to create my own LFS system on a dual > quad-core Xeon (x86_64), and the LFS turns out to be a pure-64 bit > environment. I am unable to compile grub, as it requires a 32 bit libc, > and everything I find about grub shows I will have to use a statically > compiled version. My research (mailing list, google, etc) only revealed > setting the enviroment variable for the CFLAGS with a -static, but that > STILL resulted in the binaries holding a reference to /lib/ld-linux.so, > which doesn't exist in a true 64 bit environment - it is > /lib/ld-linux-x86_64.so . And, since it is a 64 bit environment, the > "static" binaries complain about a corrupt shared object if one just > slaps a symlink in there (I've tried everything I can think of). > > I finally hit a wall, and I do not know where to look next. Has anyone > built grub2 on another platform for use in an LFS pure-64 bit > environment? Has anyone successfully compiled grub2 in a 64 bit > environment (I doubt this, but it doesn't hurt to ask) ? I'd be willing > to act as a guinea pig if anyone has some patches to test with, etc. I > had the svn version of 1886. > > Many thanks for taking the time to read this, > Joe > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- Best Regards, Manoel Abranches IBM Linux Technology Center Brazil From MAILER-DAEMON Sat Oct 25 15:02:45 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtoPN-0005e6-G9 for mharc-grub-devel@gnu.org; Sat, 25 Oct 2008 15:02:45 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtoPL-0005cD-Nh for grub-devel@gnu.org; Sat, 25 Oct 2008 15:02:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtoPF-0005WF-Tf for grub-devel@gnu.org; Sat, 25 Oct 2008 15:02:43 -0400 Received: from [199.232.76.173] (port=37181 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtoPF-0005Vy-P3 for grub-devel@gnu.org; Sat, 25 Oct 2008 15:02:37 -0400 Received: from 197.red-80-32-81.staticip.rima-tde.net ([80.32.81.197]:50019 helo=mail.pina.cat) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KtoPF-0002jA-4H for grub-devel@gnu.org; Sat, 25 Oct 2008 15:02:37 -0400 Received: from pinux (unknown [192.168.0.67]) by mail.pina.cat (Postfix) with ESMTP id B74752890653C for ; Sat, 25 Oct 2008 21:02:29 +0200 (CEST) Received: by pinux (Postfix, from userid 1000) id 72B0631DC; Sat, 25 Oct 2008 21:02:27 +0200 (CEST) Date: Sat, 25 Oct 2008 21:02:27 +0200 From: Carles Pina i Estany To: The development of GRUB 2 Message-ID: <20081025190227.GB4743@pina.cat> References: <20080920203745.GA27562@pina.cat> <20080924103424.GK6973@thorin> <20080924160724.GA10087@pina.cat> <20080924163322.GA31610@thorin> <20080924165056.GA24548@pina.cat> <20081021183959.GA12487@pina.cat> <1224626947.3267.21.camel@dv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1224626947.3267.21.camel@dv> User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] Menu control for NPAGE and PPAGE X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2008 19:02:44 -0000 Hi, On Oct/21/2008, Pavel Roskin wrote: > On Tue, 2008-10-21 at 20:39 +0200, Carles Pina i Estany wrote: > > Hello, > > > > On Sep/24/2008, Carles Pina i Estany wrote: > > > > > On Sep/24/2008, Robert Millan wrote: > > > > On Wed, Sep 24, 2008 at 06:07:24PM +0200, Carles Pina i Estany wrote: > > > > > > > > > > New patch is attached. I also improved some other thing. > > > > > > > > > > Feedback is welcomed :-) > > > > > > > > There seems to be an off-by-one problem. Try with the attached grub.cfg. > > > > > > should be fine now, sorry. > > > > pinging... somebody has had time to check it? > > I can commit it if there are no objections and my testing finds no > problems. I don't think that will be objections, we talked about it some time ago. I did some testing and Robert did some too (I think), if you test it and you find some problems report it to me, I will fix and we can commit soon or later. Thanks, -- Carles Pina i Estany GPG id: 0x17756391 http://pinux.info From MAILER-DAEMON Sun Oct 26 12:23:29 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Ku8On-00086k-9o for mharc-grub-devel@gnu.org; Sun, 26 Oct 2008 12:23:29 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ku8Ok-00086E-BM for grub-devel@gnu.org; Sun, 26 Oct 2008 12:23:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ku8Oj-000861-Gz for grub-devel@gnu.org; Sun, 26 Oct 2008 12:23:25 -0400 Received: from [199.232.76.173] (port=43814 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ku8Oj-00085y-B5 for grub-devel@gnu.org; Sun, 26 Oct 2008 12:23:25 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]:58056) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ku8Oj-0000gE-1f for grub-devel@gnu.org; Sun, 26 Oct 2008 12:23:25 -0400 Received: from [85.180.20.91] (e180020091.adsl.alicedsl.de [85.180.20.91]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1Ku8OW1gXi-0006oS; Sun, 26 Oct 2008 17:23:12 +0100 From: Felix Zielcke To: The development of GRUB 2 In-Reply-To: References: <33A9D2741DB24A5A90897DF26C83C3F9@who8> Content-Type: text/plain Date: Sun, 26 Oct 2008 17:23:11 +0100 Message-Id: <1225038191.4216.5.camel@fz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19ZG8m8qb7y6d8w4H9oTGlv/Ua9Y8FgjGAODMw vUP0OR5/MlZk069pDPVBuCF8MQzKb4csjKqDDP5mfnzDVzvUF2 jZg1tQa/dsY1RIqqRJ2WvYT90iaBbRi X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6? (barebone, rare!) Subject: Re: GRUB 2 release? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2008 16:23:26 -0000 Am Samstag, den 25.10.2008, 18:03 +0100 schrieb Matt Sturgeon: > How is GRUB 2 installed at the moment? > > could you tell me in basic and detail if you know both. > svn co svn://svn.sv.gnu.org/grub/trunk/grub2 cd grub2 ./configure && make && make install `grub-install /dev/sda' if you want grub2 to have in MBR of disk sda. and then `grub-mkconfig -o /boot/grub/grub.cfg' to have a generated grub.cfg. -- Felix Zielcke From MAILER-DAEMON Sun Oct 26 12:27:57 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Ku8T7-0001lI-Ke for mharc-grub-devel@gnu.org; Sun, 26 Oct 2008 12:27:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ku8T7-0001ka-1U for grub-devel@gnu.org; Sun, 26 Oct 2008 12:27:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ku8T2-0001e4-LI for grub-devel@gnu.org; Sun, 26 Oct 2008 12:27:56 -0400 Received: from [199.232.76.173] (port=34382 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ku8T2-0001dr-E3 for grub-devel@gnu.org; Sun, 26 Oct 2008 12:27:52 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:57938) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ku8T2-00020S-2B for grub-devel@gnu.org; Sun, 26 Oct 2008 12:27:52 -0400 Received: from [85.180.20.91] (e180020091.adsl.alicedsl.de [85.180.20.91]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1Ku8T10V4Z-0007L9; Sun, 26 Oct 2008 17:27:51 +0100 From: Felix Zielcke To: The development of GRUB 2 In-Reply-To: References: Content-Type: text/plain Date: Sun, 26 Oct 2008 17:27:50 +0100 Message-Id: <1225038470.4216.10.camel@fz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19AQOFsWBfaVLtG9st0cK8Ztn4usrckcYXPqC8 PuqBEoniK+nVYh7pZVPbzIOFAOmIRmtDq4DnkEU2Gt63SjK4Ya eOFaT8VdM4nLbuUVkEJCXPSBpjfQjI8 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: GRUB 2 release? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2008 16:27:57 -0000 Am Samstag, den 25.10.2008, 15:33 +0100 schrieb Matt Sturgeon: > when will GRUB 2 be released as stable edition, and will there be an > installer? grub-legacy wasn't ever released as stable. Though it always depends how you define `stable'. In my opion grub2 is more bugfree then grub-legacy, it just doestn't have yet every feature from it. For example `map' command and savedefault/fallback thing, but instead it has RAID/LVM support for example. There was some talk about a new release 1.97 but unfortunately both maintainers are busy with other things so there won't be that soon a new release, which could be made from my point of view. -- Felix Zielcke From MAILER-DAEMON Sun Oct 26 18:46:00 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KuEMy-0005oA-D8 for mharc-grub-devel@gnu.org; Sun, 26 Oct 2008 18:46:00 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KuEMw-0005nq-Gv for grub-devel@gnu.org; Sun, 26 Oct 2008 18:45:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KuEMt-0005nX-Qi for grub-devel@gnu.org; Sun, 26 Oct 2008 18:45:57 -0400 Received: from [199.232.76.173] (port=34900 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KuEMt-0005nU-KP for grub-devel@gnu.org; Sun, 26 Oct 2008 18:45:55 -0400 Received: from 166-70-186-42.ip.xmission.com ([166.70.186.42]:51262 helo=onyx.sharktooth.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KuEMt-0003JU-J1 for grub-devel@gnu.org; Sun, 26 Oct 2008 18:45:55 -0400 Received: from ut51-217.dsl.relia.net ([72.250.217.51] helo=[192.168.1.183]) by onyx.sharktooth.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KuE5C-0004KY-CQ for grub-devel@gnu.org; Sun, 26 Oct 2008 15:27:39 -0700 Message-ID: <4904F303.3060704@joe-lewis.com> Date: Sun, 26 Oct 2008 16:45:23 -0600 From: Joe Lewis User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <49033FA8.5010106@joe-lewis.com> <1224954862.8384.1.camel@manoel-laptop> In-Reply-To: <1224954862.8384.1.camel@manoel-laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 72.250.217.51 X-SA-Exim-Mail-From: joe@joe-lewis.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on onyx.sharktooth.org) X-detected-operating-system: by monty-python.gnu.org: FreeBSD 6.x (1) Subject: Re: Question about static compiling X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2008 22:45:58 -0000 Manoel wrote: > Even if are using a 64-bit system you can still have 32-bit libraries. > I'm not sure about it bur I think the configure script will take care of > all flags for you.\ > It actually doesn't have the 32 bit. In fact, configure errors out because it cannot find the 32 bit libc, which doesn't exist on an LFS 64-bit system that was compiled purely for 64 bit. So the configure script cannot handle those flags. What I have resorted to is attempting to compile it on a fedora core 8 platform. Unfortunately, this isn't creating static libraries - it still requires some 32-bit shared objects, which means I cannot run it on the 64 bit to install it there. Am I going to have to run another distribution's rescue prompt and manually install it from there? Joe From MAILER-DAEMON Mon Oct 27 04:04:47 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KuN5i-0000UA-Vg for mharc-grub-devel@gnu.org; Mon, 27 Oct 2008 04:04:46 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KuN5h-0000TX-Kj for grub-devel@gnu.org; Mon, 27 Oct 2008 04:04:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KuN5e-0000Qf-8w for grub-devel@gnu.org; Mon, 27 Oct 2008 04:04:44 -0400 Received: from [199.232.76.173] (port=47492 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KuN5e-0000Qc-2s for grub-devel@gnu.org; Mon, 27 Oct 2008 04:04:42 -0400 Received: from mx20.gnu.org ([199.232.41.8]:15044) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KuN5d-0007mF-H6 for grub-devel@gnu.org; Mon, 27 Oct 2008 04:04:41 -0400 Received: from sif.is.scarlet.be ([193.74.71.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KuN5W-0001wT-4y for grub-devel@gnu.org; Mon, 27 Oct 2008 04:04:34 -0400 Received: from scarlet.be (fuji.is.scarlet.be [193.74.71.41]) by sif.is.scarlet.be (8.14.2/8.14.2) with ESMTP id m9R84QaK024524; Mon, 27 Oct 2008 09:04:26 +0100 Date: Mon, 27 Oct 2008 09:04:26 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "rubisher" To: "grub-devel" X-XaM3-API-Version: 4.1 (B54) X-type: 0 X-SenderIP: 57.67.177.33 X-DCC-scarlet.be-Metrics: sif; whitelist X-detected-kernel: by mx20.gnu.org: Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Cc: mrabran , crncosta , grub-devel Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2008 08:04:45 -0000 ---------- Initial header ----------- >From : grub-devel-bounces+rubisher=3Dscarlet.be@gnu.org To : "Manoel" mrabran@linux.vnet.ibm.com CC : "The development of GRUB 2" grub-devel@gnu.org,"Carlos Robe= rto do Nascimento Costa" crncosta@linux.vnet.ibm.com Date : Thu, 23 Oct 2008 14:08:55 -0500 Subject : Re: PPC64 > On Thu, 2008-10-23 at 16:00 -0200, Manoel wrote: > > [snip] > > PAPR was based on the older CHRP specification. > mmm, from my aix boot: '# lscfg -vp' report me: [snip] Model Architecture: chrp [snip] Hth, r. ps: I would like to help more but not enough time right now. [snip] =0A --- More than 2000 Scarlet customers don't pay a subscription anymore! Join and surf free of charge! >> http://www.scarlet.be/nl/mgm From MAILER-DAEMON Mon Oct 27 10:51:27 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KuTRH-0001JO-ME for mharc-grub-devel@gnu.org; Mon, 27 Oct 2008 10:51:27 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KuTRF-0001J2-JU for grub-devel@gnu.org; Mon, 27 Oct 2008 10:51:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KuTRE-0001Il-Oa for grub-devel@gnu.org; Mon, 27 Oct 2008 10:51:25 -0400 Received: from [199.232.76.173] (port=44252 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KuTRE-0001Ig-K7 for grub-devel@gnu.org; Mon, 27 Oct 2008 10:51:24 -0400 Received: from ns39764.ovh.net ([91.121.25.85]:35394 helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KuTRE-0008R2-Bf for grub-devel@gnu.org; Mon, 27 Oct 2008 10:51:24 -0400 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id 10BB53DBE3 for ; Mon, 27 Oct 2008 15:51:21 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Mon, 27 Oct 2008 16:51:10 +0200 User-Agent: KMail/1.9.9 References: <1225038470.4216.10.camel@fz.local> In-Reply-To: <1225038470.4216.10.camel@fz.local> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810271551.11396.okuji@enbug.org> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: GRUB 2 release? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2008 14:51:25 -0000 On Sunday 26 October 2008 17:27:50 Felix Zielcke wrote: > Am Samstag, den 25.10.2008, 15:33 +0100 schrieb Matt Sturgeon: > > when will GRUB 2 be released as stable edition, and will there be an > > installer? > > grub-legacy wasn't ever released as stable. > Though it always depends how you define `stable'. > In my opion grub2 is more bugfree then grub-legacy, it just doestn't > have yet every feature from it. For example `map' command and > savedefault/fallback thing, but instead it has RAID/LVM support for > example. > > There was some talk about a new release 1.97 but unfortunately both > maintainers are busy with other things so there won't be that soon a new > release, which could be made from my point of view. Who has time these days? I can ask the GNU project to appoint yet another person as a co-maintainer. I don't like to be the bottleneck. (Note that being a maintainer needs to follow and advocate the philosophy of GNU, as a representative of the GNU project. So, if you have any important role in another project (e.g. Debian), I don't recommend being a maintainer. Otherwise, you will face on conflicts from time to time.) Regards, Okuji From MAILER-DAEMON Mon Oct 27 13:19:51 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KuVkt-0005j6-EZ for mharc-grub-devel@gnu.org; Mon, 27 Oct 2008 13:19:51 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KuVkr-0005gZ-JQ for grub-devel@gnu.org; Mon, 27 Oct 2008 13:19:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KuVkn-0005bS-Vh for grub-devel@gnu.org; Mon, 27 Oct 2008 13:19:49 -0400 Received: from [199.232.76.173] (port=53230 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KuVkn-0005bC-ND for grub-devel@gnu.org; Mon, 27 Oct 2008 13:19:45 -0400 Received: from c60.cesmail.net ([216.154.195.49]:4143) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1KuVkn-0002LK-Ca for grub-devel@gnu.org; Mon, 27 Oct 2008 13:19:45 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 27 Oct 2008 13:19:44 -0400 Received: from [192.168.0.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id 62E42618FDE; Mon, 27 Oct 2008 13:19:44 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: <1224885201.7358.53.camel@manoel-laptop> References: <1224622323.31194.81.camel@localhost.localdomain> <1224784802.9254.56.camel@manoel-laptop> <1224788935.16720.38.camel@localhost.localdomain> <1224885201.7358.53.camel@manoel-laptop> Content-Type: text/plain Date: Mon, 27 Oct 2008 13:19:42 -0400 Message-Id: <1225127982.4991.7.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: Carlos Roberto do Nascimento Costa , Hollis Blanchard Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2008 17:19:49 -0000 On Fri, 2008-10-24 at 19:53 -0200, Manoel wrote: > Changing the load-base worked in the P5 machine but when I tested in the > P6 machine I got the following message: > Relocation overflow > In function grub_arch_dl_relocate_symbols. > It means that I'm lacking memory? No. Look at the code. For R_PPC_REL24, delta is shifted by 6 bits left and right and should stay the same. It's a 32-bit signed integer. The overflow would happen for positive numbers that exceed (0x7fffffff>>6) or 0x01ffffff. A similar limit exists for negative numbers. I suggest that you add some print statements to find out what's happening. -- Regards, Pavel Roskin From MAILER-DAEMON Tue Oct 28 13:37:05 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KusV7-0008Uj-8a for mharc-grub-devel@gnu.org; Tue, 28 Oct 2008 13:37:05 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KusV6-0008T1-0E for grub-devel@gnu.org; Tue, 28 Oct 2008 13:37:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KusV4-0008Qu-4G for grub-devel@gnu.org; Tue, 28 Oct 2008 13:37:03 -0400 Received: from [199.232.76.173] (port=58444 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KusV3-0008Qb-TA for grub-devel@gnu.org; Tue, 28 Oct 2008 13:37:01 -0400 Received: from mail-gx0-f11.google.com ([209.85.217.11]:59110) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KusV3-0003An-6W for grub-devel@gnu.org; Tue, 28 Oct 2008 13:37:01 -0400 Received: by gxk4 with SMTP id 4so4833437gxk.18 for ; Tue, 28 Oct 2008 10:36:55 -0700 (PDT) Received: by 10.150.177.20 with SMTP id z20mr14701177ybe.98.1225215414743; Tue, 28 Oct 2008 10:36:54 -0700 (PDT) Received: by 10.150.191.2 with HTTP; Tue, 28 Oct 2008 10:36:54 -0700 (PDT) Message-ID: Date: Tue, 28 Oct 2008 17:36:54 +0000 From: "Matt Sturgeon" Sender: capt.gen@bberry.biz To: "The development of GRUB 2" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_40631_1514535.1225215414696" X-Google-Sender-Auth: 6f5ba78ef16f53bd X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Fancy menu theme X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2008 17:37:04 -0000 ------=_Part_40631_1514535.1225215414696 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I was looking at xfce themes and i notist that xfce has another feature, missing from GRUB 2: GRUB 2 uses the following system: [image: Box_slice_names.png]and[image: Box_slice_example_terminal.png] where as xfce uses this system: [image: Pixmaps of a xfwm4 window] they are exactly the same, except that xfce gives you the feature of a background for a title, and two edges for it. so if the fancy menu project by Collin Bennett could include a title option for the menu, and then incorporate a bg field for it, then GRUB 2 will be able to look similar to the OS of the theme creator (for example if they distributed GRUB with there OS) more easily. it would also be good to include a close-window button on the terminal window, to make closing it easier. ------=_Part_40631_1514535.1225215414696 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I was looking at xfce themes and i notist that xfce has another feature, missing from GRUB 2:

GRUB 2 uses the following system:

Box_slice_names.pngandBox_slice_example_terminal.png

where as xfce uses this system:

Pixmaps of a xfwm4 window

they are exactly the same, except that xfce gives you the feature of a background for a title, and two edges for it.
so if the fancy menu project by Collin Bennett could include a title option for the menu, and then incorporate a bg field for it, then GRUB 2 will be able to look similar to the OS of the theme creator (for example if they distributed GRUB with there OS) more easily.

it would also be good to include a close-window button on the terminal window, to make closing it easier. ------=_Part_40631_1514535.1225215414696-- From MAILER-DAEMON Tue Oct 28 16:56:09 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kuvbl-0007xK-MK for mharc-grub-devel@gnu.org; Tue, 28 Oct 2008 16:56:09 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kuvbj-0007w8-2I for grub-devel@gnu.org; Tue, 28 Oct 2008 16:56:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kuvbf-0007sg-BH for grub-devel@gnu.org; Tue, 28 Oct 2008 16:56:05 -0400 Received: from [199.232.76.173] (port=44444 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kuvbe-0007sF-OT for grub-devel@gnu.org; Tue, 28 Oct 2008 16:56:02 -0400 Received: from gateway13.websitewelcome.com ([67.18.137.85]:55462) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Kuvbe-000777-AV for grub-devel@gnu.org; Tue, 28 Oct 2008 16:56:02 -0400 Received: (qmail 20984 invoked from network); 28 Oct 2008 21:06:40 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway13.websitewelcome.com with SMTP; 28 Oct 2008 21:06:40 -0000 Received: from [146.187.184.228] (port=36988 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KuvbW-0001C4-Au; Tue, 28 Oct 2008 15:55:54 -0500 Date: Tue, 28 Oct 2008 13:54:33 -0700 From: Colin D Bennett To: The development of GRUB 2 Message-ID: <20081028135433.2927f595@gibibit.com> In-Reply-To: References: X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/so+ZSRCQwAt_yS6e9JRa++J"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: mttza1@gmail.com Subject: Re: Fancy menu theme X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2008 20:56:07 -0000 --Sig_/so+ZSRCQwAt_yS6e9JRa++J Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 28 Oct 2008 17:36:54 +0000 "Matt Sturgeon" wrote: > Hi, I was looking at xfce themes and i notist that xfce has another > feature, missing from GRUB 2: >=20 > GRUB 2 uses the following system: >=20 > [image: Box_slice_names.png]and[image: Box_slice_example_terminal.png] >=20 > where as xfce uses this system: >=20 > [image: Pixmaps of a xfwm4 window] >=20 > they are exactly the same, except that xfce gives you the feature of a > background for a title, and two edges for it. > so if the fancy menu project by Collin Bennett could include a title > option for the menu, and then incorporate a bg field for it, then > GRUB 2 will be able to look similar to the OS of the theme creator > (for example if they distributed GRUB with there OS) more easily. Yes, there are several ways that the theme support can be made more flexible. Particularly, we could allow the themed boxes (which are used for windows, selection highlights, etc.) to be composed of a set of any number of pixmaps, where each pixmap has a placement and size policy. The current configuration looks like this: - 4x corners : placed in the 4 corners of the box. Not scaled. - 4x sides : placed along the top, bottom, left, and right of the box. Scaled to the correct length to fit the side based on the box's runtime size. - center : pixmap scaled to fit the area not used by the sides/corners A more flexible arrangement with arbitrary pixmap placement could allow the addition of other pixmaps, such as - title : title bar placed below the "north" side but above the "center". Centered. Not scaled. The actual format used to specify the pixmap placement and size policies would have to be decided, and a more advanced layout algorithm would have to be implemented. The one I have currently implemented is obviously quite simple. > it would also be good to include a close-window button on the terminal > window, to make closing it easier. Well, that would make sense if/when mouse support is added down the road. (It may not be too difficult, and I hope to tackle it some time.) Regards, Colin --Sig_/so+ZSRCQwAt_yS6e9JRa++J Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkHfA0ACgkQokx8fzcGbYeI4QCfRRRBNLYxjzklWoX93S+Pe3Og L3IAn3Zrz5MJVSPOCHrHr27JirTHy32F =sOyL -----END PGP SIGNATURE----- --Sig_/so+ZSRCQwAt_yS6e9JRa++J-- From MAILER-DAEMON Wed Oct 29 06:45:27 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kv8YJ-0003QR-JM for mharc-grub-devel@gnu.org; Wed, 29 Oct 2008 06:45:27 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kv8YH-0003Pf-0Q for grub-devel@gnu.org; Wed, 29 Oct 2008 06:45:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kv8YE-0003Om-Uq for grub-devel@gnu.org; Wed, 29 Oct 2008 06:45:24 -0400 Received: from [199.232.76.173] (port=56042 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kv8YE-0003Og-O5 for grub-devel@gnu.org; Wed, 29 Oct 2008 06:45:22 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]:21807) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kv8YE-0002Or-36 for grub-devel@gnu.org; Wed, 29 Oct 2008 06:45:22 -0400 Received: by nf-out-0910.google.com with SMTP id c7so1392933nfi.26 for ; Wed, 29 Oct 2008 03:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=E45O+iUcZZ3g/hg+cgMspgDTAl86vTDX+nLw1jSi3GA=; b=vCVX3v98hev63/AiTXJgcpFd+cTjDuBxwISLmlyuRKhpBiQoFU+E3BWSrEMhg+w233 SGDPAEmnw3G5TtXZio17Ir2jPfa/GjCLjXsUtxDw7HpIk/QGpwYETpMrONsIloRzcdv5 MTQc3IgoYfXkf9rm/wTxySawyHfvqoEeI+g/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=Hz1ch5/Sg7ylgsMMxlPwLPhT8HdVGtKbhHhNRg3n9zGgeEiCQarHUAHgbhYxPIcgo/ zx4TtEtzQdAWNHn0QRhokpROo1iZgh71YFVXMWo//1vM60DWK1aHltVCiLvwianNJIu3 UWB1djNsjS9yZQhW38oA0EtwqIjPqWMpekbM8= Received: by 10.86.96.18 with SMTP id t18mr5465930fgb.56.1225277116185; Wed, 29 Oct 2008 03:45:16 -0700 (PDT) Received: from posto1e113 (fw-priv.eseig.wan.ipp.pt [193.136.56.222]) by mx.google.com with ESMTPS id d6sm3596406fga.2.2008.10.29.03.45.14 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Oct 2008 03:45:15 -0700 (PDT) From: =?iso-8859-1?Q?Jos=E9_Campos?= To: "'The development of GRUB 2'" Date: Wed, 29 Oct 2008 10:51:43 -0000 Message-ID: <001801c939b4$563b4070$02b1c150$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C939B4.563B4070" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack5tFG5jqyhu8/4RF2JuzHkj5iCpA== Content-Language: pt X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Hide de Rectangle X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2008 10:45:25 -0000 Esta é uma mensagem com várias partes no formato MIME. ------=_NextPart_000_0019_01C939B4.563B4070 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is there any way to hide the rectangle and bottom text shown at boot. This is in front of the defined background_image. =20 Can I use the password command just like in the grub = legacy? =20 Many thanks =20 Jos=E9 Campos ------=_NextPart_000_0019_01C939B4.563B4070 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Is there any way to hide the rectangle and bottom =A0text shown at boot. This is in front of the = defined background_image.

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Can I use the = password command just like in the grub legacy?

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Many = thanks

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Jos=E9 = Campos

------=_NextPart_000_0019_01C939B4.563B4070-- From MAILER-DAEMON Wed Oct 29 23:21:36 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KvO6K-0003tC-HN for mharc-grub-devel@gnu.org; Wed, 29 Oct 2008 23:21:36 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KvO6I-0003qe-BA for grub-devel@gnu.org; Wed, 29 Oct 2008 23:21:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvO6G-0003qQ-G6 for grub-devel@gnu.org; Wed, 29 Oct 2008 23:21:32 -0400 Received: from [199.232.76.173] (port=56584 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvO6G-0003qN-B0 for grub-devel@gnu.org; Wed, 29 Oct 2008 23:21:32 -0400 Received: from gateway02.websitewelcome.com ([69.56.159.20]:38394) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KvO6G-000563-1d for grub-devel@gnu.org; Wed, 29 Oct 2008 23:21:32 -0400 Received: (qmail 4461 invoked from network); 30 Oct 2008 03:38:52 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway02.websitewelcome.com with SMTP; 30 Oct 2008 03:38:52 -0000 Received: from c-67-185-177-95.hsd1.wa.comcast.net ([67.185.177.95]:58247 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KvO67-00054q-FW; Wed, 29 Oct 2008 22:21:23 -0500 Date: Wed, 29 Oct 2008 20:20:00 -0700 From: Colin D Bennett To: The development of GRUB 2 Message-ID: <20081029202000.66f38131@gibibit.com> In-Reply-To: <48F5FF64.6010500@nic.fi> References: <20080831000157.0c548199@gamma.lan> <48BAC517.4060002@nic.fi> <48BD5F00.9090902@nic.fi> <48E67DB3.8030408@nic.fi> <20081013100010.22d1dc54@gibibit.com> <48F39322.8060508@nic.fi> <20081013130005.2adac4b2@gibibit.com> <48F3B98E.4060109@nic.fi> <20081014224251.78ee2aa0@gibibit.com> <48F5FF64.6010500@nic.fi> X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/X5H1Qh94TFn9Q.6sSnMyDTq"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: Subject: Re: [PATCH] GSoC #09 Bitmap scaling X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2008 03:21:35 -0000 --Sig_/X5H1Qh94TFn9Q.6sSnMyDTq Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 15 Oct 2008 17:34:12 +0300 Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > Colin D Bennett wrote: > > On Tue, 14 Oct 2008 00:11:42 +0300 > > Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > >> As we have same handle all the time for bitmap we can just > >> continue to use it as is. If we would make new instance of it, > >> would either need to delete previous one and replace its usage > >> with new one. Of course use case here affects. > >=20 > > Ok. That's fine. I'm still a little confused about the purpose of > > lock/unlock, however. Is it basically a way of catching mistakes in > > the code where we accidentally try to modify bitmap data when we > > don't want to? I guess what I'm asking is, do lock/unlock do > > anything more than set a flag that is checked, as in: (pseudocode) > >=20 > >=20 > > void *get_ptr(bitmap b) > > { > > if (b.optimized) return error(); > > return b.ptr;=20 > > } > > void optimize(bitmap b) > > { > > if (b.locked) error(); > > /* optimize b... */ > > } > > void lock(bitmap b) > > { > > if (b.locked) error(); > > b.locked =3D 1;=20 > > } > > void unlock(bitmap b) { b.locked =3D 0; } >=20 > No, more like: >=20 > void *lock(bitmap b) > { > if (b.locked) return NULL; > if (b.optimized) return NULL; >=20 > b.locked =3D 1; >=20 > return b.dataptr; > } >=20 > void unlock(bitmap b) > { > b.locked =3D 0; > } >=20 > grub_err_t optimize(bitmap b, rendertarget r) > { > if (b.locked) return error; > if (b.optimized) return error; >=20 > // do magic > b.optimized =3D 1; >=20 > return success; > } >=20 > Now one would use it like: >=20 > ptr =3D lock(); > if (ptr) > { > // modify it. > ptr[0] =3D blue; > ptr[1] =3D green; > ptr[2] =3D red; > if (has_alpha) > ptr[3] =3D alpha; >=20 > unlock(); > } Any more thoughts on this? I can try to implement the bitmap optimization when I have a chance, but I wondered if you had any more insights into how you think it should work before I got to the effort of implementing it. Perhaps if we were to modify some of the "user" code to use bitmap optimization, we could see how the proposed API works out, and whether there are any things we could do better to make it easier for the users of the bitmap API, since there are many users and only one bitmap API that has to do the dirty work. It would be nice if the API made simple, common tasks are made easy for users. Do you think we should return a uint8_t* from the lock() function? The other option is to return a basic structure to the caller that provides the necessary information to manipulate the data in the 'unoptimized' format (perhaps we could call it the 'intermediate representation' or common format to avoid the cumbersome 'unoptimized' term). User code that uses the "accessible" or "portable" standard bitmap format for manipulation does not need most of the stuff in the bitmap's mode_info struct, so it might simplify the task of user code if we had a structure with just the data relevant to manipulation of these accessible bitmaps. For instance: struct common_bitmap // An RGB/RGBA bitmap in the standard format. { uint8_t *data; // Pixel data in BGR[A] order int width; // Width in pixels int height; // Height in pixels (number of rows in DATA) int stride; // Number of bytes per row in DATA bool has_alpha; // Alpha channel? 0 =3D> BGR, 1 =3D> BGRA }; Then user code could do something like this: struct bitmap * prepare_frob_bitmap (render_target target) { struct bitmap *bitmap; struct common_bitmap work; create_bitmap (&bitmap, 640, 480, NO_ALPHA); bitmap_lock (bitmap, &work); do_something_to_bitmap (&work); bitmap_unlock (bitmap); bitmap_optimize (bitmap, target); } Regards, Colin --Sig_/X5H1Qh94TFn9Q.6sSnMyDTq Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkJJ+YACgkQokx8fzcGbYfbZwCdG5AVhiwI4acXgCVPGA9gryJQ C+YAmwZKsoxO2g5aNElE2h41YInbDYQ0 =nZz1 -----END PGP SIGNATURE----- --Sig_/X5H1Qh94TFn9Q.6sSnMyDTq-- From MAILER-DAEMON Thu Oct 30 15:12:37 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kvcwf-0000RB-Iy for mharc-grub-devel@gnu.org; Thu, 30 Oct 2008 15:12:37 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kvcwd-0000Qt-O4 for grub-devel@gnu.org; Thu, 30 Oct 2008 15:12:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kvcwb-0000Qh-OQ for grub-devel@gnu.org; Thu, 30 Oct 2008 15:12:35 -0400 Received: from [199.232.76.173] (port=54369 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kvcwb-0000Qe-JW for grub-devel@gnu.org; Thu, 30 Oct 2008 15:12:33 -0400 Received: from gateway12.websitewelcome.com ([69.41.255.7]:46400) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Kvcwb-0007M9-3s for grub-devel@gnu.org; Thu, 30 Oct 2008 15:12:34 -0400 Received: (qmail 21119 invoked from network); 30 Oct 2008 19:23:12 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway12.websitewelcome.com with SMTP; 30 Oct 2008 19:23:12 -0000 Received: from c-67-185-177-95.hsd1.wa.comcast.net ([67.185.177.95]:38940 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KvcwS-0004Bx-LZ; Thu, 30 Oct 2008 14:12:25 -0500 Date: Thu, 30 Oct 2008 12:11:06 -0700 From: Colin D Bennett To: The development of GRUB 2 Message-ID: <20081030121106.4efffecc@gibibit.com> In-Reply-To: <48E87FB9.8070603@nic.fi> References: <20080901092753.3918cf73@gamma.lan> <20081004214640.5ab21f53@gibibit.com> <48E87FB9.8070603@nic.fi> X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/4.0QWF1RbluvAB7Y_uAF.nU" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: Subject: Re: [PATCH] GSoC #10 new font engine (UTF-8 support) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2008 19:12:35 -0000 --MP_/4.0QWF1RbluvAB7Y_uAF.nU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Vesa, I have implemented UTF-8 support in the new font engine. I have also added smart glyph fallback behavior, which is used when the requested font is missing a glyph from the text being rendered. In that case, all other loaded fonts are checked to see if any of them have the requested character. The font most similar (mainly in size) to the current font is selected. My example in the 'videotest' command uses the '10x20' fixed font (the name is "Fixed 20" when requesting the font) which provides all the Unicode characters that the test uses. However, when the test uses Helvetica, which is missing many of the non-ASCII characters, the smart glyph substitution uses glyphs from other fonts (including Fixed 20) to render those characters. To see what this looks like, look at . This is a screen shot of the enhanced videotest (GSoC patch #12) rendering UTF-8 strings. I don't have many good fonts here, but it is nice to see that Helvetica 8 (the bottom font) uses smaller replacement glyphs for its missing characters than the others do. Without the glyph substitution, you would see the 'unknown glyph' question-mark symbol instead. Attached is my new patch which hopefully addresses your points below. Summary of changes since the previous patch: - UTF-8 text support (including 'videotest' changes to test it) - Smart substitution for missing glyphs - Text rendering code is in the font module instead of vbe - Comment formatting fixed - Single font.c file instead of multiple source files Responses to your comments follow. On Sun, 05 Oct 2008 11:50:01 +0300 Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > Colin D Bennett wrote: > > Clean patch against SVN revision 1885. > >=20 > > Regards, > > Colin >=20 > Thanks for the re-base. >=20 > Here are some comments about the patch. >=20 > Check the commenting of multi line comments. Ok, fixed. >=20 > > +int > > +grub_font_get_string_width (grub_font_t font, const char *str) > > +{ > > + int i; > > + int width; > > + struct grub_font_glyph *glyph; > > + grub_size_t len; > > + > > + len =3D grub_strlen (str); > > + > > + for (i =3D 0, width =3D 0; i < len; i++) > > + { > > + glyph =3D grub_font_get_glyph (font, str[i]); > > + width +=3D glyph->device_width; > > + } > > + > > + return width; > > +} >=20 > I do not see this being utf-8 compatible eg. it breaks our Unicode > displaying support. See how grub_putchar() handles this. >=20 > There is also the same problem in grub_video_vbe_draw_string(). Fixed. > > =3D=3D=3D modified file 'conf/sparc64-ieee1275.rmk' > > --- conf/sparc64-ieee1275.rmk 2008-09-08 12:52:30 +0000 > > +++ conf/sparc64-ieee1275.rmk 2008-10-05 04:30:04 +0000 >=20 > As font code is common code. There is no need to modify sparc64 > specific makefile. You have correctly modified common.rmk so that is > enough. If sparc64 support should be moved to use common.rmk like any > other arch. Let it rot. Ok, I reverted my changes to the sparc64 file. > > =3D=3D=3D added file 'font/loader.c' > > --- font/loader.c 1970-01-01 00:00:00 +0000 > > +++ font/loader.c 2008-10-05 04:30:04 +0000 >=20 > > +/* > > + Read a 16-bit big-endian integer from FILE, convert it to > > native byte > > + order, and store it in *VALUE. > > + Returns 0 on success, 1 on failure. > > + */ > > +static int > > +read_be_uint16 (grub_file_t file, grub_uint16_t * value) >=20 > Are you fan of bigendian or why did you choose that :) ? Well, I had to choose a byte order, and I arbitrarily chose big-endian (isn't that the "network byte order" used for TCP/IP, etc.?) > > +struct grub_font_glyph * > > +grub_font_get_glyph (grub_font_t font, grub_uint32_t code) >=20 > I would propose to but all public API's to one file. Ok, it's unified into a single font.c -- this is good for encapsulation, as well. The 'font_internal.h' is gone. > > =3D=3D=3D modified file 'include/grub/video.h' > > --- include/grub/video.h 2008-10-05 04:28:39 +0000 > > +++ include/grub/video.h 2008-10-05 04:30:04 +0000 >=20 > Now that you have moved glyph rendering out from specialized glyph > rendering to bitmap rendering I would propose that no font rendering > code resides in Video API. I think this is a good move. >=20 > I would move that to font.mod (or perhaps to graphical terminal?). We > can adapt other graphical terminals to use video API to render stuff. > It just takes a bit time. But I think this time is as good as any to > start that process. All font rendering functions are in the font module now. Yes, this is a much cleaner way to do it. > Lets have another look at it after those modifications :) >=20 > Thanks, > Vesa J=C3=A4=C3=A4skel=C3=A4inen Let me know how this looks. Regards, Colin --MP_/4.0QWF1RbluvAB7Y_uAF.nU Content-Type: text/x-patch; name=10_font-engine-utf8_2008-10-30.patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=10_font-engine-utf8_2008-10-30.patch 2008-10-30 Colin D Bennett New font engine supporting large and proportional fonts, PFF2 file format. * commands/videotest.c (grub_cmd_videotest): Use new font API, test drawing UTF-8 Unicode text. * conf/common.rmk (font_mod_SOURCES): Update source file list. * font/font.c: New file. * font/font_cmd.c: New file. * font/manager.c: Deleted. * include/grub/font.h: Update copyright years. (GRUB_FONT_MAGIC): Removed. (grub_font): New forward declaration of struct. (grub_font_t): New typedef. (grub_font_node): New struct. (grub_font_list): New global symbol. (grub_font_glyph): Updated data structure to support larger, variable size fonts and to support font metrics. (grub_font_glyph_t): Removed. (grub_font_loader_init): New prototype. (grub_font_load): New prototype. (grub_font_get): New prototype. (grub_font_get_name): New prototype. (grub_font_get_max_char_width): New prototype. (grub_font_get_max_char_height): New prototype. (grub_font_get_ascent): New prototype. (grub_font_get_descent): New prototype. (grub_font_get_leading): New prototype. (grub_font_get_height): New prototype. (grub_font_get_string_width): New prototype. (grub_font_load): New prototype. (grub_font_get_glyph): New prototype. (grub_font_get_glyph_with_fallback): New prototype. (grub_font_draw_glyph): New prototype. (grub_font_draw_string): New prototype. * include/grub/misc.h (grub_utf8_to_ucs4): Added parameters. * include/grub/video.h (grub_font_glyph): Removed forward struct declaration. (GRUB_VIDEO_MODE_TYPE_ALPHA): Changed bit mask value to make space for 1BIT_BITMAP. (GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED): Likewise. (GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP): New bit mask constant. (GRUB_VIDEO_MODE_TYPE_COLOR_MASK): Updated to a wider mask to make space for 1BIT_BITMAP. (GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED): New blit format enum value. (grub_video_mode_info): Added bg_red, bg_green, bg_blue, bg_alpha, fg_red, fg_green, fg_blue, and fg_alpha fields. * kern/misc.c (grub_utf8_to_ucs4): Support null-terminated UTF-8 strings and allow limiting the number of Unicode characters decoded. * kern/term.c (grub_putchar): Pass additional arguments to grub_utf8_to_ucs4. * normal/menu.c (print_entry): Pass destination maximum length to grub_utf8_to_ucs4. * term/gfxterm.c (DEFAULT_CHAR_WIDTH): Removed. (DEFAULT_CHAR_HEIGHT): Removed. (grub_virtual_screen): Added font field. (grub_virtual_screen_setup): Add font_name parameter. Initialize terminal font information. (grub_gfxterm_init): Get font name from gfxterm_font environment variable. Pass font name to grub_virtual_screen_setup. (write_char): Place glyphs using their baseline, based on the font ascent. (write_cursor): Draw cursor using font ascent as a reference. (grub_gfxterm_putchar): Use new font API. Breaks bi-width font support. (grub_gfxterm_getcharwidth): Assume all characters are 1 character in width. Breaks bi-width font support. (grub_vga_getcharwidth): Always return a width of 1. * term/i386/pc/vesafb.c (grub_virtual_screen_get_glyph): Use new font API. Breaks vesafb glyph drawing, since it copied the glyph data directly, but now glyphs use a different storage format. This code shouldn't compile, but GRUB builds ok! * term/i386/pc/vga.c (font): New static variable. (grub_vga_mod_init): Get a font using the new font API. (write_char): Broken. Commented out code with #if 0 since it will need to be rewritten to handle the new glyph storage format if we want to maintain the vga terminal. (grub_vga_putchar): Update to use new font API; breaks support for bi-width fonts. * video/i386/pc/vbe.c (grub_video_vbe_map_rgb): Support GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP. (grub_video_vbe_map_rgba): Likewise. (grub_video_vbe_unmap_color_int): Likewise. (grub_video_vbe_blit_glyph): Deleted. (grub_video_vbe_adapter): Deleted blit_glyph member. * video/i386/pc/vbeutil.c (get_data_ptr): Add a comment to the switch statement indicating why it is unimplemented for 1-bit bitmaps. (get_pixel): Support 1-bit bitmaps. (set_pixel): Support 1-bit bitmaps. * video/video.c (grub_video_blit_glyph): Renamed coordinate arguments for clarity. (grub_video_draw_string): New function. === modified file 'commands/videotest.c' --- commands/videotest.c 2007-07-21 22:32:33 +0000 +++ commands/videotest.c 2008-10-30 18:28:52 +0000 @@ -1,6 +1,6 @@ /* * GRUB -- GRand Unified Bootloader - * Copyright (C) 2006,2007 Free Software Foundation, Inc. + * Copyright (C) 2006,2007,2008 Free Software Foundation, Inc. * * GRUB is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -36,17 +36,21 @@ GRUB_VIDEO_MODE_TYPE_INDEX_COLOR) != GRUB_ERR_NONE) return grub_errno; - grub_getkey (); - grub_video_color_t color; unsigned int x; unsigned int y; unsigned int width; unsigned int height; int i; - struct grub_font_glyph glyph; + grub_font_t sansbig; + grub_font_t sans; + grub_font_t sanssmall; + grub_font_t fixed; + struct grub_font_glyph *glyph; struct grub_video_render_target *text_layer; grub_video_color_t palette[16]; + const char *str; + int texty; grub_video_get_viewport (&x, &y, &width, &height); @@ -65,8 +69,15 @@ color = grub_video_map_rgb (0, 255, 255); grub_video_fill_rect (color, 100, 100, 100, 100); - grub_font_get_glyph ('*', &glyph); - grub_video_blit_glyph (&glyph, color, 200 ,0); + sansbig = grub_font_get ("Helvetica Bold 24"); + sans = grub_font_get ("Helvetica Bold 14"); + sanssmall = grub_font_get ("Helvetica 8"); + fixed = grub_font_get ("Fixed 20"); + if (! sansbig || ! sans || ! sanssmall || ! fixed) + return grub_error (GRUB_ERR_BAD_FONT, "No font loaded."); + + glyph = grub_font_get_glyph (fixed, '*'); + grub_font_draw_glyph (glyph, color, 200 ,0); grub_video_set_viewport (x + 150, y + 150, width - 150 * 2, height - 150 * 2); @@ -77,18 +88,69 @@ color = grub_video_map_rgb (255, 255, 255); - grub_font_get_glyph ('A', &glyph); - grub_video_blit_glyph (&glyph, color, 16, 16); - grub_font_get_glyph ('B', &glyph); - grub_video_blit_glyph (&glyph, color, 16 * 2, 16); - - grub_font_get_glyph ('*', &glyph); + texty = 32; + grub_font_draw_string ("The quick brown fox jumped over the lazy dog.", + sans, color, 16, texty); + texty += grub_font_get_descent (sans) + grub_font_get_leading (sans); + + texty += grub_font_get_ascent (fixed); + grub_font_draw_string ("The quick brown fox jumped over the lazy dog.", + fixed, color, 16, texty); + texty += grub_font_get_descent (fixed) + grub_font_get_leading (fixed); + + /* To convert Unicode characters into UTF-8 for this test, the following + command is useful: + echo -ne '\x00\x00\x26\x3A' | iconv -f UTF-32BE -t UTF-8 | od -t x1 + This converts the Unicode character U+263A to UTF-8. */ + + /* Characters used: + Code point Description UTF-8 encoding + ----------- ------------------------------ -------------- + U+263A unfilled smiley face E2 98 BA + U+00A1 inverted exclamation point C2 A1 + U+00A3 British pound currency symbol C2 A3 + U+03C4 Greek tau CF 84 + U+00E4 lowercase letter a with umlaut C3 A4 + U+2124 set 'Z' symbol (integers) E2 84 A4 + U+2287 subset symbol E2 8A 87 + U+211D set 'R' symbol (real numbers) E2 84 9D */ + + str = + "Unicode test: happy\xE2\x98\xBA \xC2\xA3 5.00" + " \xC2\xA1\xCF\x84\xC3\xA4u! " + " \xE2\x84\xA4\xE2\x8A\x87\xE2\x84\x9D"; + color = grub_video_map_rgb (128, 128, 255); + + /* All characters in the string exist in the 'Fixed 20' (10x20) font. */ + texty += grub_font_get_ascent(fixed); + grub_font_draw_string (str, fixed, color, 16, texty); + texty += grub_font_get_descent (fixed) + grub_font_get_leading (fixed); + + /* Some character don't exist in the Helvetica font, so the font engine + will fall back to using glyphs from another font that does contain them. + TODO The font engine should be smart about selecting a replacement font + and prioritize fonts with similar sizes. */ + + texty += grub_font_get_ascent(sansbig); + grub_font_draw_string (str, sansbig, color, 16, texty); + texty += grub_font_get_descent (sansbig) + grub_font_get_leading (sansbig); + + texty += grub_font_get_ascent(sans); + grub_font_draw_string (str, sans, color, 16, texty); + texty += grub_font_get_descent (sans) + grub_font_get_leading (sans); + + texty += grub_font_get_ascent(sanssmall); + grub_font_draw_string (str, sanssmall, color, 16, texty); + texty += (grub_font_get_descent (sanssmall) + + grub_font_get_leading (sanssmall)); + + glyph = grub_font_get_glyph (fixed, '*'); for (i = 0; i < 16; i++) { color = grub_video_map_color (i); palette[i] = color; - grub_video_blit_glyph (&glyph, color, 16 + i * 16, 32); + grub_font_draw_glyph (glyph, color, 16 + i * 16, 220); } grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); === modified file 'conf/common.rmk' --- conf/common.rmk 2008-09-29 13:57:05 +0000 +++ conf/common.rmk 2008-10-30 18:24:32 +0000 @@ -364,7 +364,7 @@ help_mod_LDFLAGS = $(COMMON_LDFLAGS) # For font.mod. -font_mod_SOURCES = font/manager.c +font_mod_SOURCES = font/font_cmd.c font/font.c font_mod_CFLAGS = $(COMMON_CFLAGS) font_mod_LDFLAGS = $(COMMON_LDFLAGS) === added file 'font/font.c' --- font/font.c 1970-01-01 00:00:00 +0000 +++ font/font.c 2008-10-30 18:24:32 +0000 @@ -0,0 +1,971 @@ +/* font.c - Font API and font file loader. */ +/* + * GRUB -- GRand Unified Bootloader + * Copyright (C) 2003,2005,2006,2007,2008 Free Software Foundation, Inc. + * + * GRUB is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * GRUB is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with GRUB. If not, see . + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#ifndef FONT_DEBUG +#define FONT_DEBUG 0 +#endif + +struct char_index_entry +{ + grub_uint32_t code; + grub_uint8_t storage_flags; + grub_uint32_t offset; + struct grub_font_glyph *glyph; /* Glyph if loaded, or null. */ +}; + +#define FONT_WEIGHT_NORMAL 100 +#define FONT_WEIGHT_BOLD 200 + +struct grub_font +{ + char *name; + grub_file_t file; + char *family; + short point_size; + short weight; + short max_char_width; + short max_char_height; + short ascent; + short descent; + short leading; + grub_uint32_t num_chars; + struct char_index_entry *char_index; +}; + + +/*============================================================*/ +/* Font loader */ + + +/* Definition of font registry. */ +struct font_node *grub_font_list; + +static int register_font (grub_font_t font); +static void free_font (grub_font_t font); +static void remove_font (grub_font_t font); + +struct font_file_section +{ + grub_file_t file; /* The file this section is in. */ + char name[4]; /* FOURCC name of the section. */ + grub_uint32_t length; /* Length of the section contents. */ + int eof; /* Set by open_section() on EOF. */ +}; + +/* Font file format constants. */ +static const char pff2_magic[4] = { 'P', 'F', 'F', '2' }; +static const char section_names_file[4] = { 'F', 'I', 'L', 'E' }; +static const char section_names_font_name[4] = { 'N', 'A', 'M', 'E' }; +static const char section_names_point_size[4] = { 'P', 'T', 'S', 'Z' }; +static const char section_names_weight[4] = { 'W', 'E', 'I', 'G' }; +static const char section_names_max_char_width[4] = { 'M', 'A', 'X', 'W' }; +static const char section_names_max_char_height[4] = { 'M', 'A', 'X', 'H' }; +static const char section_names_ascent[4] = { 'A', 'S', 'C', 'E' }; +static const char section_names_descent[4] = { 'D', 'E', 'S', 'C' }; +static const char section_names_char_index[4] = { 'C', 'H', 'I', 'X' }; +static const char section_names_data[4] = { 'D', 'A', 'T', 'A' }; + +/* Replace unknown glyphs with a rounded question mark. */ +static grub_uint8_t unknown_glyph_bitmap[] = +{ + /* 76543210 */ + 0x7C, /* ooooo */ + 0x82, /* o o */ + 0xBA, /* o ooo o */ + 0xAA, /* o o o o */ + 0xAA, /* o o o o */ + 0x8A, /* o o o */ + 0x9A, /* o oo o */ + 0x92, /* o o o */ + 0x92, /* o o o */ + 0x92, /* o o o */ + 0x92, /* o o o */ + 0x82, /* o o */ + 0x92, /* o o o */ + 0x82, /* o o */ + 0x7C, /* ooooo */ + 0x00 /* */ +}; + +static struct grub_font_glyph *unknown_glyph; +static grub_uint8_t font_loader_initialized; + +void +grub_font_loader_init (void) +{ + if (font_loader_initialized) + return; /* Only initialize font loader once. */ + + unknown_glyph = grub_malloc(sizeof(struct grub_font_glyph) + + sizeof(unknown_glyph_bitmap)); + if (! unknown_glyph) + return; + + unknown_glyph->width = 8; + unknown_glyph->height = 16; + unknown_glyph->offset_x = 0; + unknown_glyph->offset_y = 0; + unknown_glyph->device_width = 8; + grub_memcpy(unknown_glyph->bitmap, + unknown_glyph_bitmap, sizeof(unknown_glyph_bitmap)); + + font_loader_initialized = 1; +} + +/* Open the next section in the file. + + On success, the section name is stored in section->name and the length in + section->length, and 0 is returned. On failure, 1 is returned and + grub_errno is set approriately with an error message. + + If 1 is returned due to being at the end of the file, then section->eof is + set to 1; otherwise, section->eof is set to 0. */ +static int +open_section (grub_file_t file, struct font_file_section *section) +{ + grub_ssize_t retval; + grub_uint32_t raw_length; + + section->file = file; + section->eof = 0; + + /* Read the FOURCC section name. */ + retval = grub_file_read (file, section->name, 4); + if (retval >= 0 && retval < 4) + { + section->eof = 1; + return 1; /* EOF encountered. */ + } + else if (retval < 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font format error: can't read section name"); + return 1; /* Read error. */ + } + + /* Read the big-endian 32-bit section length. */ + retval = grub_file_read (file, (char *) &raw_length, 4); + if (retval >= 0 && retval < 4) + { + section->eof = 1; + return 1; /* EOF encountered. */ + } + else if (retval < 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font format error: can't read section length"); + return 1; /* Read error. */ + } + + /* Convert byte-order and store in *length. */ + section->length = grub_be_to_cpu32 (raw_length); + + return 0; +} + +/* Size in bytes of each character index (CHIX section) + entry in the font file. */ +#define FONT_CHAR_INDEX_ENTRY_SIZE (4 + 1 + 4) + +/* Load the character index (CHIX) section contents from the font file. This + presumes that the position of FILE is positioned immediately after the + section length for the CHIX section (i.e., at the start of the section + contents). Returns 0 upon success, nonzero for failure (in which case + grub_errno is set appropriately). */ +static int +load_font_index (grub_file_t file, grub_uint32_t sect_length, struct + grub_font *font) +{ + unsigned i; + +#if FONT_DEBUG >= 2 + grub_printf("load_font_index(sect_length=%d)\n", sect_length); +#endif + + /* Sanity check: ensure section length is divisible by the entry size. */ + if (sect_length % FONT_CHAR_INDEX_ENTRY_SIZE != 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font file format error: character index length %d " + "is not a multiple of the entry size %d", + sect_length, FONT_CHAR_INDEX_ENTRY_SIZE); + return 1; /* Invalid index section length. */ + } + + /* Calculate the number of characters. */ + font->num_chars = sect_length / FONT_CHAR_INDEX_ENTRY_SIZE; + + /* Allocate the character index array. */ + font->char_index = grub_malloc (font->num_chars + * sizeof (struct char_index_entry)); + if (!font->char_index) + return 1; /* Error allocating memory. */ + +#if FONT_DEBUG >= 2 + grub_printf("num_chars=%d)\n", font->num_chars); +#endif + + /* Load the character index data from the file. */ + for (i = 0; i < font->num_chars; i++) + { + struct char_index_entry *entry = &font->char_index[i]; + + /* Read code point value; convert to native byte order. */ + if (grub_file_read (file, (char *) &entry->code, 4) != 4) + return 1; + entry->code = grub_be_to_cpu32 (entry->code); + + /* Read storage flags byte. */ + if (grub_file_read (file, (char *) &entry->storage_flags, 1) != 1) + return 1; + + /* Read glyph data offset; convert to native byte order. */ + if (grub_file_read (file, (char *) &entry->offset, 4) != 4) + return 1; + entry->offset = grub_be_to_cpu32 (entry->offset); + + /* No glyph loaded. Will be loaded on demand and cached thereafter. */ + entry->glyph = 0; + +#if FONT_DEBUG >= 5 + if (i < 10) /* Print the 1st 10 characters. */ + grub_printf("c=%d o=%d\n", entry->code, entry->offset); +#endif + } + + return 0; /* Index loaded OK. */ +} + +/* Read the contents of the specified section as a string, which is + allocated on the heap. Returns 0 if there is an error. */ +static char * +read_section_as_string (struct font_file_section *section) +{ + char *str; + grub_ssize_t ret; + + str = grub_malloc (section->length + 1); + if (!str) + return 0; + + ret = grub_file_read (section->file, str, section->length); + if (ret < 0 || ret != (grub_ssize_t) section->length) + { + grub_free (str); + return 0; + } + + str[section->length] = '\0'; + return str; +} + +/* Read the contents of the current section as a 16-bit integer value, + which is stored into *VALUE. + Returns 0 upon success, nonzero upon failure. */ +static int +read_section_as_short (struct font_file_section *section, grub_int16_t *value) +{ + grub_uint16_t raw_value; + + if (section->length != 2) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font file format error: section %c%c%c%c length " + "is %d but should be 2", + section->name[0], section->name[1], + section->name[2], section->name[3], + section->length); + return 1; /* An error occurred. */ + } + if (grub_file_read (section->file, (char *) &raw_value, 2) != 2) + return 1; /* An error occurred. */ + + *value = grub_be_to_cpu16 (raw_value); + return 0; /* Successfully read the value. */ +} + +/* Load a font and add it to the beginning of the global font list. + Returns 0 upon success, nonzero upon failure. */ +int +grub_font_load (const char *filename) +{ + grub_file_t file = 0; + struct font_file_section section; + char magic[4]; + grub_font_t font = 0; + +#if FONT_DEBUG >= 1 + grub_printf("add_font(%s)\n", filename); +#endif + + file = grub_buffile_open (filename, 1024); + if (!file) + goto fail; + +#if FONT_DEBUG >= 3 + grub_printf("file opened\n"); +#endif + + /* Read the FILE section. It indicates the file format. */ + if (open_section (file, §ion) != 0) + goto fail; + +#if FONT_DEBUG >= 3 + grub_printf("opened FILE section\n"); +#endif + if (grub_memcmp (section.name, section_names_file, 4) != 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font file format error: 1st section must be FILE"); + goto fail; + } + +#if FONT_DEBUG >= 3 + grub_printf("section name ok\n"); +#endif + if (section.length != 4) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font file format error (file type ID length is %d " + "but should be 4)", section.length); + goto fail; + } + +#if FONT_DEBUG >= 3 + grub_printf("section length ok\n"); +#endif + /* Check the file format type code. */ + if (grub_file_read (file, magic, 4) != 4) + goto fail; + +#if FONT_DEBUG >= 3 + grub_printf("read magic ok\n"); +#endif + + if (grub_memcmp (magic, pff2_magic, 4) != 0) + { + grub_error (GRUB_ERR_BAD_FONT, "Invalid font magic %x %x %x %x", + magic[0], magic[1], magic[2], magic[3]); + goto fail; + } + +#if FONT_DEBUG >= 3 + grub_printf("compare magic ok\n"); +#endif + + /* Allocate the font object. */ + font = (grub_font_t) grub_malloc (sizeof (struct grub_font)); + if (!font) + goto fail; + + font->name = 0; + font->file = file; + font->family = 0; + font->point_size = 0; + font->weight = 0; + font->leading = 1; /* Default leading value, not in font file yet. */ + font->max_char_width = 0; + font->max_char_height = 0; + font->ascent = 0; + font->descent = 0; + font->num_chars = 0; + font->char_index = 0; + +#if FONT_DEBUG >= 3 + grub_printf("allocate font ok; loading font info\n"); +#endif + + /* Load the font information. */ + while (1) + { + if (open_section (file, §ion) != 0) + { + if (section.eof) + break; /* Done reading the font file. */ + else + goto fail; + } + +#if FONT_DEBUG >= 2 + grub_printf("opened section %c%c%c%c ok\n", + section.name[0], section.name[1], + section.name[2], section.name[3]); +#endif + + if (grub_memcmp (section.name, section_names_font_name, 4) == 0) + { + font->name = read_section_as_string (§ion); + if (!font->name) + goto fail; + } + else if (grub_memcmp (section.name, section_names_point_size, 4) == 0) + { + if (read_section_as_short (§ion, &font->point_size) != 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_weight, 4) == 0) + { + char *wt; + wt = read_section_as_string (§ion); + if (!wt) + continue; + /* Convert the weight string 'normal' or 'bold' into a number. */ + if (grub_strcmp (wt, "normal") == 0) + font->weight = FONT_WEIGHT_NORMAL; + else if (grub_strcmp (wt, "bold") == 0) + font->weight = FONT_WEIGHT_BOLD; + grub_free (wt); + } + else if (grub_memcmp (section.name, section_names_max_char_width, 4) == 0) + { + if (read_section_as_short (§ion, &font->max_char_width) != 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_max_char_height, 4) == 0) + { + if (read_section_as_short (§ion, &font->max_char_height) != 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_ascent, 4) == 0) + { + if (read_section_as_short (§ion, &font->ascent) != 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_descent, 4) == 0) + { + if (read_section_as_short (§ion, &font->descent) != 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_char_index, 4) == 0) + { + /* Load the font index. */ + if (load_font_index (file, section.length, font) != 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_data, 4) == 0) + { + /* When the DATA section marker is reached, we stop reading. */ + break; + } + else + { + /* Unhandled section type, simply skip past it. */ +#if FONT_DEBUG >= 3 + grub_printf("Unhandled section type, skipping.\n"); +#endif + grub_off_t section_end = grub_file_tell (file) + section.length; + if ((int) grub_file_seek (file, section_end) == -1) + goto fail; + } + } + + if (!font->name) + { + grub_printf ("Note: Font has no name.\n"); + font->name = grub_strdup ("Unknown"); + } + +#if FONT_DEBUG >= 1 + grub_printf ("Loaded font `%s'.\n" + "Ascent=%d Descent=%d MaxW=%d MaxH=%d Number of characters=%d.\n", + font->name, + font->ascent, font->descent, + font->max_char_width, font->max_char_height, + font->num_chars); +#endif + + if (font->max_char_width == 0 + || font->max_char_height == 0 + || font->num_chars == 0 + || font->char_index == 0 + || font->ascent == 0 + || font->descent == 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Invalid font file: missing some required data."); + goto fail; + } + + /* Add the font to the global font registry. */ + if (register_font (font) != 0) + goto fail; + + return 0; /* Font loaded ok. */ + +fail: + free_font (font); + return 1; /* Failed to load font. */ +} + +/* Read a 16-bit big-endian integer from FILE, convert it to native byte + order, and store it in *VALUE. + Returns 0 on success, 1 on failure. */ +static int +read_be_uint16 (grub_file_t file, grub_uint16_t * value) +{ + if (grub_file_read (file, (char *) value, 2) != 2) + return 1; + *value = grub_be_to_cpu16 (*value); + return 0; +} + +static int +read_be_int16 (grub_file_t file, grub_int16_t * value) +{ + /* For the signed integer version, use the same code as for unsigned. */ + return read_be_uint16 (file, (grub_uint16_t *) value); +} + +/* Return a pointer to the character index entry for the glyph corresponding to + the codepoint CODE in the font FONT. If not found, return zero. */ +static struct char_index_entry * +find_glyph (const grub_font_t font, grub_uint32_t code) +{ + grub_uint32_t i; + grub_uint32_t len = font->num_chars; + struct char_index_entry *table = font->char_index; + + /* Do a linear search. */ + for (i = 0; i < len; i++) + { + if (table[i].code == code) + return &table[i]; + } + + return 0; /* No entry found for code point CODE. */ +} + +static struct grub_font_glyph * +grub_font_get_glyph_internal (grub_font_t font, grub_uint32_t code) +{ + struct char_index_entry *index_entry; + + index_entry = find_glyph (font, code); + if (index_entry) + { + struct grub_font_glyph *glyph = 0; + grub_uint16_t width; + grub_uint16_t height; + grub_int16_t xoff; + grub_int16_t yoff; + grub_int16_t dwidth; + int len; + + if (index_entry->glyph) + return index_entry->glyph; /* Return cached glyph. */ + + /* Make sure we can find glyphs for error messages. Push active + error message to error stack and reset error message. */ + grub_error_push (); + + grub_file_seek (font->file, index_entry->offset); + + /* Read the glyph width, height, and baseline. */ + if (read_be_uint16(font->file, &width) != 0 + || read_be_uint16(font->file, &height) != 0 + || read_be_int16(font->file, &xoff) != 0 + || read_be_int16(font->file, &yoff) != 0 + || read_be_int16(font->file, &dwidth) != 0) + { + remove_font (font); + return 0; + } + + len = (width * height + 7) / 8; + glyph = grub_malloc (sizeof (struct grub_font_glyph) + len); + if (! glyph) + { + remove_font (font); + return 0; + } + + glyph->font = font; + glyph->width = width; + glyph->height = height; + glyph->offset_x = xoff; + glyph->offset_y = yoff; + glyph->device_width = dwidth; + + /* Don't try to read empty bitmaps (e.g., space characters). */ + if (len != 0) + { + if (grub_file_read (font->file, (char *) glyph->bitmap, len) != len) + { + remove_font (font); + return 0; + } + } + + /* Restore old error message. */ + grub_error_pop (); + + /* Cache the glyph. */ + index_entry->glyph = glyph; + + return glyph; /* Glyph loaded ok. */ + } + + return 0; +} + +/* Free the memory used by FONT. + This should not be called if the font has been made available to + users (once it is added to the global font list), since there would + be the possibility of a dangling pointer. */ +static void +free_font (grub_font_t font) +{ + if (font) + { + if (font->file) + grub_file_close (font->file); + grub_free (font->name); + grub_free (font->family); + grub_free (font->char_index); + grub_free (font); + } +} + +/* Add FONT to the global font registry. + Returns 0 upon success, nonzero on failure + (the font was not registered). */ +static int +register_font (grub_font_t font) +{ + struct font_node *node = 0; + + node = grub_malloc (sizeof (struct font_node)); + if (!node) + return 1; /* Error. */ + + node->value = font; + node->next = grub_font_list; + grub_font_list = node; + + return 0; /* Success. */ +} + +/* Remove the font from the global font list. We don't actually free the + font's memory since users could be holding references to the font. */ +static void +remove_font (grub_font_t font) +{ + struct font_node **nextp, *cur; + + for (nextp = &grub_font_list, cur = *nextp; + cur; + nextp = &cur->next, cur = cur->next) + { + if (cur->value == font) + { + *nextp = cur->next; + + /* Free the node, but not the font itself. */ + grub_free (cur); + + return; + } + } +} + + +/*============================================================*/ +/* Public font API */ + +/* Get a font from the list of loaded fonts. This function will return + another font if the requested font is not available. */ +grub_font_t +grub_font_get (const char *font_name) +{ + struct font_node *node; + + for (node = grub_font_list; node; node = node->next) + { + grub_font_t font = node->value; + if (grub_strcmp (font->name, font_name) == 0) + return font; + } + + /* If no font by that name is found, return the first font in the list + as a fallback. */ + return grub_font_list->value; +} + +/* Get the full name of the font. For instance, "Helvetica Bold 12". */ +const char * +grub_font_get_name (grub_font_t font) +{ + return font->name; +} + +/* Get the maximum width of any character in the font in pixels. */ +int +grub_font_get_max_char_width (grub_font_t font) +{ + return font->max_char_width; +} + +/* Get the maximum height of any character in the font in pixels. */ +int +grub_font_get_max_char_height (grub_font_t font) +{ + return font->max_char_height; +} + +/* Get the distance in pixels from the top of characters to the baseline. */ +int +grub_font_get_ascent (grub_font_t font) +{ + return font->ascent; +} + +/* Get the distance in pixels from the baseline to the lowest descenders + (for instance, in a lowercase 'y', 'g', etc.). */ +int +grub_font_get_descent (grub_font_t font) +{ + return font->descent; +} + +/* Get the *standard leading* of the font in pixel, which is the spacing + between two lines of text. Specifically, it is the space between the + descent of one line and the ascent of the next line. This is included + in the *height* metric. */ +int +grub_font_get_leading (grub_font_t font) +{ + return font->leading; +} + +/* Get the distance in pixels between baselines of adjacent lines of text. */ +int +grub_font_get_height (grub_font_t font) +{ + return font->ascent + font->descent + font->leading; +} + +/* Get the width in pixels of the specified UTF-8 string, when rendered in + in the specified font (but falling back on other fonts for glyphs that + are missing). */ +int +grub_font_get_string_width (grub_font_t font, const char *str) +{ + int width; + struct grub_font_glyph *glyph; + grub_uint32_t code; + const grub_uint8_t *ptr; + + for (ptr = (const grub_uint8_t *) str, width = 0; + grub_utf8_to_ucs4 (&code, 1, ptr, -1, &ptr) > 0; ) + { + glyph = grub_font_get_glyph_with_fallback (font, code); + width += glyph->device_width; + } + + return width; +} + +/* Get the glyph for FONT corresponding to the Unicode code point CODE. + Returns a pointer to an glyph indicating there is no glyph available + if CODE does not exist in the font. The glyphs are cached once loaded. */ +struct grub_font_glyph * +grub_font_get_glyph (grub_font_t font, grub_uint32_t code) +{ + struct grub_font_glyph *glyph; + glyph = grub_font_get_glyph_internal (font, code); + if (glyph == 0) + glyph = unknown_glyph; + return glyph; +} + + +/* Calculate a subject value representing "how similar" two fonts are. + This is used to prioritize the order that fonts are scanned for missing + glyphs. The object is to select glyphs from the most similar font + possible, for the best appearance. + The heuristic is crude, but it helps greatly when fonts of similar + sizes are used so that tiny 8 point glyphs are not mixed into a string + of 24 point text unless there is no other choice. */ +static int +get_font_diversity(grub_font_t a, grub_font_t b) +{ + int d; + + d = 0; + + if (a->ascent && b->ascent) + d += grub_abs (a->ascent - b->ascent) * 8; + else + d += 50; /* Penalty for missing attributes. */ + + if (a->max_char_height && b->max_char_height) + d += grub_abs (a->max_char_height - b->max_char_height) * 8; + else + d += 50; /* Penalty for missing attributes. */ + + d += (a->weight != b->weight) ? 5 : 0; /* Weight is a minor factor. */ + + return d; +} + +/* Get a glyph corresponding to the codepoint CODE. If FONT contains the + specified glyph, then it is returned. Otherwise, all other loaded fonts + are searched until one is found that contains a glyph for CODE. + If no glyph is available for CODE in the loaded fonts, then a glyph + representing an unknown character is returned. + This function never returns NULL. + The returned glyph is owned by the font manager and should not be freed + by the caller. The glyphs are cached. */ +struct grub_font_glyph * +grub_font_get_glyph_with_fallback (grub_font_t font, grub_uint32_t code) +{ + struct grub_font_glyph *glyph; + struct font_node *node; + /* Keep track of next node, in case there's an I/O error in + grub_font_get_glyph_internal() and the font is removed from the list. */ + struct font_node *next; + /* Information on the best glyph found so far, to help find the glyph in + the best matching to the requested one. */ + int best_diversity; + struct grub_font_glyph *best_glyph; + + if (font) + { + /* First try to get the glyph from the specified font. */ + glyph = grub_font_get_glyph_internal (font, code); + if (glyph) + return glyph; + } + + /* Otherwise, search all loaded fonts for the glyph and use the one from + the font that best matches the requested font. */ + best_diversity = 10000; + best_glyph = 0; + + for (node = grub_font_list; node; node = next) + { + grub_font_t curfont; + + curfont = node->value; + next = node->next; + + glyph = grub_font_get_glyph_internal (curfont, code); + if (glyph) + { + int d; + + d = get_font_diversity (curfont, font); + if (d < best_diversity) + { + best_diversity = d; + best_glyph = glyph; + } + } + } + + if (best_glyph) + return best_glyph; + else + return unknown_glyph; /* Ugh... Glyph not available in any font. */ +} + + +/* Draw the specified glyph at (x, y). The y coordinate designates the + baseline of the character, while the x coordinate designates the left + side location of the character. */ +grub_err_t +grub_font_draw_glyph (struct grub_font_glyph *glyph, + grub_video_color_t color, + int left_x, int baseline_y) +{ + struct grub_video_bitmap glyph_bitmap; + + /* Don't try to draw empty glyphs (U+0020, etc.). */ + if (glyph->width == 0 || glyph->height == 0) + return GRUB_ERR_NONE; + + glyph_bitmap.mode_info.width = glyph->width; + glyph_bitmap.mode_info.height = glyph->height; + glyph_bitmap.mode_info.mode_type = + (1 << GRUB_VIDEO_MODE_TYPE_DEPTH_POS) + | GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP; + glyph_bitmap.mode_info.blit_format = GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED; + glyph_bitmap.mode_info.bpp = 1; + glyph_bitmap.mode_info.bytes_per_pixel = 0; /* Really 1 bit per pixel. */ + glyph_bitmap.mode_info.pitch = glyph->width; /* Packed densely as bits. */ + glyph_bitmap.mode_info.number_of_colors = 2; + glyph_bitmap.mode_info.bg_red = 0; + glyph_bitmap.mode_info.bg_green = 0; + glyph_bitmap.mode_info.bg_blue = 0; + glyph_bitmap.mode_info.bg_alpha = 0; + grub_video_unmap_color(color, + &glyph_bitmap.mode_info.fg_red, + &glyph_bitmap.mode_info.fg_green, + &glyph_bitmap.mode_info.fg_blue, + &glyph_bitmap.mode_info.fg_alpha); + glyph_bitmap.data = glyph->bitmap; + + int bitmap_left = left_x + glyph->offset_x; + int bitmap_bottom = baseline_y - glyph->offset_y; + int bitmap_top = bitmap_bottom - glyph->height; + + return grub_video_blit_bitmap (&glyph_bitmap, GRUB_VIDEO_BLIT_BLEND, + bitmap_left, bitmap_top, + 0, 0, + glyph->width, glyph->height); +} + +/* Draw a UTF-8 string of text on the current video render target. + The x coordinate specifies the starting x position for the first character, + while the y coordinate specifies the baseline position. + If the string contains a character that FONT does not contain, then + a glyph from another loaded font may be used instead. */ +grub_err_t +grub_font_draw_string (const char *str, grub_font_t font, + grub_video_color_t color, + int left_x, int baseline_y) +{ + int x; + struct grub_font_glyph *glyph; + grub_uint32_t code; + const grub_uint8_t *ptr; + + for (ptr = (const grub_uint8_t *) str, x = left_x; + grub_utf8_to_ucs4 (&code, 1, ptr, -1, &ptr) > 0; ) + { + glyph = grub_font_get_glyph_with_fallback (font, code); + if (grub_font_draw_glyph (glyph, color, x, baseline_y) + != GRUB_ERR_NONE) + return grub_errno; + x += glyph->device_width; + } + + return GRUB_ERR_NONE; +} + === added file 'font/font_cmd.c' --- font/font_cmd.c 1970-01-01 00:00:00 +0000 +++ font/font_cmd.c 2008-10-30 18:24:32 +0000 @@ -0,0 +1,77 @@ +/* font_cmd.c - Font command definition. */ +/* + * GRUB -- GRand Unified Bootloader + * Copyright (C) 2003,2005,2006,2007,2008 Free Software Foundation, Inc. + * + * GRUB is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * GRUB is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with GRUB. If not, see . + */ + +#include +#include +#include +#include + +static grub_err_t +loadfont_command (struct grub_arg_list *state __attribute__ ((unused)), + int argc, + char **args) +{ + if (argc == 0) + return grub_error (GRUB_ERR_BAD_ARGUMENT, "no font specified"); + + while (argc--) + if (grub_font_load (*args++) != 0) + return GRUB_ERR_BAD_FONT; + + return GRUB_ERR_NONE; +} + +static grub_err_t +lsfonts_command (struct grub_arg_list *state __attribute__ ((unused)), + int argc __attribute__ ((unused)), + char **args __attribute__ ((unused))) +{ + struct font_node *node; + + grub_printf ("Loaded fonts:\n"); + for (node = grub_font_list; node; node = node->next) + { + grub_font_t font = node->value; + grub_printf ("%s\n", grub_font_get_name (font)); + } + + return GRUB_ERR_NONE; +} + +GRUB_MOD_INIT(font_manager) +{ + grub_font_loader_init (); + + grub_register_command ("loadfont", loadfont_command, GRUB_COMMAND_FLAG_BOTH, + "loadfont FILE...", + "Specify one or more font files to load.", 0); + + grub_register_command ("lsfonts", lsfonts_command, GRUB_COMMAND_FLAG_BOTH, + "lsfonts", + "List the loaded fonts.", 0); +} + +GRUB_MOD_FINI(font_manager) +{ + /* Should this free fonts, unknown_glyph, etc.? Freeing fonts could + be a Bad Thing if there are still references to any of them. */ + + grub_unregister_command ("loadfont"); +} + === removed file 'font/manager.c' --- font/manager.c 2008-08-01 03:06:55 +0000 +++ font/manager.c 1970-01-01 00:00:00 +0000 @@ -1,283 +0,0 @@ -/* - * GRUB -- GRand Unified Bootloader - * Copyright (C) 2003,2005,2006,2007 Free Software Foundation, Inc. - * - * GRUB is free software: you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation, either version 3 of the License, or - * (at your option) any later version. - * - * GRUB is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with GRUB. If not, see . - */ - -#include -#include -#include -#include -#include -#include -#include -#include - -struct entry -{ - grub_uint32_t code; - grub_uint32_t offset; -}; - -struct font -{ - struct font *next; - grub_file_t file; - grub_uint32_t num; - struct entry table[0]; -}; - -static struct font *font_list; - -/* Fill unknown glyph's with rounded question mark. */ -static grub_uint8_t unknown_glyph[16] = -{ /* 76543210 */ - 0x7C, /* ooooo */ - 0x82, /* o o */ - 0xBA, /* o ooo o */ - 0xAA, /* o o o o */ - 0xAA, /* o o o o */ - 0x8A, /* o o o */ - 0x9A, /* o oo o */ - 0x92, /* o o o */ - 0x92, /* o o o */ - 0x92, /* o o o */ - 0x92, /* o o o */ - 0x82, /* o o */ - 0x92, /* o o o */ - 0x82, /* o o */ - 0x7C, /* ooooo */ - 0x00 /* */ -}; - -static int -add_font (const char *filename) -{ - grub_file_t file = 0; - char magic[4]; - grub_uint32_t num, i; - struct font *font = 0; - - file = grub_buffile_open (filename, 0); - if (! file) - goto fail; - - if (grub_file_read (file, magic, 4) != 4) - goto fail; - - if (grub_memcmp (magic, GRUB_FONT_MAGIC, 4) != 0) - { - grub_error (GRUB_ERR_BAD_FONT, "invalid font magic"); - goto fail; - } - - if (grub_file_read (file, (char *) &num, 4) != 4) - goto fail; - - num = grub_le_to_cpu32 (num); - font = (struct font *) grub_malloc (sizeof (struct font) - + sizeof (struct entry) * num); - if (! font) - goto fail; - - font->file = file; - font->num = num; - - for (i = 0; i < num; i++) - { - grub_uint32_t code, offset; - - if (grub_file_read (file, (char *) &code, 4) != 4) - goto fail; - - if (grub_file_read (file, (char *) &offset, 4) != 4) - goto fail; - - font->table[i].code = grub_le_to_cpu32 (code); - font->table[i].offset = grub_le_to_cpu32 (offset); - } - - font->next = font_list; - font_list = font; - - return 1; - - fail: - if (font) - grub_free (font); - - if (file) - grub_file_close (file); - - return 0; -} - -static void -remove_font (struct font *font) -{ - struct font **p, *q; - - for (p = &font_list, q = *p; q; p = &(q->next), q = q->next) - if (q == font) - { - *p = q->next; - - grub_file_close (font->file); - grub_free (font); - - break; - } -} - -/* Return the offset of the glyph corresponding to the codepoint CODE - in the font FONT. If no found, return zero. */ -static grub_uint32_t -find_glyph (const struct font *font, grub_uint32_t code) -{ - grub_uint32_t start = 0; - grub_uint32_t end = font->num - 1; - const struct entry *table = font->table; - - /* This shouldn't happen. */ - if (font->num == 0) - return 0; - - /* Do a binary search. */ - while (start <= end) - { - grub_uint32_t i = (start + end) / 2; - - if (table[i].code < code) - start = i + 1; - else if (table[i].code > code) - end = i - 1; - else - return table[i].offset; - } - - return 0; -} - -/* Set the glyph to something stupid. */ -static void -fill_with_default_glyph (grub_font_glyph_t glyph) -{ - unsigned i; - - /* Use pre-defined pattern to fill unknown glyphs. */ - for (i = 0; i < 16; i++) - glyph->bitmap[i] = unknown_glyph[i]; - - glyph->char_width = 1; - glyph->width = glyph->char_width * 8; - glyph->height = 16; - glyph->baseline = (16 * 3) / 4; -} - -/* Get a glyph corresponding to the codepoint CODE. Always fill glyph - information with something, even if no glyph is found. */ -int -grub_font_get_glyph (grub_uint32_t code, - grub_font_glyph_t glyph) -{ - struct font *font; - grub_uint8_t bitmap[32]; - - /* FIXME: It is necessary to cache glyphs! */ - - restart: - for (font = font_list; font; font = font->next) - { - grub_uint32_t offset; - - offset = find_glyph (font, code); - if (offset) - { - grub_uint32_t w; - int len; - - /* Make sure we can find glyphs for error messages. Push active - error message to error stack and reset error message. */ - grub_error_push (); - - grub_file_seek (font->file, offset); - if ((len = grub_file_read (font->file, (char *) &w, sizeof (w))) - != sizeof (w)) - { - remove_font (font); - goto restart; - } - - w = grub_le_to_cpu32 (w); - if (w != 1 && w != 2) - { - /* grub_error (GRUB_ERR_BAD_FONT, "invalid width"); */ - remove_font (font); - goto restart; - } - - if (grub_file_read (font->file, (char *) bitmap, w * 16) - != (grub_ssize_t) w * 16) - { - remove_font (font); - goto restart; - } - - /* Fill glyph with information. */ - grub_memcpy (glyph->bitmap, bitmap, w * 16); - - glyph->char_width = w; - glyph->width = glyph->char_width * 8; - glyph->height = 16; - glyph->baseline = (16 * 3) / 4; - - /* Restore old error message. */ - grub_error_pop (); - - return 1; - } - } - - /* Uggh... No font was found. */ - fill_with_default_glyph (glyph); - return 0; -} - -static grub_err_t -font_command (struct grub_arg_list *state __attribute__ ((unused)), - int argc __attribute__ ((unused)), - char **args __attribute__ ((unused))) -{ - if (argc == 0) - return grub_error (GRUB_ERR_BAD_ARGUMENT, "no font specified"); - - while (argc--) - if (! add_font (*args++)) - return 1; - - return 0; -} - -GRUB_MOD_INIT(font_manager) -{ - grub_register_command ("font", font_command, GRUB_COMMAND_FLAG_BOTH, - "font FILE...", - "Specify one or more font files to display.", 0); -} - -GRUB_MOD_FINI(font_manager) -{ - grub_unregister_command ("font"); -} === modified file 'include/grub/font.h' --- include/grub/font.h 2007-07-21 22:32:33 +0000 +++ include/grub/font.h 2008-10-30 18:24:32 +0000 @@ -1,6 +1,6 @@ /* * GRUB -- GRand Unified Bootloader - * Copyright (C) 2003,2007 Free Software Foundation, Inc. + * Copyright (C) 2003,2007,2008 Free Software Foundation, Inc. * * GRUB is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -20,34 +20,96 @@ #define GRUB_FONT_HEADER 1 #include - -#define GRUB_FONT_MAGIC "PPF\x7f" +#include + +/* Forward declaration of opaque structure grub_font. + Users only pass struct grub_font pointers to the font module functions, + and do not have knowledge of the structure contents. */ +struct grub_font; + +/* Font type used to access font functions. */ +typedef struct grub_font *grub_font_t; + +struct font_node +{ + struct font_node *next; + grub_font_t value; +}; + +/* Global font registry. */ +extern struct font_node *grub_font_list; struct grub_font_glyph { - /* Glyph width in pixels. */ - grub_uint8_t width; - - /* Glyph height in pixels. */ - grub_uint8_t height; - - /* Glyph width in characters. */ - grub_uint8_t char_width; - - /* Glyph baseline position in pixels (from up). */ - grub_uint8_t baseline; - - /* Glyph bitmap data array of bytes in ((width + 7) / 8) * height. - Bitmap is formulated by height scanlines, each scanline having - width number of pixels. Pixels are coded as bits, value 1 meaning - of opaque pixel and 0 is transparent. If width does not fit byte - boundary, it will be padded with 0 to make it fit. */ - grub_uint8_t bitmap[32]; + /* Reference to the font this glyph belongs to. */ + grub_font_t font; + + /* Glyph bitmap width in pixels. */ + grub_uint16_t width; + + /* Glyph bitmap height in pixels. */ + grub_uint16_t height; + + /* Glyph bitmap x offset in pixels. Add to screen coordinate. */ + grub_int16_t offset_x; + + /* Glyph bitmap y offset in pixels. Subtract from screen coordinate. */ + grub_int16_t offset_y; + + /* Number of pixels to advance to start the next character. */ + grub_uint16_t device_width; + + /* Row-major order, packed bits (no padding; rows can break within a byte). + The length of the array is (width * height + 7) / 8. Within a + byte, the most significant bit is the first (leftmost/uppermost) pixel. + Pixels are coded as bits, value 1 meaning of opaque pixel and 0 is + transparent. If the length of the array does not fit byte boundary, it + will be padded with 0 bits to make it fit. */ + grub_uint8_t bitmap[0]; }; -typedef struct grub_font_glyph *grub_font_glyph_t; - -int grub_font_get_glyph (grub_uint32_t code, - grub_font_glyph_t glyph); +/* Initialize the font loader. + Must be called before any fonts are loaded or used. */ +void grub_font_loader_init (void); + +/* Load a font and add it to the beginning of the global font list. + Returns: 0 upon success; nonzero upon failure. */ +int grub_font_load (const char *filename); + +/* Get the font that has the specified name. Font names are in the form + "Family Name Bold Italic 14", where Bold and Italic are optional. + If no font matches the name specified, the most recently loaded font + is returned as a fallback. */ +grub_font_t grub_font_get (const char *font_name); + +const char *grub_font_get_name (grub_font_t font); + +int grub_font_get_max_char_width (grub_font_t font); + +int grub_font_get_max_char_height (grub_font_t font); + +int grub_font_get_ascent (grub_font_t font); + +int grub_font_get_descent (grub_font_t font); + +int grub_font_get_leading (grub_font_t font); + +int grub_font_get_height (grub_font_t font); + +int grub_font_get_string_width (grub_font_t font, const char *str); + +struct grub_font_glyph *grub_font_get_glyph (grub_font_t font, + grub_uint32_t code); + +struct grub_font_glyph *grub_font_get_glyph_with_fallback (grub_font_t font, + grub_uint32_t code); + +grub_err_t grub_font_draw_glyph (struct grub_font_glyph *glyph, + grub_video_color_t color, + int left_x, int baseline_y); + +grub_err_t grub_font_draw_string (const char *str, grub_font_t font, + grub_video_color_t color, + int left_x, int baseline_y); #endif /* ! GRUB_FONT_HEADER */ === modified file 'include/grub/misc.h' --- include/grub/misc.h 2008-09-19 05:55:20 +0000 +++ include/grub/misc.h 2008-10-30 18:24:32 +0000 @@ -77,8 +77,10 @@ grub_uint16_t *src, grub_size_t size); grub_ssize_t EXPORT_FUNC(grub_utf8_to_ucs4) (grub_uint32_t *dest, + grub_size_t destsize, const grub_uint8_t *src, - grub_size_t size); + grub_size_t srcsize, + const grub_uint8_t **srcend); grub_uint64_t EXPORT_FUNC(grub_divmod64) (grub_uint64_t n, grub_uint32_t d, grub_uint32_t *r); === modified file 'include/grub/video.h' --- include/grub/video.h 2008-10-05 04:28:39 +0000 +++ include/grub/video.h 2008-10-30 18:28:52 +0000 @@ -31,17 +31,17 @@ struct grub_video_render_target; /* Forward declarations for used data structures. */ -struct grub_font_glyph; struct grub_video_bitmap; /* Defines used to describe video mode or rendering target. */ -#define GRUB_VIDEO_MODE_TYPE_ALPHA 0x00000008 -#define GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED 0x00000004 +#define GRUB_VIDEO_MODE_TYPE_ALPHA 0x00000020 +#define GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED 0x00000010 +#define GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP 0x00000004 #define GRUB_VIDEO_MODE_TYPE_INDEX_COLOR 0x00000002 #define GRUB_VIDEO_MODE_TYPE_RGB 0x00000001 /* Defines used to mask flags. */ -#define GRUB_VIDEO_MODE_TYPE_COLOR_MASK 0x00000003 +#define GRUB_VIDEO_MODE_TYPE_COLOR_MASK 0x0000000F /* Defines used to specify requested bit depth. */ #define GRUB_VIDEO_MODE_TYPE_DEPTH_MASK 0x0000ff00 @@ -72,7 +72,9 @@ GRUB_VIDEO_BLIT_FORMAT_BGR_565, /* When needed, decode color or just use value as is. */ - GRUB_VIDEO_BLIT_FORMAT_INDEXCOLOR + GRUB_VIDEO_BLIT_FORMAT_INDEXCOLOR, + /* Two color bitmap; bits packed: rows are not padded to byte boundary. */ + GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED }; /* Define blitting operators. */ @@ -135,6 +137,18 @@ /* What is location of reserved color bits. In Index Color mode, this is 0. */ unsigned int reserved_field_pos; + + /* For 1-bit bitmaps, the background color. Used for bits = 0. */ + grub_uint8_t bg_red; + grub_uint8_t bg_green; + grub_uint8_t bg_blue; + grub_uint8_t bg_alpha; + + /* For 1-bit bitmaps, the foreground color. Used for bits = 1. */ + grub_uint8_t fg_red; + grub_uint8_t fg_green; + grub_uint8_t fg_blue; + grub_uint8_t fg_alpha; }; struct grub_video_palette_data @@ -188,9 +202,6 @@ grub_err_t (*fill_rect) (grub_video_color_t color, int x, int y, unsigned int width, unsigned int height); - grub_err_t (*blit_glyph) (struct grub_font_glyph *glyph, - grub_video_color_t color, int x, int y); - grub_err_t (*blit_bitmap) (struct grub_video_bitmap *bitmap, enum grub_video_blit_operators oper, int x, int y, int offset_x, int offset_y, @@ -260,9 +271,6 @@ grub_err_t grub_video_fill_rect (grub_video_color_t color, int x, int y, unsigned int width, unsigned int height); -grub_err_t grub_video_blit_glyph (struct grub_font_glyph *glyph, - grub_video_color_t color, int x, int y); - grub_err_t grub_video_blit_bitmap (struct grub_video_bitmap *bitmap, enum grub_video_blit_operators oper, int x, int y, int offset_x, int offset_y, === modified file 'kern/misc.c' --- kern/misc.c 2008-09-19 05:55:20 +0000 +++ kern/misc.c 2008-10-30 18:24:32 +0000 @@ -951,22 +951,29 @@ return dest; } -/* Convert an UTF-8 string to an UCS-4 string. Return the number of - characters converted. DEST must be able to hold at least SIZE - characters (when the input is unknown). If an invalid sequence is found, - return -1. */ +/* Convert a (possibly null-terminated) UTF-8 string of at most SRCSIZE + bytes (if SRCSIZE is -1, it is ignored) in length to a UCS-4 string. + Return the number of characters converted. DEST must be able to hold + at least DESTSIZE characters. If an invalid sequence is found, return -1. + If SRCEND is not NULL, then *SRCEND is set to the next byte after the + last byte used in SRC. */ grub_ssize_t -grub_utf8_to_ucs4 (grub_uint32_t *dest, const grub_uint8_t *src, - grub_size_t size) +grub_utf8_to_ucs4 (grub_uint32_t *dest, grub_size_t destsize, + const grub_uint8_t *src, grub_size_t srcsize, + const grub_uint8_t **srcend) { grub_uint32_t *p = dest; int count = 0; grub_uint32_t code = 0; - while (size--) + if (*srcend) + *srcend = src; + + while (srcsize && destsize) { grub_uint32_t c = *src++; - + if (srcsize != -1) + srcsize--; if (count) { if ((c & 0xc0) != 0x80) @@ -983,6 +990,8 @@ } else { + if (c == 0) + break; /* NUL character terminates the string. */ if ((c & 0x80) == 0x00) code = c; else if ((c & 0xe0) == 0xc0) @@ -1011,14 +1020,18 @@ code = c & 0x01; } else - /* invalid */ return -1; } if (count == 0) - *p++ = code; + { + *p++ = code; + destsize--; + } } + if (srcend) + *srcend = src; return p - dest; } === modified file 'kern/term.c' --- kern/term.c 2007-12-25 11:10:47 +0000 +++ kern/term.c 2008-10-30 18:24:32 +0000 @@ -153,7 +153,7 @@ grub_ssize_t ret; buf[size++] = c; - ret = grub_utf8_to_ucs4 (&code, buf, size); + ret = grub_utf8_to_ucs4 (&code, 1, buf, size, 0); if (ret > 0) { === modified file 'normal/menu.c' --- normal/menu.c 2008-08-31 00:48:14 +0000 +++ normal/menu.c 2008-10-30 18:43:35 +0000 @@ -117,19 +117,21 @@ { int x; const char *title; + grub_size_t title_len; grub_ssize_t len; grub_uint32_t *unicode_title; grub_ssize_t i; grub_uint8_t old_color_normal, old_color_highlight; title = entry ? entry->title : ""; - unicode_title = grub_malloc (grub_strlen (title) * sizeof (*unicode_title)); + title_len = grub_strlen (title); + unicode_title = grub_malloc (title_len * sizeof (*unicode_title)); if (! unicode_title) /* XXX How to show this error? */ return; - len = grub_utf8_to_ucs4 (unicode_title, (grub_uint8_t *) title, - grub_strlen (title)); + len = grub_utf8_to_ucs4 (unicode_title, title_len, + (grub_uint8_t *) title, -1, 0); if (len < 0) { /* It is an invalid sequence. */ === modified file 'term/gfxterm.c' --- term/gfxterm.c 2008-08-31 03:08:13 +0000 +++ term/gfxterm.c 2008-10-30 18:24:32 +0000 @@ -35,9 +35,6 @@ #define DEFAULT_VIDEO_HEIGHT 480 #define DEFAULT_VIDEO_FLAGS 0 -#define DEFAULT_CHAR_WIDTH 8 -#define DEFAULT_CHAR_HEIGHT 16 - #define DEFAULT_BORDER_WIDTH 10 #define DEFAULT_STANDARD_COLOR 0x07 @@ -91,6 +88,9 @@ unsigned int cursor_y; int cursor_state; + /* Font settings. */ + grub_font_t font; + /* Terminal color settings. */ grub_uint8_t standard_color_setting; grub_uint8_t normal_color_setting; @@ -169,18 +169,25 @@ static grub_err_t grub_virtual_screen_setup (unsigned int x, unsigned int y, - unsigned int width, unsigned int height) + unsigned int width, unsigned int height, + const char *font_name) { /* Free old virtual screen. */ grub_virtual_screen_free (); /* Initialize with default data. */ + virtual_screen.font = grub_font_get (font_name); + if (!virtual_screen.font) + return grub_error (GRUB_ERR_BAD_FONT, + "No font loaded."); virtual_screen.width = width; virtual_screen.height = height; virtual_screen.offset_x = x; virtual_screen.offset_y = y; - virtual_screen.char_width = DEFAULT_CHAR_WIDTH; - virtual_screen.char_height = DEFAULT_CHAR_HEIGHT; + virtual_screen.char_width = + grub_font_get_max_char_width (virtual_screen.font); + virtual_screen.char_height = + grub_font_get_max_char_height (virtual_screen.font); virtual_screen.cursor_x = 0; virtual_screen.cursor_y = 0; virtual_screen.cursor_state = 1; @@ -226,6 +233,7 @@ static grub_err_t grub_gfxterm_init (void) { + char *font_name; char *modevar; int width = DEFAULT_VIDEO_WIDTH; int height = DEFAULT_VIDEO_HEIGHT; @@ -233,6 +241,11 @@ int flags = DEFAULT_VIDEO_FLAGS; grub_video_color_t color; + /* Select the font to use. */ + font_name = grub_env_get ("gfxterm_font"); + if (!font_name) + font_name = ""; /* Allow fallback to any font. */ + /* Parse gfxmode environment variable if set. */ modevar = grub_env_get ("gfxmode"); if (modevar) @@ -472,7 +485,7 @@ /* Create virtual screen. */ if (grub_virtual_screen_setup (DEFAULT_BORDER_WIDTH, DEFAULT_BORDER_WIDTH, - width, height) != GRUB_ERR_NONE) + width, height, font_name) != GRUB_ERR_NONE) { grub_video_restore (); return grub_errno; @@ -658,11 +671,12 @@ write_char (void) { struct grub_colored_char *p; - struct grub_font_glyph glyph; + struct grub_font_glyph *glyph; grub_video_color_t color; grub_video_color_t bgcolor; unsigned int x; unsigned int y; + int ascent; /* Find out active character. */ p = (virtual_screen.text_buffer @@ -672,7 +686,8 @@ p -= p->index; /* Get glyph for character. */ - grub_font_get_glyph (p->code, &glyph); + glyph = grub_font_get_glyph (virtual_screen.font, p->code); + ascent = grub_font_get_ascent (virtual_screen.font); color = p->fg_color; bgcolor = p->bg_color; @@ -682,13 +697,13 @@ /* Render glyph to text layer. */ grub_video_set_active_render_target (text_layer); - grub_video_fill_rect (bgcolor, x, y, glyph.width, glyph.height); - grub_video_blit_glyph (&glyph, color, x, y); + grub_video_fill_rect (bgcolor, x, y, glyph->width, glyph->height); + grub_font_draw_glyph (glyph, color, x, y + ascent); grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); /* Mark character to be drawn. */ dirty_region_add (virtual_screen.offset_x + x, virtual_screen.offset_y + y, - glyph.width, glyph.height); + glyph->width, glyph->height); } static void @@ -702,7 +717,8 @@ /* Determine cursor properties and position on text layer. */ x = virtual_screen.cursor_x * virtual_screen.char_width; - y = ((virtual_screen.cursor_y + 1) * virtual_screen.char_height) - 3; + y = (virtual_screen.cursor_y * virtual_screen.char_height + + grub_font_get_ascent (virtual_screen.font)); width = virtual_screen.char_width; height = 2; @@ -819,14 +835,18 @@ } else { - struct grub_font_glyph glyph; + struct grub_font_glyph *glyph; struct grub_colored_char *p; + unsigned char_width; /* Get properties of the character. */ - grub_font_get_glyph (c, &glyph); + glyph = grub_font_get_glyph (virtual_screen.font, c); + + /* TODO Fix wide characters. Bi-width font support? */ + char_width = 1; /* If we are about to exceed line length, wrap to next line. */ - if (virtual_screen.cursor_x + glyph.char_width > virtual_screen.columns) + if (virtual_screen.cursor_x + char_width > virtual_screen.columns) grub_putchar ('\n'); /* Find position on virtual screen, and fill information. */ @@ -836,18 +856,18 @@ p->code = c; p->fg_color = virtual_screen.fg_color; p->bg_color = virtual_screen.bg_color; - p->width = glyph.char_width - 1; + p->width = char_width - 1; p->index = 0; /* If we have large glyph, add fixup info. */ - if (glyph.char_width > 1) + if (char_width > 1) { unsigned i; - for (i = 1; i < glyph.char_width; i++) + for (i = 1; i < char_width; i++) { p[i].code = ' '; - p[i].width = glyph.char_width - 1; + p[i].width = char_width - 1; p[i].index = i; } } @@ -856,7 +876,7 @@ write_char (); /* Make sure we scroll screen when needed and wrap line correctly. */ - virtual_screen.cursor_x += glyph.char_width; + virtual_screen.cursor_x += char_width; if (virtual_screen.cursor_x >= virtual_screen.columns) { virtual_screen.cursor_x = 0; @@ -876,11 +896,16 @@ static grub_ssize_t grub_gfxterm_getcharwidth (grub_uint32_t c) { - struct grub_font_glyph glyph; - - grub_font_get_glyph (c, &glyph); - - return glyph.char_width; +#if 0 + struct grub_font_glyph *glyph; + + glyph = grub_font_get_glyph (c); + + return glyph->char_width; +#else + (void) c; /* Prevent warning. */ + return 1; /* TODO Fix wide characters. */ +#endif } static grub_uint16_t === modified file 'term/i386/pc/vesafb.c' --- term/i386/pc/vesafb.c 2007-12-30 08:52:06 +0000 +++ term/i386/pc/vesafb.c 2008-10-30 18:24:32 +0000 @@ -250,10 +250,11 @@ break; default: - return grub_font_get_glyph (code, bitmap, width); + return grub_font_get_glyph_any (code, bitmap, width); } } + /* TODO This is wrong for the new font module. Should it be fixed? */ if (bitmap) grub_memcpy (bitmap, vga_font + code * virtual_screen.char_height, === modified file 'term/i386/pc/vga.c' --- term/i386/pc/vga.c 2008-01-21 15:48:27 +0000 +++ term/i386/pc/vga.c 2008-10-30 18:24:32 +0000 @@ -65,6 +65,7 @@ static struct colored_char text_buf[TEXT_WIDTH * TEXT_HEIGHT]; static unsigned char saved_map_mask; static int page = 0; +static grub_font_t font = 0; #define SEQUENCER_ADDR_PORT 0x3C4 #define SEQUENCER_DATA_PORT 0x3C5 @@ -161,6 +162,9 @@ saved_map_mask = get_map_mask (); set_map_mask (0x0f); set_start_address (PAGE_OFFSET (page)); + font = grub_font_get (""); /* Choose any font, for now. */ + if (!font) + return grub_error (GRUB_ERR_BAD_FONT, "No font loaded."); return GRUB_ERR_NONE; } @@ -185,7 +189,7 @@ write_char (void) { struct colored_char *p = text_buf + xpos + ypos * TEXT_WIDTH; - struct grub_font_glyph glyph; + struct grub_font_glyph *glyph; unsigned char *mem_base; unsigned plane; @@ -194,7 +198,7 @@ p -= p->index; /* Get glyph for character. */ - grub_font_get_glyph (p->code, &glyph); + glyph = grub_font_get_glyph (font, p->code); for (plane = 0x01; plane <= 0x08; plane <<= 1) { @@ -208,19 +212,23 @@ y < CHAR_HEIGHT; y++, mem += TEXT_WIDTH) { + /* TODO Re-implement glyph drawing for vga module. */ +#if 0 unsigned i; - for (i = 0; i < glyph.char_width && offset < 32; i++) + unsigned char_width = 1; /* TODO Figure out wide characters. */ + for (i = 0; i < char_width && offset < 32; i++) { unsigned char fg_mask, bg_mask; - fg_mask = (p->fg_color & plane) ? glyph.bitmap[offset] : 0; - bg_mask = (p->bg_color & plane) ? ~(glyph.bitmap[offset]) : 0; + fg_mask = (p->fg_color & plane) ? glyph->bitmap[offset] : 0; + bg_mask = (p->bg_color & plane) ? ~(glyph->bitmap[offset]) : 0; offset++; if (check_vga_mem (mem + i)) mem[i] = (fg_mask | bg_mask); } +#endif /* 0 */ } } @@ -320,36 +328,37 @@ } else { - struct grub_font_glyph glyph; + struct grub_font_glyph *glyph; struct colored_char *p; + unsigned char_width = 1; - grub_font_get_glyph(c, &glyph); + glyph = grub_font_get_glyph(font, c); - if (xpos + glyph.char_width > TEXT_WIDTH) + if (xpos + char_width > TEXT_WIDTH) grub_putchar ('\n'); p = text_buf + xpos + ypos * TEXT_WIDTH; p->code = c; p->fg_color = fg_color; p->bg_color = bg_color; - p->width = glyph.char_width - 1; + p->width = char_width - 1; p->index = 0; - if (glyph.char_width > 1) + if (char_width > 1) { unsigned i; - for (i = 1; i < glyph.char_width; i++) + for (i = 1; i < char_width; i++) { p[i].code = ' '; - p[i].width = glyph.char_width - 1; + p[i].width = char_width - 1; p[i].index = i; } } write_char (); - xpos += glyph.char_width; + xpos += char_width; if (xpos >= TEXT_WIDTH) { xpos = 0; @@ -381,11 +390,16 @@ static grub_ssize_t grub_vga_getcharwidth (grub_uint32_t c) { +#if 0 struct grub_font_glyph glyph; - grub_font_get_glyph (c, &glyph); + glyph = grub_font_get_glyph (c); return glyph.char_width; +#else + (void) c; /* Prevent warning. */ + return 1; /* TODO Fix wide characters? */ +#endif } static grub_uint16_t === modified file 'video/i386/pc/vbe.c' --- video/i386/pc/vbe.c 2008-10-03 15:25:34 +0000 +++ video/i386/pc/vbe.c 2008-10-30 18:24:32 +0000 @@ -26,7 +26,6 @@ #include #include #include -#include #include #include #include @@ -896,6 +895,16 @@ return minindex; } + else if ((render_target->mode_info.mode_type + & GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP) != 0) + { + if (red == render_target->mode_info.fg_red + && green == render_target->mode_info.fg_green + && blue == render_target->mode_info.fg_blue) + return 1; + else + return 0; + } else { grub_uint32_t value; @@ -926,6 +935,17 @@ /* No alpha available in index color modes, just use same value as in only RGB modes. */ return grub_video_vbe_map_rgb (red, green, blue); + else if ((render_target->mode_info.mode_type + & GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP) != 0) + { + if (red == render_target->mode_info.fg_red + && green == render_target->mode_info.fg_green + && blue == render_target->mode_info.fg_blue + && alpha == render_target->mode_info.fg_alpha) + return 1; + else + return 0; + } else { grub_uint32_t value; @@ -988,6 +1008,24 @@ *alpha = framebuffer.palette[color].a; return; } + else if ((mode_info->mode_type + & GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP) != 0) + { + if (color & 1) + { + *red = mode_info->fg_red; + *green = mode_info->fg_green; + *blue = mode_info->fg_blue; + *alpha = mode_info->fg_alpha; + } + else + { + *red = mode_info->bg_red; + *green = mode_info->bg_green; + *blue = mode_info->bg_blue; + *alpha = mode_info->bg_alpha; + } + } else { grub_uint32_t tmp; @@ -1111,76 +1149,6 @@ return GRUB_ERR_NONE; } -// TODO: Remove this method and replace with bitmap based glyphs -static grub_err_t -grub_video_vbe_blit_glyph (struct grub_font_glyph * glyph, - grub_video_color_t color, int x, int y) -{ - struct grub_video_i386_vbeblit_info target; - unsigned int width; - unsigned int charwidth; - unsigned int height; - unsigned int i; - unsigned int j; - unsigned int x_offset = 0; - unsigned int y_offset = 0; - - /* Make sure there is something to do. */ - if (x >= (int)render_target->viewport.width) - return GRUB_ERR_NONE; - - if (y >= (int)render_target->viewport.height) - return GRUB_ERR_NONE; - - /* Calculate glyph dimensions. */ - width = ((glyph->width + 7) / 8) * 8; - charwidth = width; - height = glyph->height; - - if (x + (int)width < 0) - return GRUB_ERR_NONE; - - if (y + (int)height < 0) - return GRUB_ERR_NONE; - - /* Do not allow drawing out of viewport. */ - if (x < 0) - { - width += x; - x_offset = (unsigned int)-x; - x = 0; - } - if (y < 0) - { - height += y; - y_offset = (unsigned int)-y; - y = 0; - } - - if ((x + width) > render_target->viewport.width) - width = render_target->viewport.width - x; - if ((y + height) > render_target->viewport.height) - height = render_target->viewport.height - y; - - /* Add viewport offset. */ - x += render_target->viewport.x; - y += render_target->viewport.y; - - /* Use vbeblit_info to encapsulate rendering. */ - target.mode_info = &render_target->mode_info; - target.data = render_target->data; - - /* Draw glyph. */ - for (j = 0; j < height; j++) - for (i = 0; i < width; i++) - if ((glyph->bitmap[((i + x_offset) / 8) - + (j + y_offset) * (charwidth / 8)] - & (1 << ((charwidth - (i + x_offset) - 1) % 8)))) - set_pixel (&target, x+i, y+j, color); - - return GRUB_ERR_NONE; -} - /* NOTE: This function assumes that given coordinates are within bounds of handled data. */ static void @@ -1804,7 +1772,6 @@ .map_rgba = grub_video_vbe_map_rgba, .unmap_color = grub_video_vbe_unmap_color, .fill_rect = grub_video_vbe_fill_rect, - .blit_glyph = grub_video_vbe_blit_glyph, .blit_bitmap = grub_video_vbe_blit_bitmap, .blit_render_target = grub_video_vbe_blit_render_target, .scroll = grub_video_vbe_scroll, === modified file 'video/i386/pc/vbeutil.c' --- video/i386/pc/vbeutil.c 2007-07-21 22:32:33 +0000 +++ video/i386/pc/vbeutil.c 2008-10-30 18:24:32 +0000 @@ -52,6 +52,11 @@ + y * source->mode_info->pitch + x; break; + + /* case 1: */ + /* For 1-bit bitmaps, addressing needs to be done at the bit level + * and it doesn't make sense, in general, to ask for a pointer + * to a particular pixel's data. */ } return ptr; @@ -86,6 +91,17 @@ color = *(grub_uint8_t *)get_data_ptr (source, x, y); break; + case 1: + if (source->mode_info->blit_format == GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED) + { + int bit_index = y * source->mode_info->width + x; + grub_uint8_t *ptr = (grub_uint8_t *)source->data + + bit_index / 8; + int bit_pos = 7 - bit_index % 8; + color = (*ptr >> bit_pos) & 0x01; + } + break; + default: break; } @@ -143,6 +159,17 @@ } break; + case 1: + if (source->mode_info->blit_format == GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED) + { + int bit_index = y * source->mode_info->width + x; + grub_uint8_t *ptr = (grub_uint8_t *)source->data + + bit_index / 8; + int bit_pos = 7 - bit_index % 8; + *ptr = (*ptr & ~(1 << bit_pos)) | ((color & 0x01) << bit_pos); + } + break; + default: break; } === modified file 'video/video.c' --- video/video.c 2008-10-03 15:25:34 +0000 +++ video/video.c 2008-10-30 18:24:32 +0000 @@ -336,17 +336,6 @@ return grub_video_adapter_active->fill_rect (color, x, y, width, height); } -/* Blit glyph to screen using specified color. */ -grub_err_t -grub_video_blit_glyph (struct grub_font_glyph *glyph, - grub_video_color_t color, int x, int y) -{ - if (! grub_video_adapter_active) - return grub_error (GRUB_ERR_BAD_DEVICE, "No video mode activated"); - - return grub_video_adapter_active->blit_glyph (glyph, color, x, y); -} - /* Blit bitmap to screen. */ grub_err_t grub_video_blit_bitmap (struct grub_video_bitmap *bitmap, --MP_/4.0QWF1RbluvAB7Y_uAF.nU-- From MAILER-DAEMON Thu Oct 30 15:31:00 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KvdER-0008RR-Jp for mharc-grub-devel@gnu.org; Thu, 30 Oct 2008 15:30:59 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KvdEQ-0008Qg-4A for grub-devel@gnu.org; Thu, 30 Oct 2008 15:30:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvdEO-0008Pp-9Z for grub-devel@gnu.org; Thu, 30 Oct 2008 15:30:57 -0400 Received: from [199.232.76.173] (port=57079 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvdEO-0008Pf-0J for grub-devel@gnu.org; Thu, 30 Oct 2008 15:30:56 -0400 Received: from gateway09.websitewelcome.com ([67.18.14.9]:57102) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KvdEN-0002Ez-25 for grub-devel@gnu.org; Thu, 30 Oct 2008 15:30:56 -0400 Received: (qmail 4777 invoked from network); 30 Oct 2008 19:41:51 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway09.websitewelcome.com with SMTP; 30 Oct 2008 19:41:51 -0000 Received: from c-67-185-177-95.hsd1.wa.comcast.net ([67.185.177.95]:36521 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KvdEE-0007SN-Da for grub-devel@gnu.org; Thu, 30 Oct 2008 14:30:46 -0500 Date: Thu, 30 Oct 2008 12:29:25 -0700 From: Colin D Bennett To: The development of GRUB 2 Message-ID: <20081030122925.0b978501@gibibit.com> In-Reply-To: <20080901105708.3c194cf7@gamma.lan> References: <20080901105708.3c194cf7@gamma.lan> X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/LldYPZA.P+5uWlvje=Tt7mc"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #12 videotest enhancements (plus UTF-8 test) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2008 19:30:58 -0000 --Sig_/LldYPZA.P+5uWlvje=Tt7mc Content-Type: multipart/mixed; boundary="MP_//=857D__Bt=SPy15N=AG+87" --MP_//=857D__Bt=SPy15N=AG+87 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 1 Sep 2008 10:57:08 -0700 Colin D Bennett wrote: > This patch adds a number of different tests to the 'videotest' > command, including a benchmark test that tabulates the performance > results for various video modes and graphics operations. This updated patch adds support to the "videotest text" test for testing UTF-8 strings containing non-ASCII Unicode characters. It requires the GSoC #10 Font Engine patch updated with UTF-8 support. Regards, Colin --MP_//=857D__Bt=SPy15N=AG+87 Content-Type: text/x-patch; name=12_videotest_2008-10-30.patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=12_videotest_2008-10-30.patch 2008-10-30 Colin D Bennett Enhance the 'videotest' command with a number of different tests. * commands/videotest.c (grub_cmd_videotest): Support running different tests and handling command line arguments for several flags. (ARGINDEX_TEST_TIME): Added. (ARGINDEX_DOUBLE_BUF): Likewise. (arg_options): Likewise. (DEFAULT_TEST_TIME): Likewise. (videotest_options): Likewise. (basic_video_test): Likewise. (bitmap_demo): Likewise. (benchmark_config): Likewise. (MODE_TYPE_RGB): Likewise. (benchmark_configs): Likewise. (NUM_BENCHMARK_CONFIGS): Likewise. (benchmark_result): Likewise. (BENCHMARK_RESULT_FPS_SCALE): Likewise. (move_rectangle_one_step): Likewise. (do_benchmark): Likewise. (benchmark_test): Likewise. (clock_test): Likewise. (doublebuf_test): Likewise. (text_test): Likewise. (scale_test): Likewise. (list_tests): Likewise. * include/grub/video.h (grub_video_rect_t: Added. =3D=3D=3D modified file 'commands/videotest.c' --- commands/videotest.c 2008-10-30 16:46:05 +0000 +++ commands/videotest.c 2008-10-30 18:26:46 +0000 @@ -17,6 +17,7 @@ */ =20 #include +#include #include #include #include @@ -26,31 +27,59 @@ #include #include #include - -static grub_err_t -grub_cmd_videotest (struct grub_arg_list *state __attribute__ ((unused)), - int argc __attribute__ ((unused)), - char **args __attribute__ ((unused))) -{ +#include +#include +#include /* to test grub_vbe_bios_set_display_start= */ + +/* Option array indices. */ +#define ARGINDEX_TEST_TIME 0 +#define ARGINDEX_DOUBLE_BUF 1 + +static const struct grub_arg_option arg_options[] =3D { + {"time", 't', 0, "Time to run each test, in seconds.", 0, ARG_TYPE_INT}, + {"dbuf", 'd', 0, "Use double buffered graphics.", 0, ARG_TYPE_NONE}, + {0, 0, 0, 0, 0, 0} +}; + +#define DEFAULT_TEST_TIME 5 + +/* Command options -- populated base on command line arguments. */ +struct videotest_options +{ + int test_time; + int double_buffering; +}; + + +static void +basic_video_test (struct videotest_options *vt_opts) +{ + int mode_type =3D GRUB_VIDEO_MODE_TYPE_INDEX_COLOR; + if (vt_opts->double_buffering) + mode_type |=3D GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED; if (grub_video_setup (1024, 768, GRUB_VIDEO_MODE_TYPE_INDEX_COLOR) !=3D GRUB_ERR_NO= NE) - return grub_errno; + return; =20 grub_video_color_t color; + grub_video_color_t bg; unsigned int x; unsigned int y; unsigned int width; unsigned int height; int i; - grub_font_t sansbig; - grub_font_t sans; - grub_font_t sanssmall; - grub_font_t fixed; struct grub_font_glyph *glyph; struct grub_video_render_target *text_layer; + grub_font_t fixed; grub_video_color_t palette[16]; - const char *str; - int texty; + int info_width; + int info_height; + + if (! (fixed =3D grub_font_get ("Fixed 20"))) + { + grub_error (GRUB_ERR_BAD_FONT, "No font loaded."); + return; + } =20 grub_video_get_viewport (&x, &y, &width, &height); =20 @@ -60,7 +89,11 @@ =20 grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); =20 + info_width =3D 500; + info_height =3D 100; + color =3D grub_video_map_rgb (0, 0, 0); + bg =3D color; grub_video_fill_rect (color, 0, 0, width, height); =20 color =3D grub_video_map_rgb (255, 0, 0); @@ -69,13 +102,6 @@ color =3D grub_video_map_rgb (0, 255, 255); grub_video_fill_rect (color, 100, 100, 100, 100); =20 - sansbig =3D grub_font_get ("Helvetica Bold 24"); - sans =3D grub_font_get ("Helvetica Bold 14"); - sanssmall =3D grub_font_get ("Helvetica 8"); - fixed =3D grub_font_get ("Fixed 20"); - if (! sansbig || ! sans || ! sanssmall || ! fixed) - return grub_error (GRUB_ERR_BAD_FONT, "No font loaded."); - glyph =3D grub_font_get_glyph (fixed, '*'); grub_font_draw_glyph (glyph, color, 200 ,0); =20 @@ -86,17 +112,920 @@ =20 grub_video_set_active_render_target (text_layer); =20 - color =3D grub_video_map_rgb (255, 255, 255); - - texty =3D 32; - grub_font_draw_string ("The quick brown fox jumped over the lazy dog.", - sans, color, 16, texty); - texty +=3D grub_font_get_descent (sans) + grub_font_get_leading (sans); - - texty +=3D grub_font_get_ascent (fixed); - grub_font_draw_string ("The quick brown fox jumped over the lazy dog.", - fixed, color, 16, texty); - texty +=3D grub_font_get_descent (fixed) + grub_font_get_leading (fixed); + color =3D grub_video_map_rgb (255, 255, 0); + grub_font_draw_string ("ABCDEFG", fixed, color, 16, 100); + color =3D grub_video_map_rgb (128, 128, 255); + grub_font_draw_string ("The quick brown fox jumped over the lazy dog.", + fixed, color, 16, 150); + + color =3D grub_video_map_rgb (255, 255, 255); + glyph =3D grub_font_get_glyph (fixed, '*'); + + for (i =3D 0; i < 16; i++) + { + color =3D grub_video_map_color (i); + palette[i] =3D color; + grub_font_draw_glyph (glyph, color, 16 + i * 16, 220); + } + + grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); + + for (i =3D 0; i < 255; i++) + { + color =3D grub_video_map_rgb (i, 33, 77); + grub_video_fill_rect (color, 0, 0, width, height); + grub_video_blit_render_target (text_layer, GRUB_VIDEO_BLIT_BLEND, 0,= 0, + 0, 0, width, height); + } + + color =3D grub_video_map_rgb (255, 255, 0); + grub_font_draw_string ("Press a key to continue.", fixed, color, 10, 60); + grub_video_swap_buffers (); + grub_getkey (); + grub_video_fill_rect (bg, 0, 0, info_width, info_height); /* Clear info= . */ + + /* Test VBE set display start address. */ + /* This should scroll the screen, first vertically, + * then horizontally. The horizontal scrolling seems to + * only have a resolution of about 16 pixels on my VIA Mini-ITX. */ + grub_font_draw_string ("Testing VBE 'Set display start' operation " + "for horizontal scrolling...", + fixed, color, 10, 20); + grub_video_swap_buffers (); + int vbestatus; + int vbeok =3D 0; + int vbeerr =3D 0; + for (i =3D 0; i < 50; i++) + { + vbestatus =3D grub_vbe_bios_set_display_start (0, i); + if (vbestatus =3D=3D GRUB_VBE_STATUS_OK) + vbeok++; + else + vbeerr++; + } + + grub_font_draw_string ("Press a key to continue.", fixed, color, 10, 60); + grub_video_swap_buffers (); + grub_getkey (); + grub_video_fill_rect (bg, 0, 0, info_width, info_height); /* Clear info= . */ + grub_video_swap_buffers (); + + grub_font_draw_string ("Testing VBE 'Set display start' operation " + "for vertical scrolling...", + fixed, color, 10, 40); + grub_video_swap_buffers (); + for (i =3D 0; i < 50; i++) + { + vbestatus =3D grub_vbe_bios_set_display_start (i, 50); + if (vbestatus =3D=3D GRUB_VBE_STATUS_OK) + vbeok++; + else + vbeerr++; + } + + grub_font_draw_string ("Press a key to continue.", fixed, color, 10, 60); + grub_video_swap_buffers (); + grub_getkey (); + grub_video_fill_rect (bg, 0, 0, info_width, info_height); /* Clear info= . */ + grub_video_swap_buffers (); + + grub_video_delete_render_target (text_layer); + grub_video_restore (); + + grub_printf ("VBE set_display_start status: %d\n", vbestatus); + grub_printf ("ok: %d\n", vbeok); + grub_printf ("errors: %d\n", vbeerr); + + grub_errno =3D GRUB_ERR_NONE; +} +=0C + + +/** + * Simple opaque image blit test. + * Returns the error status in grub_errno. + */ +static void +bitmap_demo (struct videotest_options *vt_opts) +{ + int mode_type =3D GRUB_VIDEO_MODE_TYPE_RGB; + if (vt_opts->double_buffering) + mode_type |=3D GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED; + if (grub_video_setup (1024, 768, mode_type) !=3D GRUB_ERR_NONE) + return; + + grub_video_rect_t view; + grub_video_get_viewport ((unsigned *) &view.x, (unsigned *) &view.y, + (unsigned *) &view.width, + (unsigned *) &view.height); + + grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); + const int bm1width =3D 500, bm1height =3D 400; + struct grub_video_bitmap *bitmap1; + + if (grub_video_bitmap_create (&bitmap1, bm1width, bm1height, + GRUB_VIDEO_BLIT_FORMAT_RGB_888) + !=3D GRUB_ERR_NONE) + return; + + int offset =3D 0; + int x; + int y; + grub_uint8_t *data =3D grub_video_bitmap_get_data (bitmap1); + for (y =3D 0; y < bm1height; y++) + { + for (x =3D 0; x < bm1width; x++) + { + data[offset++] =3D x ^ y; /* red */ + data[offset++] =3D (x * 3) ^ (y * 3); /* green */ + data[offset++] =3D (x * 2) ^ (y * 2); /* blue */ + } + } + + /* Blit the entire bitmap in the center of the screen. */ + grub_video_blit_bitmap (bitmap1, + GRUB_VIDEO_BLIT_REPLACE, + view.x + (view.width - bm1width) / 2, + view.y + (view.height - bm1height) / 2, + 0, 0, bm1width, bm1height); + grub_video_swap_buffers (); + grub_getkey (); + + /* Blit more copies of the bitmap. */ + /* Upper left. */ + grub_video_blit_bitmap (bitmap1, GRUB_VIDEO_BLIT_REPLACE, + view.x, view.y, 0, 0, bm1width, bm1height); + /* Upper right. */ + grub_video_blit_bitmap (bitmap1, + GRUB_VIDEO_BLIT_REPLACE, + view.x + view.width - bm1width, + view.y, 0, 0, bm1width, bm1height); + /* Lower left. */ + grub_video_blit_bitmap (bitmap1, + GRUB_VIDEO_BLIT_REPLACE, + view.x, + view.y + view.height - bm1height, + 0, 0, bm1width, bm1height); + /* Lower right. */ + grub_video_blit_bitmap (bitmap1, + GRUB_VIDEO_BLIT_REPLACE, + view.x + view.width - bm1width, + view.y + view.height - bm1height, + 0, 0, bm1width, bm1height); + grub_video_swap_buffers (); + grub_getkey (); + + int clearbg =3D 0; /* Boolean flag: whether to fill backgro= und. */ + grub_video_color_t bgcolor =3D grub_video_map_rgb (16, 16, 96); + + /* Animate the image sliding in. End when a key is pressed. */ + int vscale =3D 1000; + int velocityx =3D -5000; + int velocityy =3D -8000; + int positionx =3D 100; + int positiony =3D 300; + + grub_uint32_t frame_count =3D 0; + grub_uint32_t start_time =3D grub_get_time_ms (); + + while (grub_checkkey () =3D=3D -1) + { + /* If the time limit option is set, then check if it's exceeded. */ + if (vt_opts->test_time !=3D 0 + && grub_get_time_ms () >=3D start_time + vt_opts->test_time * 10= 00) + break; + + int newx =3D positionx + velocityx / vscale; + int newy =3D positiony + velocityy / vscale; + + /* Check collision w/ left */ + if (newx < view.x && velocityx < 0) + { + velocityx =3D -velocityx; + newx =3D positionx + velocityx / vscale; + } + /* Check collision w/ right */ + if (newx + bm1width > view.x + view.width && velocityx > 0) + { + velocityx =3D -velocityx; + newx =3D positionx + velocityx / vscale; + } + /* Check collision w/ top */ + if (newy < 0 && velocityy < 0) + { + velocityy =3D -velocityy; + newy =3D positiony + velocityy / vscale; + } + /* Check collision w/ bottom */ + if (newy + bm1height > view.y + view.height && velocityy > 0) + { + velocityy =3D -velocityy; + newy =3D positiony + velocityy / vscale; + } + + positionx =3D newx; + positiony =3D newy; + + if (clearbg) + grub_video_fill_rect (bgcolor, view.x, view.y, view.width, + view.height); + + grub_video_blit_bitmap (bitmap1, + GRUB_VIDEO_BLIT_REPLACE, + view.x + positionx, + view.y + positiony, 0, 0, bm1width, bm1heigh= t); + grub_video_swap_buffers (); + frame_count++; + + /* Acceleration due to gravity... + * note that the y coordinate is increasing downward. */ + velocityy +=3D vscale / 7; + } + + /* Calculate average frame rate. */ + grub_uint32_t duration =3D grub_get_time_ms () - start_time; + grub_uint32_t fps_x10 =3D 10 * 1000 * frame_count / duration; + + /* Eat the keystroke. */ + if (grub_checkkey () !=3D -1) + grub_getkey (); + + grub_video_bitmap_destroy (bitmap1); + grub_video_restore (); + + grub_printf ("Average frame rate: %d.%d fps\n", fps_x10 / 10, fps_x10 % = 10); + + grub_errno =3D GRUB_ERR_NONE; +} +=0C + + +/* Configuration settings for a benchmark run. */ +struct benchmark_config +{ + int width; + int height; + unsigned int mode_type; + int use_rgba_bitmaps; +}; + +/* Macro to make the benchmark_configs[] declaration more concise. */ +#define MODE_TYPE_RGB(bpp) (GRUB_VIDEO_MODE_TYPE_RGB \ + | ((bpp) << GRUB_VIDEO_MODE_TYPE_DEPTH_POS)) + +/* The video configurations to use for the benchmark. */ +static struct benchmark_config benchmark_configs[] =3D { + {320, 200, MODE_TYPE_RGB (0), 0}, + {640, 480, MODE_TYPE_RGB (0), 0}, + {1024, 768, MODE_TYPE_RGB (0), 0}, + {1024, 768, MODE_TYPE_RGB (0), 1}, +}; + +#define NUM_BENCHMARK_CONFIGS (sizeof(benchmark_configs) \ + / sizeof(benchmark_configs[0])) + +struct benchmark_result +{ + /* If set to 1, the test was able to run successfully; + * 0 means there was an error. */ + int test_passed; + + /* Bits per pixel for the video mode used. */ + int bpp; + + /* All fps are in fps * 10 to achieve one decimal place. */ + /* Set to 0 to indicate the test could not be run. */ + grub_int32_t fill_fps; + grub_int32_t blit_fps; + grub_int32_t blend_fps; +}; + +#define BENCHMARK_RESULT_FPS_SCALE 10 + +static void +move_rectangle_one_step (int *x, int *y, + int width, int height, + int *vx, int *vy, const grub_video_rect_t * bound= s) +{ + int newx =3D *x + *vx; + int newy =3D *y + *vy; + + /* Check collision w/ left */ + if (newx < bounds->x && *vx < 0) + { + *vx =3D -*vx; + newx =3D *x + *vx; + } + /* Check collision w/ right */ + if (newx + width > bounds->x + bounds->width && *vx > 0) + { + *vx =3D -*vx; + newx =3D *x + *vx; + } + /* Check collision w/ top */ + if (newy < 0 && *vy < 0) + { + *vy =3D -*vy; + newy =3D *y + *vy; + } + /* Check collision w/ bottom */ + if (newy + height > bounds->y + bounds->height && *vy > 0) + { + *vy =3D -*vy; + newy =3D *y + *vy; + } + + *x =3D newx; + *y =3D newy; +} + +/** + * Run the benchmark test for a particular video mode, which is specified + * by ``*config``. The results of the test are stored in ``*result``. + */ +static void +do_benchmark (const struct benchmark_config *config, + struct benchmark_result *result, + struct videotest_options *vt_opts) +{ + struct grub_video_mode_info modeinfo; + + result->test_passed =3D 0; + result->fill_fps =3D 0; + result->blit_fps =3D 0; + result->blend_fps =3D 0; + result->bpp =3D 0; + + int mode_type =3D config->mode_type; + if (vt_opts->double_buffering) + mode_type |=3D GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED; + if (grub_video_setup (config->width, config->height, + mode_type) !=3D GRUB_ERR_NONE) + return; + + if (grub_video_get_info (&modeinfo) =3D=3D GRUB_ERR_NONE) + result->bpp =3D modeinfo.bpp; + + /* Full screen bitmap blit test. */ + + grub_video_rect_t view; + grub_video_get_viewport ((unsigned *) &view.x, (unsigned *) &view.y, + (unsigned *) &view.width, + (unsigned *) &view.height); + + grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); + + + /* For measuring timing. */ + grub_uint32_t frame_count; + grub_uint64_t start_time; + grub_uint64_t desired_stop_time; + grub_uint32_t duration; + + + /*** FILL TEST ***/ + + /* Alternates between 0 and 1 to change the color. */ + int color_flag =3D 0; + grub_video_color_t fillcolors[2]; + fillcolors[0] =3D grub_video_map_rgb (0, 0, 255); + fillcolors[1] =3D grub_video_map_rgb (255, 255, 0); + + frame_count =3D 0; + start_time =3D grub_get_time_ms (); + desired_stop_time =3D start_time + vt_opts->test_time * 1000; + + while (grub_get_time_ms () < desired_stop_time && grub_checkkey () =3D= =3D -1) + { + grub_video_fill_rect (fillcolors[color_flag], + view.x, view.y, view.width, view.height); + grub_video_swap_buffers (); + color_flag ^=3D 1; + frame_count++; + } + if (grub_checkkey () !=3D -1) + grub_getkey (); /* Eat the keypress, if there was one. */ + + /* Calculate average frame rate. */ + duration =3D grub_get_time_ms () - start_time; + if (duration =3D=3D 0) + { + result->fill_fps =3D 0; + } + else + { + result->fill_fps =3D + (BENCHMARK_RESULT_FPS_SCALE * 1000 + * frame_count / duration); + } + + + /*** BLIT TEST ***/ + + /* Generate two bitmaps, the same size as the screen. */ + const int bitmapwidth =3D view.width, bitmapheight =3D view.height; + struct grub_video_bitmap *bitmap1; + struct grub_video_bitmap *bitmap2; + enum grub_video_blit_format bitmap_format =3D config->use_rgba_bitmaps + ? GRUB_VIDEO_BLIT_FORMAT_RGBA_8888 : GRUB_VIDEO_BLIT_FORMAT_RGB_888; + + if (grub_video_bitmap_create (&bitmap1, bitmapwidth, bitmapheight, + bitmap_format) !=3D GRUB_ERR_NONE) + return; + + if (grub_video_bitmap_create (&bitmap2, bitmapwidth, bitmapheight, + bitmap_format) !=3D GRUB_ERR_NONE) + { + grub_video_bitmap_destroy (bitmap1); + return; + } + + int offset; + int x; + int y; + grub_uint8_t *data; + + offset =3D 0; + data =3D grub_video_bitmap_get_data (bitmap1); + for (y =3D 0; y < bitmapheight; y++) + { + for (x =3D 0; x < bitmapwidth; x++) + { + data[offset++] =3D x ^ y; /* red */ + data[offset++] =3D (x * 3) ^ (y * 3); /* green */ + data[offset++] =3D (x * 2) ^ (y * 2); /* blue */ + if (config->use_rgba_bitmaps) + data[offset++] =3D 255; + } + } + + offset =3D 0; + data =3D grub_video_bitmap_get_data (bitmap2); + for (y =3D 0; y < bitmapheight; y++) + { + for (x =3D 0; x < bitmapwidth; x++) + { + data[offset++] =3D x + y; /* red */ + data[offset++] =3D x * x + y * y; /* green */ + data[offset++] =3D x * x / 4 + y * y / 4; /* blue */ + if (config->use_rgba_bitmaps) + data[offset++] =3D 255; + } + } + + + /* Now do the blit test, alternating between the two bitmaps. */ + frame_count =3D 0; + start_time =3D grub_get_time_ms (); + desired_stop_time =3D start_time + vt_opts->test_time * 1000; + + int cur =3D 0; /* Which bitmap to draw this frame. */ + while (grub_get_time_ms () < desired_stop_time && grub_checkkey () =3D= =3D -1) + { + struct grub_video_bitmap *current_bitmap =3D cur =3D=3D 0 ? bitmap1 = : bitmap2; + grub_video_blit_bitmap (current_bitmap, + GRUB_VIDEO_BLIT_REPLACE, + view.x, view.y, 0, 0, bitmapwidth, + bitmapheight); + grub_video_swap_buffers (); + frame_count++; + cur ^=3D 1; + } + if (grub_checkkey () !=3D -1) + grub_getkey (); /* Eat the keypress, if there was once. */ + + /* Calculate average frame rate. */ + duration =3D grub_get_time_ms () - start_time; + if (duration =3D=3D 0) + { + result->blit_fps =3D 0; + } + else + { + result->blit_fps =3D + (BENCHMARK_RESULT_FPS_SCALE * 1000 + * frame_count / duration); + } + + grub_video_bitmap_destroy (bitmap2); + grub_video_bitmap_destroy (bitmap1); + + + + /*** BLEND TEST ***/ + + /* Generate two bitmaps, with alpha translucency. */ + const int bbw =3D view.width * 2 / 3; + const int bbh =3D view.height * 2 / 3; + + if (grub_video_bitmap_create (&bitmap1, bbw, bbh, + GRUB_VIDEO_BLIT_FORMAT_RGBA_8888) !=3D + GRUB_ERR_NONE) + return; + + if (grub_video_bitmap_create (&bitmap2, bbw, bbh, + GRUB_VIDEO_BLIT_FORMAT_RGBA_8888) !=3D + GRUB_ERR_NONE) + { + grub_video_bitmap_destroy (bitmap1); + return; + } + + offset =3D 0; + data =3D grub_video_bitmap_get_data (bitmap1); + for (y =3D 0; y < bbh; y++) + { + for (x =3D 0; x < bbw; x++) + { + /* Calculate a to be increasing away from the center. */ + int dx =3D 256 * (x - bbw / 2) / (bbw / 2); + int dy =3D 256 * (y - bbh / 2) / (bbh / 2); + int a =3D dx * dx + dy * dy; + /* range for a =3D 0 .. 2*(256^2) =3D 2*2^16 =3D 2^17 */ + a >>=3D 17 - 8; /* Make range 0..256. */ + if (a > 255) + a =3D 255; + + data[offset++] =3D x ^ y; /* red */ + data[offset++] =3D (x * 3) ^ (y * 3); /* green */ + data[offset++] =3D (x * 2) ^ (y * 2); /* blue */ + data[offset++] =3D 255 - a; + } + } + + offset =3D 0; + data =3D grub_video_bitmap_get_data (bitmap2); + for (y =3D 0; y < bbh; y++) + { + for (x =3D 0; x < bbw; x++) + { + data[offset++] =3D x + y; /* red */ + data[offset++] =3D x * x + y * y; /* green */ + data[offset++] =3D x * x / 4 + y * y / 4; /* blue */ + data[offset++] =3D 255; + } + } + + frame_count =3D 0; + start_time =3D grub_get_time_ms (); + desired_stop_time =3D start_time + vt_opts->test_time * 1000; + + + grub_video_color_t bgcolor =3D grub_video_map_rgb (80, 80, 80); + + /* Bitmap locations. */ + int b1x =3D 0; + int b1y =3D 0; + int b2x =3D view.width - bbw; + int b2y =3D 0; + /* Bitmap velocities. */ + int b1vx =3D 8; + int b1vy =3D 12; + int b2vx =3D -10; + int b2vy =3D 9; + + while (grub_get_time_ms () < desired_stop_time && grub_checkkey () =3D= =3D -1) + { + move_rectangle_one_step (&b1x, &b1y, bbw, bbh, &b1vx, &b1vy, &view); + move_rectangle_one_step (&b2x, &b2y, bbw, bbh, &b2vx, &b2vy, &view); + grub_video_fill_rect (bgcolor, view.x, view.y, view.width, view.heig= ht); + grub_video_blit_bitmap (bitmap2, + GRUB_VIDEO_BLIT_BLEND, + b2x, b2y, 0, 0, bbw, bbh); + grub_video_blit_bitmap (bitmap1, + GRUB_VIDEO_BLIT_BLEND, + b1x, b1y, 0, 0, bbw, bbh); + grub_video_swap_buffers (); + frame_count++; + cur ^=3D 1; + } + if (grub_checkkey () !=3D -1) + grub_getkey (); /* Eat the keypress, if there was once. */ + + /* Calculate average frame rate. */ + duration =3D grub_get_time_ms () - start_time; + if (duration =3D=3D 0) + { + result->blend_fps =3D 0; + } + else + { + result->blend_fps =3D + (BENCHMARK_RESULT_FPS_SCALE * 1000 + * frame_count / duration); + } + + grub_video_bitmap_destroy (bitmap2); + grub_video_bitmap_destroy (bitmap1); + + grub_video_restore (); + result->test_passed =3D 1; +} + +/** + * Run a benchmark test in a series of video modes. + * The results are reported in tabular form. This will be helpful to + * determine how effective various optimizations are. + */ +static void +benchmark_test (struct videotest_options *vt_opts) +{ + unsigned int i; + struct benchmark_result results[NUM_BENCHMARK_CONFIGS]; + + /* Set option default values. */ + if (vt_opts->test_time =3D=3D 0) + vt_opts->test_time =3D DEFAULT_TEST_TIME; + + /* Run benchmarks. */ + for (i =3D 0; i < NUM_BENCHMARK_CONFIGS; i++) + { + grub_error_push (); + do_benchmark (&benchmark_configs[i], &results[i], vt_opts); + } + + grub_print_error (); + + /* Display results. */ + grub_printf ("Benchmark results (in frames/s):\n"); + grub_printf ("(W=3DWidth, H=3DHeight, B=3DBits per pixel,\n" + " T=3DMode Type, A=3DBitmap Alpha)\n"); + grub_printf (" W H B T A FILL BLIT BLEND\n"); + for (i =3D 0; i < NUM_BENCHMARK_CONFIGS; i++) + { + struct benchmark_config *c =3D &benchmark_configs[i]; + struct benchmark_result *r =3D &results[i]; + + if (r->test_passed) + { + grub_printf ("%4dx%4d %2d %d %d: %4d.%d %4d.%d %4d.%d\n", + c->width, c->height, r->bpp, + c->mode_type & 0x0F, + c->use_rgba_bitmaps, + r->fill_fps / BENCHMARK_RESULT_FPS_SCALE, + r->fill_fps % BENCHMARK_RESULT_FPS_SCALE, + r->blit_fps / BENCHMARK_RESULT_FPS_SCALE, + r->blit_fps % BENCHMARK_RESULT_FPS_SCALE, + r->blend_fps / BENCHMARK_RESULT_FPS_SCALE, + r->blend_fps % BENCHMARK_RESULT_FPS_SCALE); + } + else + { + grub_printf ("%4dx%4d %2d %d Not supported.\n", + c->width, c->height, + ((c->mode_type & GRUB_VIDEO_MODE_TYPE_DEPTH_MASK) + >> GRUB_VIDEO_MODE_TYPE_DEPTH_POS), + c->mode_type & 0x0F); + } + } + + grub_errno =3D GRUB_ERR_NONE; +} +=0C + +/** + * Test time functions. + */ +static void +clock_test (struct videotest_options *vt_opts) +{ + int mode_type =3D GRUB_VIDEO_MODE_TYPE_RGB; + if (vt_opts->double_buffering) + mode_type |=3D GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED; + if (grub_video_setup (640, 480, mode_type) !=3D GRUB_ERR_NONE) + return; + + grub_video_rect_t view; + grub_video_get_viewport ((unsigned *) &view.x, (unsigned *) &view.y, + (unsigned *) &view.width, + (unsigned *) &view.height); + + grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); + + /* Draw a progress bar that animates in sync with time. */ + + grub_video_rect_t bar_frame; + bar_frame.width =3D view.width - 2 * view.width / 10; + bar_frame.height =3D view.height / 20; + bar_frame.x =3D view.x + view.width / 10; + bar_frame.y =3D view.y + view.height - bar_frame.height - view.height / = 10; + + grub_video_color_t bgcolor =3D grub_video_map_rgb (50, 50, 50); + grub_video_color_t framecolor =3D grub_video_map_rgb (255, 255, 255); + grub_video_color_t barbgcolor =3D grub_video_map_rgb (0, 0, 128); + grub_video_color_t barcolor =3D grub_video_map_rgb (100, 100, 255); + + grub_uint32_t frame_count; + grub_uint64_t start_time; + grub_uint64_t barstart; + grub_uint32_t barlength =3D 1000; + + grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); + + frame_count =3D 0; + start_time =3D grub_get_time_ms (); + barstart =3D grub_get_time_ms (); + + while (grub_checkkey () =3D=3D -1) + { + grub_uint64_t now; + grub_uint32_t bartime; + now =3D grub_get_time_ms (); + /* If the time limit option is set, then check if it's exceeded. */ + if (vt_opts->test_time !=3D 0 + && now >=3D start_time + vt_opts->test_time * 1000) + break; + bartime =3D now - barstart; + if (bartime > barlength) + { + barstart =3D grub_get_time_ms (); /* Start over. */ + bartime =3D barlength; + } + + /* Clear screen. */ + grub_video_fill_rect (bgcolor, view.x, view.y, view.width, view.heig= ht); + + /* Border. */ + grub_video_fill_rect (framecolor, + bar_frame.x - 1, bar_frame.y - 1, + bar_frame.width + 2, bar_frame.height + 2); + + /* Bar background. */ + int barwidth =3D bar_frame.width * bartime / barlength; + grub_video_fill_rect (barbgcolor, bar_frame.x + barwidth, + bar_frame.y, bar_frame.width - barwidth, + bar_frame.height); + /* Bar foreground. */ + grub_video_fill_rect (barcolor, bar_frame.x, bar_frame.y, + barwidth, bar_frame.height); + grub_video_swap_buffers (); + frame_count++; + } + + grub_uint32_t duration =3D grub_get_time_ms () - start_time; + grub_uint32_t fps_x10 =3D 10 * 1000 * frame_count / duration; + + if (grub_checkkey () !=3D -1) + grub_getkey (); /* Eat the keypress, if there was one. */ + grub_video_restore (); + grub_printf ("Average frame rate: %d.%d fps\n", fps_x10 / 10, fps_x10 % = 10); +} +=0C + +/** + * Test double buffering. + */ +static void +doublebuf_test (struct videotest_options *vt_opts) +{ + int mode_type =3D GRUB_VIDEO_MODE_TYPE_RGB; + if (vt_opts->double_buffering) + mode_type |=3D GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED; + if (grub_video_setup (640, 480, mode_type) !=3D GRUB_ERR_NONE) + return; + + grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); + + grub_video_color_t red =3D grub_video_map_rgb (255, 50, 50); + grub_video_color_t yellow =3D grub_video_map_rgb (255, 255, 0); + grub_video_color_t green =3D grub_video_map_rgb (20, 255, 20); + grub_video_color_t blue =3D grub_video_map_rgb (50, 50, 255); + grub_video_color_t black =3D grub_video_map_rgb (0, 0, 0); + grub_video_color_t bgcolor =3D grub_video_map_rgb (255, 255, 255); + + grub_video_fill_rect (bgcolor, 0, 0, 640, 480); + grub_video_fill_rect (red, 100, 100, 200, 200); + grub_video_swap_buffers (); + grub_getkey (); + + grub_video_fill_rect (bgcolor, 0, 0, 640, 480); + grub_video_fill_rect (yellow, 120, 120, 200, 200); + grub_video_swap_buffers (); + grub_getkey (); + + grub_video_fill_rect (bgcolor, 0, 0, 640, 480); + grub_video_fill_rect (green, 140, 140, 200, 200); + grub_video_swap_buffers (); + grub_getkey (); + + grub_video_fill_rect (bgcolor, 0, 0, 640, 480); + grub_video_fill_rect (blue, 160, 160, 200, 200); + grub_video_swap_buffers (); + grub_getkey (); + + grub_video_fill_rect (bgcolor, 0, 0, 640, 480); + grub_video_fill_rect (black, 180, 180, 200, 200); + grub_video_swap_buffers (); + grub_getkey (); + + grub_video_restore (); +} +=0C + +/** + * Test text rendering. + */ +static void +text_test (struct videotest_options *vt_opts) +{ + grub_video_color_t color; + const char *s; + int view_x; + int view_y; + int view_width; + int view_height; + int xpos; + int ypos; + int i; + grub_font_t font1; + grub_font_t font2; + grub_font_t font3; + grub_font_t sansbig; + grub_font_t sans; + grub_font_t sanssmall; + grub_font_t fixed; + + int mode_type =3D GRUB_VIDEO_MODE_TYPE_RGB; + if (vt_opts->double_buffering) + mode_type |=3D GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED; + if (grub_video_setup (1024, 768, mode_type) !=3D GRUB_ERR_NONE) + return; + + grub_video_get_viewport ((unsigned int *) &view_x, + (unsigned int *) &view_y, + (unsigned int *) &view_width, + (unsigned int *) &view_height); + grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); + + if (!(font1 =3D grub_font_get ("New Century Schoolbook 24")) + || !(font2 =3D grub_font_get ("Helvetica Bold 14")) + || !(font3 =3D grub_font_get ("Helvetica 10")) + || !(sansbig =3D grub_font_get ("Helvetica Bold 24")) + || !(sans =3D grub_font_get ("Helvetica Bold 14")) + || !(sanssmall =3D grub_font_get ("Helvetica 8")) + || !(fixed =3D grub_font_get ("Fixed 20"))) + { + grub_video_restore (); + grub_error (GRUB_ERR_BAD_FONT, "No font loaded."); + return; + } + + color =3D grub_video_map_rgb (0, 0, 0); + grub_video_fill_rect (color, 0, 0, view_width, view_height); + + color =3D grub_video_map_rgb (255, 0, 0); + grub_video_fill_rect (color, 0, 0, 100, 100); + + color =3D grub_video_map_rgb (0, 255, 255); + grub_video_fill_rect (color, 100, 100, 100, 100); + + color =3D grub_video_map_rgb (255, 255, 255); + + xpos =3D 10; + ypos =3D 30; + s =3D "Hello, World!"; + for (i =3D 0; i < 24; i++) + { + if (xpos + grub_font_get_string_width (font1, s) >=3D view_width) + { + /* The string will wrap; go to the beginning of the next line. = */ + xpos =3D 10; + ypos +=3D (grub_font_get_descent (font1) + + grub_font_get_ascent (font1)); + } + grub_font_draw_string ("Hello, World!", + font1, grub_video_map_rgb (255, 255, 0), + xpos, ypos); + + xpos +=3D grub_font_get_string_width (font1, s); + } + + xpos =3D 240; + ypos =3D 280; + grub_font_draw_string (grub_font_get_name (font1), + font1, grub_video_map_rgb (255, 255, 255), + xpos, ypos); + ypos +=3D grub_font_get_descent (font1) + grub_font_get_ascent (font2) += 2; + grub_font_draw_string (grub_font_get_name (font2), + font2, grub_video_map_rgb (255, 255, 255), + xpos, ypos); + ypos +=3D grub_font_get_descent (font2) + grub_font_get_ascent (font3) += 2; + grub_font_draw_string (grub_font_get_name (font3), + font3, grub_video_map_rgb (255, 255, 255), + xpos, ypos); + + ypos +=3D 40; /* Spacing. */ + + grub_font_draw_string ("The quick brown fox jumped over the lazy dog.", + sans, color, view_x + 16, ypos); + ypos +=3D grub_font_get_descent (sans) + grub_font_get_leading (sans); + + ypos +=3D grub_font_get_ascent (fixed); + grub_font_draw_string ("The quick brown fox jumped over the lazy dog.", + fixed, color, 16, ypos); + ypos +=3D grub_font_get_descent (fixed) + grub_font_get_leading (fixed); + + ypos +=3D 40; /* Spacing. */ =20 /* To convert Unicode characters into UTF-8 for this test, the following command is useful: @@ -115,78 +1044,254 @@ U+2287 subset symbol E2 8A 87 U+211D set 'R' symbol (real numbers) E2 84 9D */ =20 - str =3D + s =3D "Unicode test: happy\xE2\x98\xBA \xC2\xA3 5.00" " \xC2\xA1\xCF\x84\xC3\xA4u! " " \xE2\x84\xA4\xE2\x8A\x87\xE2\x84\x9D"; color =3D grub_video_map_rgb (128, 128, 255); =20 /* All characters in the string exist in the 'Fixed 20' (10x20) font. */ - texty +=3D grub_font_get_ascent(fixed); - grub_font_draw_string (str, fixed, color, 16, texty); - texty +=3D grub_font_get_descent (fixed) + grub_font_get_leading (fixed); - - /* Some character don't exist in the Helvetica font, so the font engine - will fall back to using glyphs from another font that does contain th= em. - TODO The font engine should be smart about selecting a replacement fo= nt - and prioritize fonts with similar sizes. */ - - texty +=3D grub_font_get_ascent(sansbig); - grub_font_draw_string (str, sansbig, color, 16, texty); - texty +=3D grub_font_get_descent (sansbig) + grub_font_get_leading (sans= big); - - texty +=3D grub_font_get_ascent(sans); - grub_font_draw_string (str, sans, color, 16, texty); - texty +=3D grub_font_get_descent (sans) + grub_font_get_leading (sans); - - texty +=3D grub_font_get_ascent(sanssmall); - grub_font_draw_string (str, sanssmall, color, 16, texty); - texty +=3D (grub_font_get_descent (sanssmall) + ypos +=3D grub_font_get_ascent (fixed); + grub_font_draw_string (s, fixed, color, 16, ypos); + ypos +=3D grub_font_get_descent (fixed) + grub_font_get_leading (fixed); + + /* Some characters don't exist in the Helvetica font, so the font engine + may fall back to using glyphs from another font that has them. */ + + ypos +=3D grub_font_get_ascent (sansbig); + grub_font_draw_string (s, sansbig, color, 16, ypos); + ypos +=3D grub_font_get_descent (sansbig) + grub_font_get_leading (sansb= ig); + + ypos +=3D grub_font_get_ascent (sans); + grub_font_draw_string (s, sans, color, 16, ypos); + ypos +=3D grub_font_get_descent (sans) + grub_font_get_leading (sans); + + ypos +=3D grub_font_get_ascent (sanssmall); + grub_font_draw_string (s, sanssmall, color, 16, ypos); + ypos +=3D (grub_font_get_descent (sanssmall) + grub_font_get_leading (sanssmall)); =20 - glyph =3D grub_font_get_glyph (fixed, '*'); - - for (i =3D 0; i < 16; i++) - { - color =3D grub_video_map_color (i); - palette[i] =3D color; - grub_font_draw_glyph (glyph, color, 16 + i * 16, 220); - } + + grub_video_swap_buffers (); + grub_getkey (); + grub_video_restore (); + grub_errno =3D GRUB_ERR_NONE; +} +=0C + +/** + * Test bitmap scaling. + */ +static void +scale_test (struct videotest_options *vt_opts) +{ + int mode_type =3D GRUB_VIDEO_MODE_TYPE_RGB; + if (vt_opts->double_buffering) + mode_type |=3D GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED; + if (grub_video_setup (1024, 768, mode_type) !=3D GRUB_ERR_NONE) + return; + + grub_errno =3D GRUB_ERR_NONE; + grub_video_rect_t view; + grub_video_get_viewport ((unsigned *) &view.x, (unsigned *) &view.y, + (unsigned *) &view.width, + (unsigned *) &view.height); =20 grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); =20 - for (i =3D 0; i < 255; i++) - { - color =3D grub_video_map_rgb (i, 33, 77); - grub_video_fill_rect (color, 0, 0, width, height); - grub_video_blit_render_target (text_layer, GRUB_VIDEO_BLIT_BLEND, 0,= 0, - 0, 0, width, height); - } - + grub_font_t font; + if (!(font =3D grub_font_get ("Helvetica 10"))) + { + grub_video_restore (); + grub_error (GRUB_ERR_BAD_FONT, "No font loaded."); + return; + } + + grub_video_color_t color; + + int text_y =3D 0; + int text_height =3D 25; + + color =3D grub_video_map_rgb (44, 44, 200); + grub_video_fill_rect (color, view.x, view.y, view.width, view.height); + color =3D grub_video_map_rgb (255, 255, 255); + + grub_font_draw_string ("Loading image", + font, color, 10, text_y +=3D text_height); + + enum grub_video_bitmap_scale_method scale_method =3D + GRUB_VIDEO_BITMAP_SCALE_METHOD_BEST; + const char *bitmap_name =3D "/boot/grub/themes/winter/without-leaves.png= "; + struct grub_video_bitmap *bitmap; + grub_video_bitmap_load (&bitmap, bitmap_name); + if (grub_errno !=3D GRUB_ERR_NONE) + { + grub_font_draw_string ("Error loading bitmap", + font, color, 10, text_y +=3D text_height); + } + else + { + grub_font_draw_string ("Original image", + font, color, 10, text_y +=3D text_height); + grub_video_blit_bitmap (bitmap, GRUB_VIDEO_BLIT_BLEND, + 400, text_y - 10, + 0, 0, grub_video_bitmap_get_width (bitmap), + grub_video_bitmap_get_height (bitmap)); + + struct grub_video_bitmap *bitmap2; + if (grub_video_bitmap_create_scaled (&bitmap2, 40, 40, + bitmap, + scale_method) + !=3D GRUB_ERR_NONE) + { + grub_font_draw_string ("Error scaling down bitmap", + font, color, 10, text_y +=3D text_height); + } + else + { + grub_font_draw_string ("Scaled down version", + font, color, 10, text_y +=3D text_height); + grub_video_blit_bitmap (bitmap2, GRUB_VIDEO_BLIT_BLEND, + 400, text_y + 100, + 0, 0, grub_video_bitmap_get_width (bitma= p2), + grub_video_bitmap_get_height (bitmap2)); + grub_video_bitmap_destroy (bitmap2); + } + + struct grub_video_bitmap *bitmap3; + if (grub_video_bitmap_create_scaled (&bitmap3, 500, 300, bitmap, + scale_method) + !=3D GRUB_ERR_NONE) + { + grub_font_draw_string ("Error scaling up bitmap", + font, color, 10, text_y +=3D text_height); + } + else + { + grub_font_draw_string ("Scaled up version", + font, color, 10, text_y +=3D text_height); + grub_video_blit_bitmap (bitmap3, GRUB_VIDEO_BLIT_BLEND, + 400, text_y + 50, + 0, 0, grub_video_bitmap_get_width (bitma= p3), + grub_video_bitmap_get_height (bitmap3)); + grub_video_bitmap_destroy (bitmap3); + } + } + + grub_video_swap_buffers (); grub_getkey (); - - grub_video_delete_render_target (text_layer); - + grub_video_bitmap_destroy (bitmap); grub_video_restore (); - - for (i =3D 0; i < 16; i++) - grub_printf("color %d: %08x\n", i, palette[i]); - - grub_errno =3D GRUB_ERR_NONE; +} +=0C + +/** Print a list of the available tests. */ +static void list_tests (void); + +/** + * Video test command. Takes an argument specifying the test to run. + */ +static grub_err_t +grub_cmd_videotest (struct grub_arg_list *state, int argc, char **args) +{ + int i; + struct videotest_options vt_opts; + /* Pointer to the test function. */ + void (*test_func) (struct videotest_options *) =3D NULL; + + vt_opts.test_time =3D + state[ARGINDEX_TEST_TIME].set + ? grub_strtoul (state[ARGINDEX_TEST_TIME].arg, 0, 0) : 0; + vt_opts.double_buffering =3D state[ARGINDEX_DOUBLE_BUF].set; + + /* Parse command line arguments to determine the test to run. */ + for (i =3D 0; i < argc; i++) + { + char *arg =3D args[i]; + if (grub_strcmp (arg, "list") =3D=3D 0) + { + list_tests (); + return GRUB_ERR_NONE; + } + else if (grub_strcmp (arg, "basic") =3D=3D 0) + { + test_func =3D basic_video_test; + } + else if (grub_strcmp (arg, "bench") =3D=3D 0) + { + test_func =3D benchmark_test; + } + else if (grub_strcmp (arg, "bitmaps") =3D=3D 0) + { + test_func =3D bitmap_demo; + } + else if (grub_strcmp (arg, "clock") =3D=3D 0) + { + test_func =3D clock_test; + } + else if (grub_strcmp (arg, "doublebuf") =3D=3D 0) + { + test_func =3D doublebuf_test; + } + else if (grub_strcmp (arg, "text") =3D=3D 0) + { + test_func =3D text_test; + } + else if (grub_strcmp (arg, "scale") =3D=3D 0) + { + test_func =3D scale_test; + } + else + { + grub_printf ("Error: Unknown test `%s'\n", arg); + grub_errno =3D GRUB_ERR_BAD_ARGUMENT; + return grub_errno; + } + } + + if (test_func =3D=3D NULL) + { + grub_printf ("Usage: videotest TESTNAME Run a test.\n"); + grub_printf (" videotest list List available tests.\n"); + grub_printf ("\n"); + list_tests (); + } + else + { + test_func (&vt_opts); + } + return grub_errno; } =20 -GRUB_MOD_INIT(videotest) +static void +list_tests (void) +{ + grub_printf ("Available tests\n"); + grub_printf ("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n"); + grub_printf ("basic Basic video test with filled rectangles,\n"); + grub_printf (" offscreen rendering targets, some text.\n"); + grub_printf ("bench Run a performance benchmark.\n"); + grub_printf ("bitmaps Test generating and blitting bitmaps.\n"); + grub_printf ("clock Test time functions w/ animated progress bar.\= n"); + grub_printf ("doublebuf Test double buffering.\n"); + grub_printf ("text Test text rendering.\n"); + grub_printf ("scale Test image scaling.\n"); + grub_printf ("\n"); +} + + +GRUB_MOD_INIT (videotest) { grub_register_command ("videotest", grub_cmd_videotest, GRUB_COMMAND_FLAG_BOTH, - "videotest", - "Test video subsystem", - 0); + "videotest TEST", + "Run the specified video subsystem test.", + arg_options); } =20 -GRUB_MOD_FINI(videotest) +GRUB_MOD_FINI (videotest) { grub_unregister_command ("videotest"); } =3D=3D=3D modified file 'include/grub/video.h' --- include/grub/video.h 2008-10-30 07:03:25 +0000 +++ include/grub/video.h 2008-10-30 18:26:46 +0000 @@ -159,6 +159,16 @@ grub_uint8_t a; /* Reserved bits value (0-255). */ }; =20 +/* A 2D rectangle type. */ +struct grub_video_rect +{ + int x; + int y; + int width; + int height; +}; +typedef struct grub_video_rect grub_video_rect_t; + struct grub_video_adapter { /* The video adapter name. */ --MP_//=857D__Bt=SPy15N=AG+87-- --Sig_/LldYPZA.P+5uWlvje=Tt7mc Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkKCxgACgkQokx8fzcGbYeCFgCgkDJY0vmAO40t3qcl008GLbUL z5IAnRaq6fdj0dRcsmtR8xncNucxHrh7 =EL7M -----END PGP SIGNATURE----- --Sig_/LldYPZA.P+5uWlvje=Tt7mc-- From MAILER-DAEMON Thu Oct 30 23:59:14 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KvlAI-0006Kd-7L for mharc-grub-devel@gnu.org; Thu, 30 Oct 2008 23:59:14 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KvlAG-0006JB-5F for grub-devel@gnu.org; Thu, 30 Oct 2008 23:59:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvlAE-0006Hg-RD for grub-devel@gnu.org; Thu, 30 Oct 2008 23:59:11 -0400 Received: from [199.232.76.173] (port=42052 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvlAE-0006HR-KB for grub-devel@gnu.org; Thu, 30 Oct 2008 23:59:10 -0400 Received: from gateway16.websitewelcome.com ([69.56.148.23]:50060) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KvlAD-0003Lm-Dk for grub-devel@gnu.org; Thu, 30 Oct 2008 23:59:10 -0400 Received: (qmail 4055 invoked from network); 31 Oct 2008 04:10:56 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway16.websitewelcome.com with SMTP; 31 Oct 2008 04:10:56 -0000 Received: from c-67-185-177-95.hsd1.wa.comcast.net ([67.185.177.95]:60067 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KvlA1-00086i-HQ; Thu, 30 Oct 2008 22:58:57 -0500 Date: Thu, 30 Oct 2008 20:57:36 -0700 From: Colin D Bennett To: grub-devel@gnu.org, Vesa =?UTF-8?Q?J=C3=A4=C3=A4skel=C3=A4inen?= Message-ID: <20081030205736.7e080a5e@gibibit.com> In-Reply-To: <20081030121106.4efffecc@gibibit.com> References: <20080901092753.3918cf73@gamma.lan> <20081004214640.5ab21f53@gibibit.com> <48E87FB9.8070603@nic.fi> <20081030121106.4efffecc@gibibit.com> X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/5JJPp8f2UUZ.fQ3Lqt3ogW+"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: Subject: Re: [PATCH] GSoC #10 new font engine (UTF-8 support+bugfix) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 03:59:12 -0000 --Sig_/5JJPp8f2UUZ.fQ3Lqt3ogW+ Content-Type: multipart/mixed; boundary="MP_/gl5hFA.k5o19toXYw/TFnHO" --MP_/gl5hFA.k5o19toXYw/TFnHO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Update:=20 I fixed an error pointed out to me by Y.Volta:=20 In grub_font_get(), if no fonts are loaded, a null pointer is dereferenced. This is fixed in the attached patch. The grub_font_get() function now returns a dummy font object (a statically allocated font object with no characters) so that callers of grub_font_get() can be assured that the return value will never be NULL. If no fonts are loaded, then the "unknown glyph" will be used for all characters, but it will be safe. Regards, Colin --MP_/gl5hFA.k5o19toXYw/TFnHO Content-Type: text/x-patch; name=10_font-engine-utf8_2008-10-30.patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=10_font-engine-utf8_2008-10-30.patch 2008-10-30 Colin D Bennett New font engine supporting large and proportional fonts, PFF2 file format. * commands/videotest.c (grub_cmd_videotest): Use new font API, test drawing UTF-8 Unicode text. * conf/common.rmk (font_mod_SOURCES): Update source file list. * font/font.c: New file. * font/font_cmd.c: New file. * font/manager.c: Deleted. * include/grub/font.h: Update copyright years. (GRUB_FONT_MAGIC): Removed. (grub_font): New forward declaration of struct. (grub_font_t): New typedef. (grub_font_node): New struct. (grub_font_list): New global symbol. (grub_font_glyph): Updated data structure to support larger, variable size fonts and to support font metrics. (grub_font_glyph_t): Removed. (grub_font_loader_init): New prototype. (grub_font_load): New prototype. (grub_font_get): New prototype. (grub_font_get_name): New prototype. (grub_font_get_max_char_width): New prototype. (grub_font_get_max_char_height): New prototype. (grub_font_get_ascent): New prototype. (grub_font_get_descent): New prototype. (grub_font_get_leading): New prototype. (grub_font_get_height): New prototype. (grub_font_get_string_width): New prototype. (grub_font_load): New prototype. (grub_font_get_glyph): New prototype. (grub_font_get_glyph_with_fallback): New prototype. (grub_font_draw_glyph): New prototype. (grub_font_draw_string): New prototype. * include/grub/misc.h (grub_utf8_to_ucs4): Added parameters. * include/grub/video.h (grub_font_glyph): Removed forward struct declaration. (GRUB_VIDEO_MODE_TYPE_ALPHA): Changed bit mask value to make space for 1BIT_BITMAP. (GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED): Likewise. (GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP): New bit mask constant. (GRUB_VIDEO_MODE_TYPE_COLOR_MASK): Updated to a wider mask to make space for 1BIT_BITMAP. (GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED): New blit format enum value. (grub_video_mode_info): Added bg_red, bg_green, bg_blue, bg_alpha, fg_red, fg_green, fg_blue, and fg_alpha fields. * kern/misc.c (grub_utf8_to_ucs4): Support null-terminated UTF-8 strings and allow limiting the number of Unicode characters decoded. * kern/term.c (grub_putchar): Pass additional arguments to grub_utf8_to_ucs4. * normal/menu.c (print_entry): Pass destination maximum length to grub_utf8_to_ucs4. * term/gfxterm.c (DEFAULT_CHAR_WIDTH): Removed. (DEFAULT_CHAR_HEIGHT): Removed. (grub_virtual_screen): Added font field. (grub_virtual_screen_setup): Add font_name parameter. Initialize terminal font information. (grub_gfxterm_init): Get font name from gfxterm_font environment variable. Pass font name to grub_virtual_screen_setup. (write_char): Place glyphs using their baseline, based on the font ascent. (write_cursor): Draw cursor using font ascent as a reference. (grub_gfxterm_putchar): Use new font API. Breaks bi-width font support. (grub_gfxterm_getcharwidth): Assume all characters are 1 character in width. Breaks bi-width font support. (grub_vga_getcharwidth): Always return a width of 1. * term/i386/pc/vesafb.c (grub_virtual_screen_get_glyph): Use new font API. Breaks vesafb glyph drawing, since it copied the glyph data directly, but now glyphs use a different storage format. This code shouldn't compile, but GRUB builds ok! * term/i386/pc/vga.c (font): New static variable. (grub_vga_mod_init): Get a font using the new font API. (write_char): Broken. Commented out code with #if 0 since it will need to be rewritten to handle the new glyph storage format if we want to maintain the vga terminal. (grub_vga_putchar): Update to use new font API; breaks support for bi-width fonts. * video/i386/pc/vbe.c (grub_video_vbe_map_rgb): Support GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP. (grub_video_vbe_map_rgba): Likewise. (grub_video_vbe_unmap_color_int): Likewise. (grub_video_vbe_blit_glyph): Deleted. (grub_video_vbe_adapter): Deleted blit_glyph member. * video/i386/pc/vbeutil.c (get_data_ptr): Add a comment to the switch statement indicating why it is unimplemented for 1-bit bitmaps. (get_pixel): Support 1-bit bitmaps. (set_pixel): Support 1-bit bitmaps. =09 * video/video.c (grub_video_blit_glyph): Renamed coordinate arguments for clarity. (grub_video_draw_string): New function. =3D=3D=3D modified file 'commands/videotest.c' --- commands/videotest.c 2007-07-21 22:32:33 +0000 +++ commands/videotest.c 2008-10-31 03:46:58 +0000 @@ -1,6 +1,6 @@ /* * GRUB -- GRand Unified Bootloader - * Copyright (C) 2006,2007 Free Software Foundation, Inc. + * Copyright (C) 2006,2007,2008 Free Software Foundation, Inc. * * GRUB is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -36,17 +36,21 @@ GRUB_VIDEO_MODE_TYPE_INDEX_COLOR) !=3D GRUB_ERR_NO= NE) return grub_errno; =20 - grub_getkey (); - grub_video_color_t color; unsigned int x; unsigned int y; unsigned int width; unsigned int height; int i; - struct grub_font_glyph glyph; + grub_font_t sansbig; + grub_font_t sans; + grub_font_t sanssmall; + grub_font_t fixed; + struct grub_font_glyph *glyph; struct grub_video_render_target *text_layer; grub_video_color_t palette[16]; + const char *str; + int texty; =20 grub_video_get_viewport (&x, &y, &width, &height); =20 @@ -65,8 +69,15 @@ color =3D grub_video_map_rgb (0, 255, 255); grub_video_fill_rect (color, 100, 100, 100, 100); =20 - grub_font_get_glyph ('*', &glyph); =20 - grub_video_blit_glyph (&glyph, color, 200 ,0); + sansbig =3D grub_font_get ("Helvetica Bold 24"); + sans =3D grub_font_get ("Helvetica Bold 14"); + sanssmall =3D grub_font_get ("Helvetica 8"); + fixed =3D grub_font_get ("Fixed 20"); + if (! sansbig || ! sans || ! sanssmall || ! fixed) + return grub_error (GRUB_ERR_BAD_FONT, "No font loaded."); + + glyph =3D grub_font_get_glyph (fixed, '*'); + grub_font_draw_glyph (glyph, color, 200 ,0); =20 grub_video_set_viewport (x + 150, y + 150, width - 150 * 2, height - 150 * 2); @@ -77,18 +88,69 @@ =20 color =3D grub_video_map_rgb (255, 255, 255); =20 - grub_font_get_glyph ('A', &glyph); - grub_video_blit_glyph (&glyph, color, 16, 16); - grub_font_get_glyph ('B', &glyph); - grub_video_blit_glyph (&glyph, color, 16 * 2, 16); - - grub_font_get_glyph ('*', &glyph); + texty =3D 32; + grub_font_draw_string ("The quick brown fox jumped over the lazy dog.", + sans, color, 16, texty); + texty +=3D grub_font_get_descent (sans) + grub_font_get_leading (sans); + + texty +=3D grub_font_get_ascent (fixed); + grub_font_draw_string ("The quick brown fox jumped over the lazy dog.", + fixed, color, 16, texty); + texty +=3D grub_font_get_descent (fixed) + grub_font_get_leading (fixed); + + /* To convert Unicode characters into UTF-8 for this test, the following + command is useful: + echo -ne '\x00\x00\x26\x3A' | iconv -f UTF-32BE -t UTF-8 | od -t x1 + This converts the Unicode character U+263A to UTF-8. */ + + /* Characters used: + Code point Description UTF-8 encoding + ----------- ------------------------------ -------------- + U+263A unfilled smiley face E2 98 BA + U+00A1 inverted exclamation point C2 A1 + U+00A3 British pound currency symbol C2 A3 + U+03C4 Greek tau CF 84 + U+00E4 lowercase letter a with umlaut C3 A4 + U+2124 set 'Z' symbol (integers) E2 84 A4 + U+2287 subset symbol E2 8A 87 + U+211D set 'R' symbol (real numbers) E2 84 9D */ + + str =3D + "Unicode test: happy\xE2\x98\xBA \xC2\xA3 5.00" + " \xC2\xA1\xCF\x84\xC3\xA4u! " + " \xE2\x84\xA4\xE2\x8A\x87\xE2\x84\x9D"; + color =3D grub_video_map_rgb (128, 128, 255); + + /* All characters in the string exist in the 'Fixed 20' (10x20) font. */ + texty +=3D grub_font_get_ascent(fixed); + grub_font_draw_string (str, fixed, color, 16, texty); + texty +=3D grub_font_get_descent (fixed) + grub_font_get_leading (fixed); + + /* Some character don't exist in the Helvetica font, so the font engine + will fall back to using glyphs from another font that does contain th= em. + TODO The font engine should be smart about selecting a replacement fo= nt + and prioritize fonts with similar sizes. */ + + texty +=3D grub_font_get_ascent(sansbig); + grub_font_draw_string (str, sansbig, color, 16, texty); + texty +=3D grub_font_get_descent (sansbig) + grub_font_get_leading (sans= big); + + texty +=3D grub_font_get_ascent(sans); + grub_font_draw_string (str, sans, color, 16, texty); + texty +=3D grub_font_get_descent (sans) + grub_font_get_leading (sans); + + texty +=3D grub_font_get_ascent(sanssmall); + grub_font_draw_string (str, sanssmall, color, 16, texty); + texty +=3D (grub_font_get_descent (sanssmall) + + grub_font_get_leading (sanssmall)); + + glyph =3D grub_font_get_glyph (fixed, '*'); =20 for (i =3D 0; i < 16; i++) { color =3D grub_video_map_color (i); palette[i] =3D color; - grub_video_blit_glyph (&glyph, color, 16 + i * 16, 32); + grub_font_draw_glyph (glyph, color, 16 + i * 16, 220); } =20 grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); =3D=3D=3D modified file 'conf/common.rmk' --- conf/common.rmk 2008-09-29 13:57:05 +0000 +++ conf/common.rmk 2008-10-30 18:24:32 +0000 @@ -364,7 +364,7 @@ help_mod_LDFLAGS =3D $(COMMON_LDFLAGS) =20 # For font.mod. -font_mod_SOURCES =3D font/manager.c +font_mod_SOURCES =3D font/font_cmd.c font/font.c font_mod_CFLAGS =3D $(COMMON_CFLAGS) font_mod_LDFLAGS =3D $(COMMON_LDFLAGS) =20 =3D=3D=3D added file 'font/font.c' --- font/font.c 1970-01-01 00:00:00 +0000 +++ font/font.c 2008-10-31 03:46:01 +0000 @@ -0,0 +1,1004 @@ +/* font.c - Font API and font file loader. */ +/* + * GRUB -- GRand Unified Bootloader + * Copyright (C) 2003,2005,2006,2007,2008 Free Software Foundation, Inc. + * + * GRUB is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * GRUB is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with GRUB. If not, see . + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#ifndef FONT_DEBUG +#define FONT_DEBUG 0 +#endif + +struct char_index_entry +{ + grub_uint32_t code; + grub_uint8_t storage_flags; + grub_uint32_t offset; + struct grub_font_glyph *glyph; /* Glyph if loaded, or null. */ +}; + +#define FONT_WEIGHT_NORMAL 100 +#define FONT_WEIGHT_BOLD 200 + +struct grub_font +{ + char *name; + grub_file_t file; + char *family; + short point_size; + short weight; + short max_char_width; + short max_char_height; + short ascent; + short descent; + short leading; + grub_uint32_t num_chars; + struct char_index_entry *char_index; +}; + + +/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/ +/* Font loader */ + + +/* Definition of font registry. */ +struct grub_font_node *grub_font_list; + +static int register_font (grub_font_t font); +static void font_init (grub_font_t font); +static void free_font (grub_font_t font); +static void remove_font (grub_font_t font); + +struct font_file_section +{ + grub_file_t file; /* The file this section is in. */ + char name[4]; /* FOURCC name of the section. */ + grub_uint32_t length; /* Length of the section contents. */ + int eof; /* Set by open_section() on EOF. */ +}; + +/* Font file format constants. */ +static const char pff2_magic[4] =3D { 'P', 'F', 'F', '2' }; +static const char section_names_file[4] =3D { 'F', 'I', 'L', 'E' }; +static const char section_names_font_name[4] =3D { 'N', 'A', 'M', 'E' }; +static const char section_names_point_size[4] =3D { 'P', 'T', 'S', 'Z' }; +static const char section_names_weight[4] =3D { 'W', 'E', 'I', 'G' }; +static const char section_names_max_char_width[4] =3D { 'M', 'A', 'X', 'W'= }; +static const char section_names_max_char_height[4] =3D { 'M', 'A', 'X', 'H= ' }; +static const char section_names_ascent[4] =3D { 'A', 'S', 'C', 'E' }; +static const char section_names_descent[4] =3D { 'D', 'E', 'S', 'C' }; +static const char section_names_char_index[4] =3D { 'C', 'H', 'I', 'X' }; +static const char section_names_data[4] =3D { 'D', 'A', 'T', 'A' }; + +/* Replace unknown glyphs with a rounded question mark. */ +static grub_uint8_t unknown_glyph_bitmap[] =3D +{ + /* 76543210 */ + 0x7C, /* ooooo */ + 0x82, /* o o */ + 0xBA, /* o ooo o */ + 0xAA, /* o o o o */ + 0xAA, /* o o o o */ + 0x8A, /* o o o */ + 0x9A, /* o oo o */ + 0x92, /* o o o */ + 0x92, /* o o o */ + 0x92, /* o o o */ + 0x92, /* o o o */ + 0x82, /* o o */ + 0x92, /* o o o */ + 0x82, /* o o */ + 0x7C, /* ooooo */ + 0x00 /* */ +}; + +/* The "unknown glyph" glyph, used as a last resort. */ +static struct grub_font_glyph *unknown_glyph; +/* The font structure used when no other font is loaded. This functions + as a "Null Object" pattern, so that code everywhere does not have to + check for a NULL grub_font_t to avoid dereferencing a null pointer. */ +static struct grub_font null_font; +/* Flag to ensure module is initialized only once. */ +static grub_uint8_t font_loader_initialized; + +void +grub_font_loader_init (void) +{ + if (font_loader_initialized) + return; /* Only initialize font loader once. */ + + unknown_glyph =3D grub_malloc(sizeof(struct grub_font_glyph) + + sizeof(unknown_glyph_bitmap)); + if (! unknown_glyph) + return; + + unknown_glyph->width =3D 8; + unknown_glyph->height =3D 16; + unknown_glyph->offset_x =3D 0; + unknown_glyph->offset_y =3D 0; + unknown_glyph->device_width =3D 8; + grub_memcpy(unknown_glyph->bitmap, + unknown_glyph_bitmap, sizeof(unknown_glyph_bitmap)); + + font_init (&null_font); /* Initialize the null font. */ + null_font.name =3D ""; + null_font.ascent =3D unknown_glyph->height; + null_font.descent =3D 1; + null_font.max_char_width =3D unknown_glyph->width; + null_font.max_char_height =3D unknown_glyph->height; + + font_loader_initialized =3D 1; +} + +/* Initialize the font object with initial default values. */ +static void +font_init (grub_font_t font) +{ + font->name =3D 0; + font->file =3D 0; + font->family =3D 0; + font->point_size =3D 0; + font->weight =3D 0; + font->leading =3D 1; /* Default leading value, not in font file yet. = */ + font->max_char_width =3D 0; + font->max_char_height =3D 0; + font->ascent =3D 0; + font->descent =3D 0; + font->num_chars =3D 0; + font->char_index =3D 0; +} + +/* Open the next section in the file. + + On success, the section name is stored in section->name and the length = in + section->length, and 0 is returned. On failure, 1 is returned and + grub_errno is set approriately with an error message. + + If 1 is returned due to being at the end of the file, then section->eof= is + set to 1; otherwise, section->eof is set to 0. */ +static int +open_section (grub_file_t file, struct font_file_section *section) +{ + grub_ssize_t retval; + grub_uint32_t raw_length; + + section->file =3D file; + section->eof =3D 0; + + /* Read the FOURCC section name. */ + retval =3D grub_file_read (file, section->name, 4); + if (retval >=3D 0 && retval < 4) + { + section->eof =3D 1; + return 1; /* EOF encountered. */ + } + else if (retval < 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font format error: can't read section name"); + return 1; /* Read error. */ + } + + /* Read the big-endian 32-bit section length. */ + retval =3D grub_file_read (file, (char *) &raw_length, 4); + if (retval >=3D 0 && retval < 4) + { + section->eof =3D 1; + return 1; /* EOF encountered. */ + } + else if (retval < 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font format error: can't read section length"); + return 1; /* Read error. */ + } + + /* Convert byte-order and store in *length. */ + section->length =3D grub_be_to_cpu32 (raw_length); + + return 0; +} + +/* Size in bytes of each character index (CHIX section) + entry in the font file. */ +#define FONT_CHAR_INDEX_ENTRY_SIZE (4 + 1 + 4) + +/* Load the character index (CHIX) section contents from the font file. T= his + presumes that the position of FILE is positioned immediately after the + section length for the CHIX section (i.e., at the start of the section + contents). Returns 0 upon success, nonzero for failure (in which case + grub_errno is set appropriately). */ +static int +load_font_index (grub_file_t file, grub_uint32_t sect_length, struct + grub_font *font) +{ + unsigned i; + +#if FONT_DEBUG >=3D 2 + grub_printf("load_font_index(sect_length=3D%d)\n", sect_length); +#endif + + /* Sanity check: ensure section length is divisible by the entry size. = */ + if (sect_length % FONT_CHAR_INDEX_ENTRY_SIZE !=3D 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font file format error: character index length %d " + "is not a multiple of the entry size %d", + sect_length, FONT_CHAR_INDEX_ENTRY_SIZE); + return 1; /* Invalid index section length. */ + } + + /* Calculate the number of characters. */ + font->num_chars =3D sect_length / FONT_CHAR_INDEX_ENTRY_SIZE; + + /* Allocate the character index array. */ + font->char_index =3D grub_malloc (font->num_chars + * sizeof (struct char_index_entry)); + if (!font->char_index) + return 1; /* Error allocating memory. */ + +#if FONT_DEBUG >=3D 2 + grub_printf("num_chars=3D%d)\n", font->num_chars); +#endif + + /* Load the character index data from the file. */ + for (i =3D 0; i < font->num_chars; i++) + { + struct char_index_entry *entry =3D &font->char_index[i]; + + /* Read code point value; convert to native byte order. */ + if (grub_file_read (file, (char *) &entry->code, 4) !=3D 4) + return 1; + entry->code =3D grub_be_to_cpu32 (entry->code); + + /* Read storage flags byte. */ + if (grub_file_read (file, (char *) &entry->storage_flags, 1) !=3D 1) + return 1; + + /* Read glyph data offset; convert to native byte order. */ + if (grub_file_read (file, (char *) &entry->offset, 4) !=3D 4) + return 1; + entry->offset =3D grub_be_to_cpu32 (entry->offset); + + /* No glyph loaded. Will be loaded on demand and cached thereafter.= */ + entry->glyph =3D 0; + +#if FONT_DEBUG >=3D 5 + if (i < 10) /* Print the 1st 10 characters. */ + grub_printf("c=3D%d o=3D%d\n", entry->code, entry->offset); +#endif + } + + return 0; /* Index loaded OK. */ +} + +/* Read the contents of the specified section as a string, which is + allocated on the heap. Returns 0 if there is an error. */ +static char * +read_section_as_string (struct font_file_section *section) +{ + char *str; + grub_ssize_t ret; + + str =3D grub_malloc (section->length + 1); + if (!str) + return 0; + + ret =3D grub_file_read (section->file, str, section->length); + if (ret < 0 || ret !=3D (grub_ssize_t) section->length) + { + grub_free (str); + return 0; + } + + str[section->length] =3D '\0'; + return str; +} + +/* Read the contents of the current section as a 16-bit integer value, + which is stored into *VALUE. + Returns 0 upon success, nonzero upon failure. */ +static int +read_section_as_short (struct font_file_section *section, grub_int16_t *va= lue) +{ + grub_uint16_t raw_value; + + if (section->length !=3D 2) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font file format error: section %c%c%c%c length " + "is %d but should be 2", + section->name[0], section->name[1], + section->name[2], section->name[3], + section->length); + return 1; /* An error occurred. */ + } + if (grub_file_read (section->file, (char *) &raw_value, 2) !=3D 2) + return 1; /* An error occurred. */ + + *value =3D grub_be_to_cpu16 (raw_value); + return 0; /* Successfully read the value. */ +} + +/* Load a font and add it to the beginning of the global font list. + Returns 0 upon success, nonzero upon failure. */ +int +grub_font_load (const char *filename) +{ + grub_file_t file =3D 0; + struct font_file_section section; + char magic[4]; + grub_font_t font =3D 0; + +#if FONT_DEBUG >=3D 1 + grub_printf("add_font(%s)\n", filename); +#endif + + file =3D grub_buffile_open (filename, 1024); + if (!file) + goto fail; + +#if FONT_DEBUG >=3D 3 + grub_printf("file opened\n"); +#endif + + /* Read the FILE section. It indicates the file format. */ + if (open_section (file, §ion) !=3D 0) + goto fail; + +#if FONT_DEBUG >=3D 3 + grub_printf("opened FILE section\n"); +#endif + if (grub_memcmp (section.name, section_names_file, 4) !=3D 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font file format error: 1st section must be FILE"); + goto fail; + } + +#if FONT_DEBUG >=3D 3 + grub_printf("section name ok\n"); +#endif + if (section.length !=3D 4) + { + grub_error (GRUB_ERR_BAD_FONT, + "Font file format error (file type ID length is %d " + "but should be 4)", section.length); + goto fail; + } + +#if FONT_DEBUG >=3D 3 + grub_printf("section length ok\n"); +#endif + /* Check the file format type code. */ + if (grub_file_read (file, magic, 4) !=3D 4) + goto fail; + +#if FONT_DEBUG >=3D 3 + grub_printf("read magic ok\n"); +#endif + + if (grub_memcmp (magic, pff2_magic, 4) !=3D 0) + { + grub_error (GRUB_ERR_BAD_FONT, "Invalid font magic %x %x %x %x", + magic[0], magic[1], magic[2], magic[3]); + goto fail; + } + +#if FONT_DEBUG >=3D 3 + grub_printf("compare magic ok\n"); +#endif + + /* Allocate the font object. */ + font =3D (grub_font_t) grub_malloc (sizeof (struct grub_font)); + if (!font) + goto fail; + + font_init (font); + font->file =3D file; + +#if FONT_DEBUG >=3D 3 + grub_printf("allocate font ok; loading font info\n"); +#endif + + /* Load the font information. */ + while (1) + { + if (open_section (file, §ion) !=3D 0) + { + if (section.eof) + break; /* Done reading the font file. */ + else + goto fail; + } + +#if FONT_DEBUG >=3D 2 + grub_printf("opened section %c%c%c%c ok\n", + section.name[0], section.name[1], + section.name[2], section.name[3]); +#endif + + if (grub_memcmp (section.name, section_names_font_name, 4) =3D=3D 0) + { + font->name =3D read_section_as_string (§ion); + if (!font->name) + goto fail; + } + else if (grub_memcmp (section.name, section_names_point_size, 4) =3D= =3D 0) + { + if (read_section_as_short (§ion, &font->point_size) !=3D 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_weight, 4) =3D=3D = 0) + { + char *wt; + wt =3D read_section_as_string (§ion); + if (!wt) + continue; + /* Convert the weight string 'normal' or 'bold' into a number. = */ + if (grub_strcmp (wt, "normal") =3D=3D 0) + font->weight =3D FONT_WEIGHT_NORMAL; + else if (grub_strcmp (wt, "bold") =3D=3D 0) + font->weight =3D FONT_WEIGHT_BOLD; + grub_free (wt); + } + else if (grub_memcmp (section.name, section_names_max_char_width, 4)= =3D=3D 0) + { + if (read_section_as_short (§ion, &font->max_char_width) !=3D= 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_max_char_height, 4= ) =3D=3D 0) + { + if (read_section_as_short (§ion, &font->max_char_height) != =3D 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_ascent, 4) =3D=3D = 0) + { + if (read_section_as_short (§ion, &font->ascent) !=3D 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_descent, 4) =3D=3D= 0) + { + if (read_section_as_short (§ion, &font->descent) !=3D 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_char_index, 4) =3D= =3D 0) + { + /* Load the font index. */ + if (load_font_index (file, section.length, font) !=3D 0) + goto fail; + } + else if (grub_memcmp (section.name, section_names_data, 4) =3D=3D 0) + { + /* When the DATA section marker is reached, we stop reading. */ + break; + } + else + { + /* Unhandled section type, simply skip past it. */ +#if FONT_DEBUG >=3D 3 + grub_printf("Unhandled section type, skipping.\n"); +#endif + grub_off_t section_end =3D grub_file_tell (file) + section.lengt= h; + if ((int) grub_file_seek (file, section_end) =3D=3D -1) + goto fail; + } + } + + if (!font->name) + { + grub_printf ("Note: Font has no name.\n"); + font->name =3D grub_strdup ("Unknown"); + } + +#if FONT_DEBUG >=3D 1 + grub_printf ("Loaded font `%s'.\n" + "Ascent=3D%d Descent=3D%d MaxW=3D%d MaxH=3D%d Number of cha= racters=3D%d.\n", + font->name, + font->ascent, font->descent, + font->max_char_width, font->max_char_height, + font->num_chars); +#endif + + if (font->max_char_width =3D=3D 0 + || font->max_char_height =3D=3D 0 + || font->num_chars =3D=3D 0 + || font->char_index =3D=3D 0 + || font->ascent =3D=3D 0 + || font->descent =3D=3D 0) + { + grub_error (GRUB_ERR_BAD_FONT, + "Invalid font file: missing some required data."); + goto fail; + } + + /* Add the font to the global font registry. */ + if (register_font (font) !=3D 0) + goto fail; + + return 0; /* Font loaded ok. */ + +fail: + free_font (font); + return 1; /* Failed to load font. */ +} + +/* Read a 16-bit big-endian integer from FILE, convert it to native byte + order, and store it in *VALUE. + Returns 0 on success, 1 on failure. */ +static int +read_be_uint16 (grub_file_t file, grub_uint16_t * value) +{ + if (grub_file_read (file, (char *) value, 2) !=3D 2) + return 1; + *value =3D grub_be_to_cpu16 (*value); + return 0; +} + +static int +read_be_int16 (grub_file_t file, grub_int16_t * value) +{ + /* For the signed integer version, use the same code as for unsigned. */ + return read_be_uint16 (file, (grub_uint16_t *) value); +} + +/* Return a pointer to the character index entry for the glyph correspondi= ng to + the codepoint CODE in the font FONT. If not found, return zero. */ +static struct char_index_entry * +find_glyph (const grub_font_t font, grub_uint32_t code) +{ + grub_uint32_t i; + grub_uint32_t len =3D font->num_chars; + struct char_index_entry *table =3D font->char_index; + + /* Do a linear search. */ + for (i =3D 0; i < len; i++) + { + if (table[i].code =3D=3D code) + return &table[i]; + } + + return 0; /* No entry found for code point CODE. */ +} + +/* Get a glyph for the Unicode character CODE in FONT. The glyph is loaded + from the font file if has not been loaded yet. + Returns a pointer to the glyph if found, or 0 if it is not found. */ +static struct grub_font_glyph * +grub_font_get_glyph_internal (grub_font_t font, grub_uint32_t code) +{ + struct char_index_entry *index_entry; + + index_entry =3D find_glyph (font, code); + if (index_entry) + { + struct grub_font_glyph *glyph =3D 0; + grub_uint16_t width; + grub_uint16_t height; + grub_int16_t xoff; + grub_int16_t yoff; + grub_int16_t dwidth; + int len; + + if (index_entry->glyph) + return index_entry->glyph; /* Return cached glyph. */ + + if (! font->file) + return 0; /* No open file, can't load any glyphs. */ + + /* Make sure we can find glyphs for error messages. Push active + error message to error stack and reset error message. */ + grub_error_push (); + + grub_file_seek (font->file, index_entry->offset); + + /* Read the glyph width, height, and baseline. */ + if (read_be_uint16(font->file, &width) !=3D 0 + || read_be_uint16(font->file, &height) !=3D 0 + || read_be_int16(font->file, &xoff) !=3D 0 + || read_be_int16(font->file, &yoff) !=3D 0 + || read_be_int16(font->file, &dwidth) !=3D 0) + { + remove_font (font); + return 0; + } + + len =3D (width * height + 7) / 8; + glyph =3D grub_malloc (sizeof (struct grub_font_glyph) + len); + if (! glyph) + { + remove_font (font); + return 0; + } + + glyph->font =3D font; + glyph->width =3D width; + glyph->height =3D height; + glyph->offset_x =3D xoff; + glyph->offset_y =3D yoff; + glyph->device_width =3D dwidth; + + /* Don't try to read empty bitmaps (e.g., space characters). */ + if (len !=3D 0) + { + if (grub_file_read (font->file, (char *) glyph->bitmap, len) != =3D len) + { + remove_font (font); + return 0; + } + } + + /* Restore old error message. */ + grub_error_pop (); + + /* Cache the glyph. */ + index_entry->glyph =3D glyph; + + return glyph; /* Glyph loaded ok. */ + } + + return 0; +} + +/* Free the memory used by FONT. + This should not be called if the font has been made available to + users (once it is added to the global font list), since there would + be the possibility of a dangling pointer. */ +static void +free_font (grub_font_t font) +{ + if (font) + { + if (font->file) + grub_file_close (font->file); + grub_free (font->name); + grub_free (font->family); + grub_free (font->char_index); + grub_free (font); + } +} + +/* Add FONT to the global font registry. + Returns 0 upon success, nonzero on failure + (the font was not registered). */ +static int +register_font (grub_font_t font) +{ + struct grub_font_node *node =3D 0; + + node =3D grub_malloc (sizeof (struct grub_font_node)); + if (! node) + return 1; /* Error. */ + + node->value =3D font; + node->next =3D grub_font_list; + grub_font_list =3D node; + + return 0; /* Success. */ +} + +/* Remove the font from the global font list. We don't actually free the + font's memory since users could be holding references to the font. */ +static void +remove_font (grub_font_t font) +{ + struct grub_font_node **nextp, *cur; + + for (nextp =3D &grub_font_list, cur =3D *nextp; + cur; + nextp =3D &cur->next, cur =3D cur->next) + { + if (cur->value =3D=3D font) + { + *nextp =3D cur->next; + + /* Free the node, but not the font itself. */ + grub_free (cur); + + return; + } + } +} + + +/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/ +/* Public font API */ + +/* Get a font from the list of loaded fonts. This function will return + another font if the requested font is not available. If no fonts are + loaded, then a special 'null font' is returned, which contains no glyph= s, + but is not a null pointer so the caller may omit checks for NULL. */ +grub_font_t +grub_font_get (const char *font_name) +{ + struct grub_font_node *node; + + for (node =3D grub_font_list; node; node =3D node->next) + { + grub_font_t font =3D node->value; + if (grub_strcmp (font->name, font_name) =3D=3D 0) + return font; + } + + /* If no font by that name is found, return the first font in the list + as a fallback. */ + if (grub_font_list && grub_font_list->value) + return grub_font_list->value; + else + return &null_font; /* The null_font is a last resort. */ +} + +/* Get the full name of the font. For instance, "Helvetica Bold 12". */ +const char * +grub_font_get_name (grub_font_t font) +{ + return font->name; +} + +/* Get the maximum width of any character in the font in pixels. */ +int +grub_font_get_max_char_width (grub_font_t font) +{ + return font->max_char_width; +} + +/* Get the maximum height of any character in the font in pixels. */ +int +grub_font_get_max_char_height (grub_font_t font) +{ + return font->max_char_height; +} + +/* Get the distance in pixels from the top of characters to the baseline. = */ +int +grub_font_get_ascent (grub_font_t font) +{ + return font->ascent; +} + +/* Get the distance in pixels from the baseline to the lowest descenders + (for instance, in a lowercase 'y', 'g', etc.). */ +int +grub_font_get_descent (grub_font_t font) +{ + return font->descent; +} + +/* Get the *standard leading* of the font in pixel, which is the spacing + between two lines of text. Specifically, it is the space between the + descent of one line and the ascent of the next line. This is included + in the *height* metric. */ +int +grub_font_get_leading (grub_font_t font) +{ + return font->leading; +} + +/* Get the distance in pixels between baselines of adjacent lines of text.= */ +int +grub_font_get_height (grub_font_t font) +{ + return font->ascent + font->descent + font->leading; +} + +/* Get the width in pixels of the specified UTF-8 string, when rendered in + in the specified font (but falling back on other fonts for glyphs that + are missing). */ +int +grub_font_get_string_width (grub_font_t font, const char *str) +{ + int width; + struct grub_font_glyph *glyph; + grub_uint32_t code; + const grub_uint8_t *ptr; + + for (ptr =3D (const grub_uint8_t *) str, width =3D 0; + grub_utf8_to_ucs4 (&code, 1, ptr, -1, &ptr) > 0; ) + { + glyph =3D grub_font_get_glyph_with_fallback (font, code); + width +=3D glyph->device_width; + } + + return width; +} + +/* Get the glyph for FONT corresponding to the Unicode code point CODE. + Returns a pointer to an glyph indicating there is no glyph available + if CODE does not exist in the font. The glyphs are cached once loaded.= */ +struct grub_font_glyph * +grub_font_get_glyph (grub_font_t font, grub_uint32_t code) +{ + struct grub_font_glyph *glyph; + glyph =3D grub_font_get_glyph_internal (font, code); + if (glyph =3D=3D 0) + glyph =3D unknown_glyph; + return glyph; +} + + +/* Calculate a subject value representing "how similar" two fonts are. + This is used to prioritize the order that fonts are scanned for missing + glyphs. The object is to select glyphs from the most similar font + possible, for the best appearance. + The heuristic is crude, but it helps greatly when fonts of similar + sizes are used so that tiny 8 point glyphs are not mixed into a string + of 24 point text unless there is no other choice. */ +static int +get_font_diversity(grub_font_t a, grub_font_t b) +{ + int d; + + d =3D 0; + + if (a->ascent && b->ascent) + d +=3D grub_abs (a->ascent - b->ascent) * 8; + else + d +=3D 50; /* Penalty for missing attributes. */ + + if (a->max_char_height && b->max_char_height) + d +=3D grub_abs (a->max_char_height - b->max_char_height) * 8; + else + d +=3D 50; /* Penalty for missing attributes. */ + + d +=3D (a->weight !=3D b->weight) ? 5 : 0; /* Weight is a minor factor= . */ + + return d; +} + +/* Get a glyph corresponding to the codepoint CODE. If FONT contains the + specified glyph, then it is returned. Otherwise, all other loaded fonts + are searched until one is found that contains a glyph for CODE. + If no glyph is available for CODE in the loaded fonts, then a glyph + representing an unknown character is returned. + This function never returns NULL. + The returned glyph is owned by the font manager and should not be freed + by the caller. The glyphs are cached. */ +struct grub_font_glyph * +grub_font_get_glyph_with_fallback (grub_font_t font, grub_uint32_t code) +{ + struct grub_font_glyph *glyph; + struct grub_font_node *node; + /* Keep track of next node, in case there's an I/O error in + grub_font_get_glyph_internal() and the font is removed from the list.= */ + struct grub_font_node *next; + /* Information on the best glyph found so far, to help find the glyph in + the best matching to the requested one. */ + int best_diversity; + struct grub_font_glyph *best_glyph; + + if (font) + { + /* First try to get the glyph from the specified font. */ + glyph =3D grub_font_get_glyph_internal (font, code); + if (glyph) + return glyph; + } + + /* Otherwise, search all loaded fonts for the glyph and use the one from + the font that best matches the requested font. */ + best_diversity =3D 10000; + best_glyph =3D 0; + + for (node =3D grub_font_list; node; node =3D next) + { + grub_font_t curfont; + + curfont =3D node->value; + next =3D node->next; + + glyph =3D grub_font_get_glyph_internal (curfont, code); + if (glyph) + { + int d; + + d =3D get_font_diversity (curfont, font); + if (d < best_diversity) + { + best_diversity =3D d; + best_glyph =3D glyph; + } + } + } + + if (best_glyph) + return best_glyph; + else + return unknown_glyph; /* Ugh... Glyph not available in any font. */ +} + + +/* Draw the specified glyph at (x, y). The y coordinate designates the + baseline of the character, while the x coordinate designates the left + side location of the character. */ +grub_err_t +grub_font_draw_glyph (struct grub_font_glyph *glyph, + grub_video_color_t color, + int left_x, int baseline_y) +{ + struct grub_video_bitmap glyph_bitmap; + + /* Don't try to draw empty glyphs (U+0020, etc.). */ + if (glyph->width =3D=3D 0 || glyph->height =3D=3D 0) + return GRUB_ERR_NONE; + + glyph_bitmap.mode_info.width =3D glyph->width; + glyph_bitmap.mode_info.height =3D glyph->height; + glyph_bitmap.mode_info.mode_type =3D + (1 << GRUB_VIDEO_MODE_TYPE_DEPTH_POS) + | GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP; + glyph_bitmap.mode_info.blit_format =3D GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKE= D; + glyph_bitmap.mode_info.bpp =3D 1; + glyph_bitmap.mode_info.bytes_per_pixel =3D 0; /* Really 1 bit per pixel= . */ + glyph_bitmap.mode_info.pitch =3D glyph->width; /* Packed densely as bits= . */ + glyph_bitmap.mode_info.number_of_colors =3D 2; + glyph_bitmap.mode_info.bg_red =3D 0; + glyph_bitmap.mode_info.bg_green =3D 0; + glyph_bitmap.mode_info.bg_blue =3D 0; + glyph_bitmap.mode_info.bg_alpha =3D 0; + grub_video_unmap_color(color, + &glyph_bitmap.mode_info.fg_red, + &glyph_bitmap.mode_info.fg_green, + &glyph_bitmap.mode_info.fg_blue, + &glyph_bitmap.mode_info.fg_alpha); + glyph_bitmap.data =3D glyph->bitmap; + + int bitmap_left =3D left_x + glyph->offset_x; + int bitmap_bottom =3D baseline_y - glyph->offset_y; + int bitmap_top =3D bitmap_bottom - glyph->height; + + return grub_video_blit_bitmap (&glyph_bitmap, GRUB_VIDEO_BLIT_BLEND, + bitmap_left, bitmap_top, + 0, 0, + glyph->width, glyph->height); +} + +/* Draw a UTF-8 string of text on the current video render target. + The x coordinate specifies the starting x position for the first charac= ter, + while the y coordinate specifies the baseline position. + If the string contains a character that FONT does not contain, then + a glyph from another loaded font may be used instead. */ +grub_err_t +grub_font_draw_string (const char *str, grub_font_t font, + grub_video_color_t color, + int left_x, int baseline_y) +{ + int x; + struct grub_font_glyph *glyph; + grub_uint32_t code; + const grub_uint8_t *ptr; + + for (ptr =3D (const grub_uint8_t *) str, x =3D left_x; + grub_utf8_to_ucs4 (&code, 1, ptr, -1, &ptr) > 0; ) + { + glyph =3D grub_font_get_glyph_with_fallback (font, code); + if (grub_font_draw_glyph (glyph, color, x, baseline_y) + !=3D GRUB_ERR_NONE) + return grub_errno; + x +=3D glyph->device_width; + } + + return GRUB_ERR_NONE; +} + =3D=3D=3D added file 'font/font_cmd.c' --- font/font_cmd.c 1970-01-01 00:00:00 +0000 +++ font/font_cmd.c 2008-10-31 03:44:24 +0000 @@ -0,0 +1,77 @@ +/* font_cmd.c - Font command definition. */ +/* + * GRUB -- GRand Unified Bootloader + * Copyright (C) 2003,2005,2006,2007,2008 Free Software Foundation, Inc. + * + * GRUB is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * GRUB is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with GRUB. If not, see . + */ + +#include +#include +#include +#include + +static grub_err_t +loadfont_command (struct grub_arg_list *state __attribute__ ((unused)), + int argc, + char **args) +{ + if (argc =3D=3D 0) + return grub_error (GRUB_ERR_BAD_ARGUMENT, "no font specified"); + + while (argc--) + if (grub_font_load (*args++) !=3D 0) + return GRUB_ERR_BAD_FONT; + + return GRUB_ERR_NONE; +} + +static grub_err_t +lsfonts_command (struct grub_arg_list *state __attribute__ ((unused)), + int argc __attribute__ ((unused)), + char **args __attribute__ ((unused))) +{ + struct grub_font_node *node; + + grub_printf ("Loaded fonts:\n"); + for (node =3D grub_font_list; node; node =3D node->next) + { + grub_font_t font =3D node->value; + grub_printf ("%s\n", grub_font_get_name (font)); + } + + return GRUB_ERR_NONE; +} + +GRUB_MOD_INIT(font_manager) +{ + grub_font_loader_init (); + + grub_register_command ("loadfont", loadfont_command, GRUB_COMMAND_FLAG_B= OTH, + "loadfont FILE...", + "Specify one or more font files to load.", 0); + + grub_register_command ("lsfonts", lsfonts_command, GRUB_COMMAND_FLAG_BOT= H, + "lsfonts", + "List the loaded fonts.", 0); +} + +GRUB_MOD_FINI(font_manager) +{ + /* Should this free fonts, unknown_glyph, etc.? Freeing fonts could=20 + be a Bad Thing if there are still references to any of them. */ + + grub_unregister_command ("loadfont"); +} + =3D=3D=3D removed file 'font/manager.c' --- font/manager.c 2008-08-01 03:06:55 +0000 +++ font/manager.c 1970-01-01 00:00:00 +0000 @@ -1,283 +0,0 @@ -/* - * GRUB -- GRand Unified Bootloader - * Copyright (C) 2003,2005,2006,2007 Free Software Foundation, Inc. - * - * GRUB is free software: you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation, either version 3 of the License, or - * (at your option) any later version. - * - * GRUB is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with GRUB. If not, see . - */ - -#include -#include -#include -#include -#include -#include -#include -#include - -struct entry -{ - grub_uint32_t code; - grub_uint32_t offset; -}; - -struct font -{ - struct font *next; - grub_file_t file; - grub_uint32_t num; - struct entry table[0]; -}; - -static struct font *font_list; - -/* Fill unknown glyph's with rounded question mark. */ -static grub_uint8_t unknown_glyph[16] =3D -{ /* 76543210 */ - 0x7C, /* ooooo */ - 0x82, /* o o */ - 0xBA, /* o ooo o */ - 0xAA, /* o o o o */ - 0xAA, /* o o o o */ - 0x8A, /* o o o */ - 0x9A, /* o oo o */ - 0x92, /* o o o */ - 0x92, /* o o o */ - 0x92, /* o o o */ - 0x92, /* o o o */ - 0x82, /* o o */ - 0x92, /* o o o */ - 0x82, /* o o */ - 0x7C, /* ooooo */ - 0x00 /* */ -}; - -static int -add_font (const char *filename) -{ - grub_file_t file =3D 0; - char magic[4]; - grub_uint32_t num, i; - struct font *font =3D 0; - - file =3D grub_buffile_open (filename, 0); - if (! file) - goto fail; - - if (grub_file_read (file, magic, 4) !=3D 4) - goto fail; - - if (grub_memcmp (magic, GRUB_FONT_MAGIC, 4) !=3D 0) - { - grub_error (GRUB_ERR_BAD_FONT, "invalid font magic"); - goto fail; - } - - if (grub_file_read (file, (char *) &num, 4) !=3D 4) - goto fail; - - num =3D grub_le_to_cpu32 (num); - font =3D (struct font *) grub_malloc (sizeof (struct font) - + sizeof (struct entry) * num); - if (! font) - goto fail; - - font->file =3D file; - font->num =3D num; - - for (i =3D 0; i < num; i++) - { - grub_uint32_t code, offset; - =20 - if (grub_file_read (file, (char *) &code, 4) !=3D 4) - goto fail; - - if (grub_file_read (file, (char *) &offset, 4) !=3D 4) - goto fail; - - font->table[i].code =3D grub_le_to_cpu32 (code); - font->table[i].offset =3D grub_le_to_cpu32 (offset); - } - - font->next =3D font_list; - font_list =3D font; - - return 1; - - fail: - if (font) - grub_free (font); - - if (file) - grub_file_close (file); - - return 0; -} - -static void -remove_font (struct font *font) -{ - struct font **p, *q; - - for (p =3D &font_list, q =3D *p; q; p =3D &(q->next), q =3D q->next) - if (q =3D=3D font) - { - *p =3D q->next; -=09 - grub_file_close (font->file); - grub_free (font); -=09 - break; - } -} - -/* Return the offset of the glyph corresponding to the codepoint CODE - in the font FONT. If no found, return zero. */ -static grub_uint32_t -find_glyph (const struct font *font, grub_uint32_t code) -{ - grub_uint32_t start =3D 0; - grub_uint32_t end =3D font->num - 1; - const struct entry *table =3D font->table; - =20 - /* This shouldn't happen. */ - if (font->num =3D=3D 0) - return 0; - - /* Do a binary search. */ - while (start <=3D end) - { - grub_uint32_t i =3D (start + end) / 2; - - if (table[i].code < code) - start =3D i + 1; - else if (table[i].code > code) - end =3D i - 1; - else - return table[i].offset; - } - - return 0; -} - -/* Set the glyph to something stupid. */ -static void -fill_with_default_glyph (grub_font_glyph_t glyph) -{ - unsigned i; - - /* Use pre-defined pattern to fill unknown glyphs. */ - for (i =3D 0; i < 16; i++) - glyph->bitmap[i] =3D unknown_glyph[i]; - - glyph->char_width =3D 1; - glyph->width =3D glyph->char_width * 8; - glyph->height =3D 16; - glyph->baseline =3D (16 * 3) / 4; -} - -/* Get a glyph corresponding to the codepoint CODE. Always fill glyph - information with something, even if no glyph is found. */ -int -grub_font_get_glyph (grub_uint32_t code, - grub_font_glyph_t glyph) -{ - struct font *font; - grub_uint8_t bitmap[32]; - - /* FIXME: It is necessary to cache glyphs! */ - =20 - restart: - for (font =3D font_list; font; font =3D font->next) - { - grub_uint32_t offset; - - offset =3D find_glyph (font, code); - if (offset) - { - grub_uint32_t w; - int len; - - /* Make sure we can find glyphs for error messages. Push active - error message to error stack and reset error message. */ - grub_error_push (); - =20 - grub_file_seek (font->file, offset); - if ((len =3D grub_file_read (font->file, (char *) &w, sizeof (w))) - !=3D sizeof (w)) - { - remove_font (font); - goto restart; - } - - w =3D grub_le_to_cpu32 (w); - if (w !=3D 1 && w !=3D 2) - { - /* grub_error (GRUB_ERR_BAD_FONT, "invalid width"); */ - remove_font (font); - goto restart; - } - - if (grub_file_read (font->file, (char *) bitmap, w * 16) - !=3D (grub_ssize_t) w * 16) - { - remove_font (font); - goto restart; - } - - /* Fill glyph with information. */ =20 - grub_memcpy (glyph->bitmap, bitmap, w * 16); - =20 - glyph->char_width =3D w; - glyph->width =3D glyph->char_width * 8; - glyph->height =3D 16; - glyph->baseline =3D (16 * 3) / 4; - =20 - /* Restore old error message. */ - grub_error_pop (); - =20 - return 1; - } - } - - /* Uggh... No font was found. */ - fill_with_default_glyph (glyph); - return 0; -} - -static grub_err_t -font_command (struct grub_arg_list *state __attribute__ ((unused)), - int argc __attribute__ ((unused)), - char **args __attribute__ ((unused))) -{ - if (argc =3D=3D 0) - return grub_error (GRUB_ERR_BAD_ARGUMENT, "no font specified"); - - while (argc--) - if (! add_font (*args++)) - return 1; - - return 0; -} - -GRUB_MOD_INIT(font_manager) -{ - grub_register_command ("font", font_command, GRUB_COMMAND_FLAG_BOTH, - "font FILE...", - "Specify one or more font files to display.", 0); -} - -GRUB_MOD_FINI(font_manager) -{ - grub_unregister_command ("font"); -} =3D=3D=3D modified file 'include/grub/font.h' --- include/grub/font.h 2007-07-21 22:32:33 +0000 +++ include/grub/font.h 2008-10-31 03:44:24 +0000 @@ -1,6 +1,6 @@ /* * GRUB -- GRand Unified Bootloader - * Copyright (C) 2003,2007 Free Software Foundation, Inc. + * Copyright (C) 2003,2007,2008 Free Software Foundation, Inc. * * GRUB is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -20,34 +20,96 @@ #define GRUB_FONT_HEADER 1 =20 #include - -#define GRUB_FONT_MAGIC "PPF\x7f" +#include + +/* Forward declaration of opaque structure grub_font. + Users only pass struct grub_font pointers to the font module functions, + and do not have knowledge of the structure contents. */ +struct grub_font; + +/* Font type used to access font functions. */ +typedef struct grub_font *grub_font_t; + +struct grub_font_node +{ + struct grub_font_node *next; + grub_font_t value; +}; + +/* Global font registry. */ +extern struct grub_font_node *grub_font_list; =20 struct grub_font_glyph { - /* Glyph width in pixels. */ - grub_uint8_t width; - =20 - /* Glyph height in pixels. */ - grub_uint8_t height; - =20 - /* Glyph width in characters. */ - grub_uint8_t char_width; - =20 - /* Glyph baseline position in pixels (from up). */ - grub_uint8_t baseline; - =20 - /* Glyph bitmap data array of bytes in ((width + 7) / 8) * height. - Bitmap is formulated by height scanlines, each scanline having - width number of pixels. Pixels are coded as bits, value 1 meaning - of opaque pixel and 0 is transparent. If width does not fit byte - boundary, it will be padded with 0 to make it fit. */ - grub_uint8_t bitmap[32]; + /* Reference to the font this glyph belongs to. */ + grub_font_t font; + + /* Glyph bitmap width in pixels. */ + grub_uint16_t width; + + /* Glyph bitmap height in pixels. */ + grub_uint16_t height; + + /* Glyph bitmap x offset in pixels. Add to screen coordinate. */ + grub_int16_t offset_x; + + /* Glyph bitmap y offset in pixels. Subtract from screen coordinate. */ + grub_int16_t offset_y; + + /* Number of pixels to advance to start the next character. */ + grub_uint16_t device_width; + + /* Row-major order, packed bits (no padding; rows can break within a byt= e). + The length of the array is (width * height + 7) / 8. Within a + byte, the most significant bit is the first (leftmost/uppermost) pixe= l. + Pixels are coded as bits, value 1 meaning of opaque pixel and 0 is + transparent. If the length of the array does not fit byte boundary, it + will be padded with 0 bits to make it fit. */ + grub_uint8_t bitmap[0]; }; =20 -typedef struct grub_font_glyph *grub_font_glyph_t; - -int grub_font_get_glyph (grub_uint32_t code, - grub_font_glyph_t glyph); +/* Initialize the font loader. + Must be called before any fonts are loaded or used. */ +void grub_font_loader_init (void); + +/* Load a font and add it to the beginning of the global font list. + Returns: 0 upon success; nonzero upon failure. */ +int grub_font_load (const char *filename); + +/* Get the font that has the specified name. Font names are in the form + "Family Name Bold Italic 14", where Bold and Italic are optional. + If no font matches the name specified, the most recently loaded font + is returned as a fallback. */ +grub_font_t grub_font_get (const char *font_name); + +const char *grub_font_get_name (grub_font_t font); + +int grub_font_get_max_char_width (grub_font_t font); + +int grub_font_get_max_char_height (grub_font_t font); + +int grub_font_get_ascent (grub_font_t font); + +int grub_font_get_descent (grub_font_t font); + +int grub_font_get_leading (grub_font_t font); + +int grub_font_get_height (grub_font_t font); + +int grub_font_get_string_width (grub_font_t font, const char *str); + +struct grub_font_glyph *grub_font_get_glyph (grub_font_t font, + grub_uint32_t code); + +struct grub_font_glyph *grub_font_get_glyph_with_fallback (grub_font_t fon= t, + grub_uint32_t c= ode); + +grub_err_t grub_font_draw_glyph (struct grub_font_glyph *glyph, + grub_video_color_t color, + int left_x, int baseline_y); + +grub_err_t grub_font_draw_string (const char *str, grub_font_t font, + grub_video_color_t color, + int left_x, int baseline_y); =20 #endif /* ! GRUB_FONT_HEADER */ =3D=3D=3D modified file 'include/grub/misc.h' --- include/grub/misc.h 2008-09-19 05:55:20 +0000 +++ include/grub/misc.h 2008-10-30 18:24:32 +0000 @@ -77,8 +77,10 @@ grub_uint16_t *src, grub_size_t size); grub_ssize_t EXPORT_FUNC(grub_utf8_to_ucs4) (grub_uint32_t *dest, + grub_size_t destsize, const grub_uint8_t *src, - grub_size_t size); + grub_size_t srcsize, + const grub_uint8_t **srcend); grub_uint64_t EXPORT_FUNC(grub_divmod64) (grub_uint64_t n, grub_uint32_t d, grub_uint32_t *r); =20 =3D=3D=3D modified file 'include/grub/video.h' --- include/grub/video.h 2008-10-05 04:28:39 +0000 +++ include/grub/video.h 2008-10-30 18:28:52 +0000 @@ -31,17 +31,17 @@ struct grub_video_render_target; =20 /* Forward declarations for used data structures. */ -struct grub_font_glyph; struct grub_video_bitmap; =20 /* Defines used to describe video mode or rendering target. */ -#define GRUB_VIDEO_MODE_TYPE_ALPHA 0x00000008 -#define GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED 0x00000004 +#define GRUB_VIDEO_MODE_TYPE_ALPHA 0x00000020 +#define GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED 0x00000010 +#define GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP 0x00000004 #define GRUB_VIDEO_MODE_TYPE_INDEX_COLOR 0x00000002 #define GRUB_VIDEO_MODE_TYPE_RGB 0x00000001 =20 /* Defines used to mask flags. */ -#define GRUB_VIDEO_MODE_TYPE_COLOR_MASK 0x00000003 +#define GRUB_VIDEO_MODE_TYPE_COLOR_MASK 0x0000000F =20 /* Defines used to specify requested bit depth. */ #define GRUB_VIDEO_MODE_TYPE_DEPTH_MASK 0x0000ff00 @@ -72,7 +72,9 @@ GRUB_VIDEO_BLIT_FORMAT_BGR_565, =20 /* When needed, decode color or just use value as is. */ - GRUB_VIDEO_BLIT_FORMAT_INDEXCOLOR + GRUB_VIDEO_BLIT_FORMAT_INDEXCOLOR, + /* Two color bitmap; bits packed: rows are not padded to byte boundary= . */ + GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED }; =20 /* Define blitting operators. */ @@ -135,6 +137,18 @@ /* What is location of reserved color bits. In Index Color mode, this is 0. */ unsigned int reserved_field_pos; + + /* For 1-bit bitmaps, the background color. Used for bits =3D 0. */ + grub_uint8_t bg_red; + grub_uint8_t bg_green; + grub_uint8_t bg_blue; + grub_uint8_t bg_alpha; + + /* For 1-bit bitmaps, the foreground color. Used for bits =3D 1. */ + grub_uint8_t fg_red; + grub_uint8_t fg_green; + grub_uint8_t fg_blue; + grub_uint8_t fg_alpha; }; =20 struct grub_video_palette_data @@ -188,9 +202,6 @@ grub_err_t (*fill_rect) (grub_video_color_t color, int x, int y, unsigned int width, unsigned int height); =20 - grub_err_t (*blit_glyph) (struct grub_font_glyph *glyph, - grub_video_color_t color, int x, int y); - grub_err_t (*blit_bitmap) (struct grub_video_bitmap *bitmap, enum grub_video_blit_operators oper, int x, int y, int offset_x, int offset_y, @@ -260,9 +271,6 @@ grub_err_t grub_video_fill_rect (grub_video_color_t color, int x, int y, unsigned int width, unsigned int height); =20 -grub_err_t grub_video_blit_glyph (struct grub_font_glyph *glyph, - grub_video_color_t color, int x, int y); - grub_err_t grub_video_blit_bitmap (struct grub_video_bitmap *bitmap, enum grub_video_blit_operators oper, int x, int y, int offset_x, int offset_= y, =3D=3D=3D modified file 'kern/misc.c' --- kern/misc.c 2008-09-19 05:55:20 +0000 +++ kern/misc.c 2008-10-30 18:24:32 +0000 @@ -951,22 +951,29 @@ return dest; } =20 -/* Convert an UTF-8 string to an UCS-4 string. Return the number of - characters converted. DEST must be able to hold at least SIZE - characters (when the input is unknown). If an invalid sequence is found, - return -1. */ +/* Convert a (possibly null-terminated) UTF-8 string of at most SRCSIZE + bytes (if SRCSIZE is -1, it is ignored) in length to a UCS-4 string. + Return the number of characters converted. DEST must be able to hold + at least DESTSIZE characters. If an invalid sequence is found, return -= 1. + If SRCEND is not NULL, then *SRCEND is set to the next byte after the + last byte used in SRC. */ grub_ssize_t -grub_utf8_to_ucs4 (grub_uint32_t *dest, const grub_uint8_t *src, - grub_size_t size) +grub_utf8_to_ucs4 (grub_uint32_t *dest, grub_size_t destsize, + const grub_uint8_t *src, grub_size_t srcsize, + const grub_uint8_t **srcend) { grub_uint32_t *p =3D dest; int count =3D 0; grub_uint32_t code =3D 0; =20 - while (size--) + if (*srcend) + *srcend =3D src; + + while (srcsize && destsize) { grub_uint32_t c =3D *src++; - =20 + if (srcsize !=3D -1) + srcsize--; if (count) { if ((c & 0xc0) !=3D 0x80) @@ -983,6 +990,8 @@ } else { + if (c =3D=3D 0) + break; /* NUL character terminates the string. */ if ((c & 0x80) =3D=3D 0x00) code =3D c; else if ((c & 0xe0) =3D=3D 0xc0) @@ -1011,14 +1020,18 @@ code =3D c & 0x01; } else - /* invalid */ return -1; } =20 if (count =3D=3D 0) - *p++ =3D code; + { + *p++ =3D code; + destsize--; + } } =20 + if (srcend) + *srcend =3D src; return p - dest; } =20 =3D=3D=3D modified file 'kern/term.c' --- kern/term.c 2007-12-25 11:10:47 +0000 +++ kern/term.c 2008-10-30 18:24:32 +0000 @@ -153,7 +153,7 @@ grub_ssize_t ret; =20 buf[size++] =3D c; - ret =3D grub_utf8_to_ucs4 (&code, buf, size); + ret =3D grub_utf8_to_ucs4 (&code, 1, buf, size, 0); =20 if (ret > 0) { =3D=3D=3D modified file 'normal/menu.c' --- normal/menu.c 2008-08-31 00:48:14 +0000 +++ normal/menu.c 2008-10-30 18:43:35 +0000 @@ -117,19 +117,21 @@ { int x; const char *title; + grub_size_t title_len; grub_ssize_t len; grub_uint32_t *unicode_title; grub_ssize_t i; grub_uint8_t old_color_normal, old_color_highlight; =20 title =3D entry ? entry->title : ""; - unicode_title =3D grub_malloc (grub_strlen (title) * sizeof (*unicode_ti= tle)); + title_len =3D grub_strlen (title); + unicode_title =3D grub_malloc (title_len * sizeof (*unicode_title)); if (! unicode_title) /* XXX How to show this error? */ return; =20 - len =3D grub_utf8_to_ucs4 (unicode_title, (grub_uint8_t *) title, - grub_strlen (title)); + len =3D grub_utf8_to_ucs4 (unicode_title, title_len, + (grub_uint8_t *) title, -1, 0); if (len < 0) { /* It is an invalid sequence. */ =3D=3D=3D modified file 'term/gfxterm.c' --- term/gfxterm.c 2008-08-31 03:08:13 +0000 +++ term/gfxterm.c 2008-10-30 18:24:32 +0000 @@ -35,9 +35,6 @@ #define DEFAULT_VIDEO_HEIGHT 480 #define DEFAULT_VIDEO_FLAGS 0 =20 -#define DEFAULT_CHAR_WIDTH 8 -#define DEFAULT_CHAR_HEIGHT 16 - #define DEFAULT_BORDER_WIDTH 10 =20 #define DEFAULT_STANDARD_COLOR 0x07 @@ -91,6 +88,9 @@ unsigned int cursor_y; int cursor_state; =20 + /* Font settings. */ + grub_font_t font; + /* Terminal color settings. */ grub_uint8_t standard_color_setting; grub_uint8_t normal_color_setting; @@ -169,18 +169,25 @@ =20 static grub_err_t grub_virtual_screen_setup (unsigned int x, unsigned int y, - unsigned int width, unsigned int height) + unsigned int width, unsigned int height, + const char *font_name) { /* Free old virtual screen. */ grub_virtual_screen_free (); =20 /* Initialize with default data. */ + virtual_screen.font =3D grub_font_get (font_name); + if (!virtual_screen.font) + return grub_error (GRUB_ERR_BAD_FONT, + "No font loaded."); virtual_screen.width =3D width; virtual_screen.height =3D height; virtual_screen.offset_x =3D x; virtual_screen.offset_y =3D y; - virtual_screen.char_width =3D DEFAULT_CHAR_WIDTH; - virtual_screen.char_height =3D DEFAULT_CHAR_HEIGHT; + virtual_screen.char_width =3D=20 + grub_font_get_max_char_width (virtual_screen.font); + virtual_screen.char_height =3D=20 + grub_font_get_max_char_height (virtual_screen.font); virtual_screen.cursor_x =3D 0; virtual_screen.cursor_y =3D 0; virtual_screen.cursor_state =3D 1; @@ -226,6 +233,7 @@ static grub_err_t grub_gfxterm_init (void) { + char *font_name; char *modevar; int width =3D DEFAULT_VIDEO_WIDTH; int height =3D DEFAULT_VIDEO_HEIGHT; @@ -233,6 +241,11 @@ int flags =3D DEFAULT_VIDEO_FLAGS; grub_video_color_t color; =20 + /* Select the font to use. */ + font_name =3D grub_env_get ("gfxterm_font"); + if (!font_name) + font_name =3D ""; /* Allow fallback to any font. */ + /* Parse gfxmode environment variable if set. */ modevar =3D grub_env_get ("gfxmode"); if (modevar) @@ -472,7 +485,7 @@ =20 /* Create virtual screen. */ if (grub_virtual_screen_setup (DEFAULT_BORDER_WIDTH, DEFAULT_BORDER_WIDT= H, - width, height) !=3D GRUB_ERR_NONE) + width, height, font_name) !=3D GRUB_ERR_N= ONE) { grub_video_restore (); return grub_errno; @@ -658,11 +671,12 @@ write_char (void) { struct grub_colored_char *p; - struct grub_font_glyph glyph; + struct grub_font_glyph *glyph; grub_video_color_t color; grub_video_color_t bgcolor; unsigned int x; unsigned int y; + int ascent; =20 /* Find out active character. */ p =3D (virtual_screen.text_buffer @@ -672,7 +686,8 @@ p -=3D p->index; =20 /* Get glyph for character. */ - grub_font_get_glyph (p->code, &glyph); + glyph =3D grub_font_get_glyph (virtual_screen.font, p->code); + ascent =3D grub_font_get_ascent (virtual_screen.font); =20 color =3D p->fg_color; bgcolor =3D p->bg_color; @@ -682,13 +697,13 @@ =20 /* Render glyph to text layer. */ grub_video_set_active_render_target (text_layer); - grub_video_fill_rect (bgcolor, x, y, glyph.width, glyph.height); - grub_video_blit_glyph (&glyph, color, x, y); + grub_video_fill_rect (bgcolor, x, y, glyph->width, glyph->height); + grub_font_draw_glyph (glyph, color, x, y + ascent); grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); =20 /* Mark character to be drawn. */ dirty_region_add (virtual_screen.offset_x + x, virtual_screen.offset_y += y, - glyph.width, glyph.height); + glyph->width, glyph->height); } =20 static void @@ -702,7 +717,8 @@ =20 /* Determine cursor properties and position on text layer. */ x =3D virtual_screen.cursor_x * virtual_screen.char_width; - y =3D ((virtual_screen.cursor_y + 1) * virtual_screen.char_height) - 3; = =20 + y =3D (virtual_screen.cursor_y * virtual_screen.char_height =20 + + grub_font_get_ascent (virtual_screen.font)); width =3D virtual_screen.char_width; height =3D 2; =20 @@ -819,14 +835,18 @@ } else { - struct grub_font_glyph glyph; + struct grub_font_glyph *glyph; struct grub_colored_char *p; + unsigned char_width; =20 /* Get properties of the character. */ =20 - grub_font_get_glyph (c, &glyph); + glyph =3D grub_font_get_glyph (virtual_screen.font, c); + + /* TODO Fix wide characters. Bi-width font support? */ + char_width =3D 1; =20 /* If we are about to exceed line length, wrap to next line. */ - if (virtual_screen.cursor_x + glyph.char_width > virtual_screen.colu= mns) + if (virtual_screen.cursor_x + char_width > virtual_screen.columns) grub_putchar ('\n'); =20 /* Find position on virtual screen, and fill information. */ @@ -836,18 +856,18 @@ p->code =3D c; p->fg_color =3D virtual_screen.fg_color; p->bg_color =3D virtual_screen.bg_color; - p->width =3D glyph.char_width - 1; + p->width =3D char_width - 1; p->index =3D 0; =20 /* If we have large glyph, add fixup info. */ - if (glyph.char_width > 1) + if (char_width > 1) { unsigned i; =20 - for (i =3D 1; i < glyph.char_width; i++) + for (i =3D 1; i < char_width; i++) { p[i].code =3D ' '; - p[i].width =3D glyph.char_width - 1; + p[i].width =3D char_width - 1; p[i].index =3D i; } } @@ -856,7 +876,7 @@ write_char (); =20 /* Make sure we scroll screen when needed and wrap line correctly. = */ - virtual_screen.cursor_x +=3D glyph.char_width; + virtual_screen.cursor_x +=3D char_width; if (virtual_screen.cursor_x >=3D virtual_screen.columns) { virtual_screen.cursor_x =3D 0; @@ -876,11 +896,16 @@ static grub_ssize_t grub_gfxterm_getcharwidth (grub_uint32_t c) { - struct grub_font_glyph glyph; - - grub_font_get_glyph (c, &glyph); - - return glyph.char_width; +#if 0 + struct grub_font_glyph *glyph; + + glyph =3D grub_font_get_glyph (c); + + return glyph->char_width; +#else + (void) c; /* Prevent warning. */ + return 1; /* TODO Fix wide characters. */ +#endif } =20 static grub_uint16_t =3D=3D=3D modified file 'term/i386/pc/vesafb.c' --- term/i386/pc/vesafb.c 2007-12-30 08:52:06 +0000 +++ term/i386/pc/vesafb.c 2008-10-30 18:24:32 +0000 @@ -250,10 +250,11 @@ break; =20 default: - return grub_font_get_glyph (code, bitmap, width); + return grub_font_get_glyph_any (code, bitmap, width); } } =20 + /* TODO This is wrong for the new font module. Should it be fixed? */ if (bitmap) grub_memcpy (bitmap, vga_font + code * virtual_screen.char_height, =3D=3D=3D modified file 'term/i386/pc/vga.c' --- term/i386/pc/vga.c 2008-01-21 15:48:27 +0000 +++ term/i386/pc/vga.c 2008-10-30 18:24:32 +0000 @@ -65,6 +65,7 @@ static struct colored_char text_buf[TEXT_WIDTH * TEXT_HEIGHT]; static unsigned char saved_map_mask; static int page =3D 0; +static grub_font_t font =3D 0; =20 #define SEQUENCER_ADDR_PORT 0x3C4 #define SEQUENCER_DATA_PORT 0x3C5 @@ -161,6 +162,9 @@ saved_map_mask =3D get_map_mask (); set_map_mask (0x0f); set_start_address (PAGE_OFFSET (page)); + font =3D grub_font_get (""); /* Choose any font, for now. */ + if (!font) + return grub_error (GRUB_ERR_BAD_FONT, "No font loaded."); =20 return GRUB_ERR_NONE; } @@ -185,7 +189,7 @@ write_char (void) { struct colored_char *p =3D text_buf + xpos + ypos * TEXT_WIDTH; - struct grub_font_glyph glyph; + struct grub_font_glyph *glyph; unsigned char *mem_base; unsigned plane; =20 @@ -194,7 +198,7 @@ p -=3D p->index; =20 /* Get glyph for character. */ - grub_font_get_glyph (p->code, &glyph); + glyph =3D grub_font_get_glyph (font, p->code); =20 for (plane =3D 0x01; plane <=3D 0x08; plane <<=3D 1) { @@ -208,19 +212,23 @@ y < CHAR_HEIGHT; y++, mem +=3D TEXT_WIDTH) { + /* TODO Re-implement glyph drawing for vga module. */ +#if 0 unsigned i; =20 - for (i =3D 0; i < glyph.char_width && offset < 32; i++) + unsigned char_width =3D 1; /* TODO Figure out wide characters. = */ + for (i =3D 0; i < char_width && offset < 32; i++) { unsigned char fg_mask, bg_mask; =20 - fg_mask =3D (p->fg_color & plane) ? glyph.bitmap[offset] : 0; - bg_mask =3D (p->bg_color & plane) ? ~(glyph.bitmap[offset]) : 0; + fg_mask =3D (p->fg_color & plane) ? glyph->bitmap[offset] : 0; + bg_mask =3D (p->bg_color & plane) ? ~(glyph->bitmap[offset]) : 0; offset++; =20 if (check_vga_mem (mem + i)) mem[i] =3D (fg_mask | bg_mask); } +#endif /* 0 */=20 } } =20 @@ -320,36 +328,37 @@ } else { - struct grub_font_glyph glyph; + struct grub_font_glyph *glyph; struct colored_char *p; + unsigned char_width =3D 1; =20 - grub_font_get_glyph(c, &glyph); + glyph =3D grub_font_get_glyph(font, c); =20 - if (xpos + glyph.char_width > TEXT_WIDTH) + if (xpos + char_width > TEXT_WIDTH) grub_putchar ('\n'); =20 p =3D text_buf + xpos + ypos * TEXT_WIDTH; p->code =3D c; p->fg_color =3D fg_color; p->bg_color =3D bg_color; - p->width =3D glyph.char_width - 1; + p->width =3D char_width - 1; p->index =3D 0; =20 - if (glyph.char_width > 1) + if (char_width > 1) { unsigned i; =20 - for (i =3D 1; i < glyph.char_width; i++) + for (i =3D 1; i < char_width; i++) { p[i].code =3D ' '; - p[i].width =3D glyph.char_width - 1; + p[i].width =3D char_width - 1; p[i].index =3D i; } } =20 write_char (); =20 - xpos +=3D glyph.char_width; + xpos +=3D char_width; if (xpos >=3D TEXT_WIDTH) { xpos =3D 0; @@ -381,11 +390,16 @@ static grub_ssize_t grub_vga_getcharwidth (grub_uint32_t c) { +#if 0 struct grub_font_glyph glyph; =20 - grub_font_get_glyph (c, &glyph); + glyph =3D grub_font_get_glyph (c); =20 return glyph.char_width; +#else + (void) c; /* Prevent warning. */ + return 1; /* TODO Fix wide characters? */ +#endif } =20 static grub_uint16_t =3D=3D=3D modified file 'video/i386/pc/vbe.c' --- video/i386/pc/vbe.c 2008-10-03 15:25:34 +0000 +++ video/i386/pc/vbe.c 2008-10-30 18:24:32 +0000 @@ -26,7 +26,6 @@ #include #include #include -#include #include #include #include @@ -896,6 +895,16 @@ =20 return minindex; } + else if ((render_target->mode_info.mode_type=20 + & GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP) !=3D 0) + { + if (red =3D=3D render_target->mode_info.fg_red + && green =3D=3D render_target->mode_info.fg_green + && blue =3D=3D render_target->mode_info.fg_blue) + return 1; + else + return 0; + } else { grub_uint32_t value; @@ -926,6 +935,17 @@ /* No alpha available in index color modes, just use same value as in only RGB modes. */ return grub_video_vbe_map_rgb (red, green, blue); + else if ((render_target->mode_info.mode_type=20 + & GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP) !=3D 0) + { + if (red =3D=3D render_target->mode_info.fg_red + && green =3D=3D render_target->mode_info.fg_green + && blue =3D=3D render_target->mode_info.fg_blue + && alpha =3D=3D render_target->mode_info.fg_alpha) + return 1; + else + return 0; + } else { grub_uint32_t value; @@ -988,6 +1008,24 @@ *alpha =3D framebuffer.palette[color].a; return; } + else if ((mode_info->mode_type + & GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP) !=3D 0) + { + if (color & 1) + { + *red =3D mode_info->fg_red; + *green =3D mode_info->fg_green; + *blue =3D mode_info->fg_blue; + *alpha =3D mode_info->fg_alpha; + } + else + { + *red =3D mode_info->bg_red; + *green =3D mode_info->bg_green; + *blue =3D mode_info->bg_blue; + *alpha =3D mode_info->bg_alpha; + } + } else { grub_uint32_t tmp; @@ -1111,76 +1149,6 @@ return GRUB_ERR_NONE; } =20 -// TODO: Remove this method and replace with bitmap based glyphs -static grub_err_t -grub_video_vbe_blit_glyph (struct grub_font_glyph * glyph, - grub_video_color_t color, int x, int y) -{ - struct grub_video_i386_vbeblit_info target; - unsigned int width; - unsigned int charwidth; - unsigned int height; - unsigned int i; - unsigned int j; - unsigned int x_offset =3D 0; - unsigned int y_offset =3D 0; - - /* Make sure there is something to do. */ - if (x >=3D (int)render_target->viewport.width) - return GRUB_ERR_NONE; - - if (y >=3D (int)render_target->viewport.height) - return GRUB_ERR_NONE; - - /* Calculate glyph dimensions. */ - width =3D ((glyph->width + 7) / 8) * 8; - charwidth =3D width; - height =3D glyph->height; - - if (x + (int)width < 0) - return GRUB_ERR_NONE; - - if (y + (int)height < 0) - return GRUB_ERR_NONE; - - /* Do not allow drawing out of viewport. */ - if (x < 0) - { - width +=3D x; - x_offset =3D (unsigned int)-x; - x =3D 0; - } - if (y < 0) - { - height +=3D y; - y_offset =3D (unsigned int)-y; - y =3D 0; - } - - if ((x + width) > render_target->viewport.width) - width =3D render_target->viewport.width - x; - if ((y + height) > render_target->viewport.height) - height =3D render_target->viewport.height - y; - - /* Add viewport offset. */ - x +=3D render_target->viewport.x; - y +=3D render_target->viewport.y; - - /* Use vbeblit_info to encapsulate rendering. */ - target.mode_info =3D &render_target->mode_info; - target.data =3D render_target->data; - - /* Draw glyph. */ - for (j =3D 0; j < height; j++) - for (i =3D 0; i < width; i++) - if ((glyph->bitmap[((i + x_offset) / 8) - + (j + y_offset) * (charwidth / 8)] - & (1 << ((charwidth - (i + x_offset) - 1) % 8)))) - set_pixel (&target, x+i, y+j, color); - - return GRUB_ERR_NONE; -} - /* NOTE: This function assumes that given coordinates are within bounds of handled data. */ static void @@ -1804,7 +1772,6 @@ .map_rgba =3D grub_video_vbe_map_rgba, .unmap_color =3D grub_video_vbe_unmap_color, .fill_rect =3D grub_video_vbe_fill_rect, - .blit_glyph =3D grub_video_vbe_blit_glyph, .blit_bitmap =3D grub_video_vbe_blit_bitmap, .blit_render_target =3D grub_video_vbe_blit_render_target, .scroll =3D grub_video_vbe_scroll, =3D=3D=3D modified file 'video/i386/pc/vbeutil.c' --- video/i386/pc/vbeutil.c 2007-07-21 22:32:33 +0000 +++ video/i386/pc/vbeutil.c 2008-10-30 18:24:32 +0000 @@ -52,6 +52,11 @@ + y * source->mode_info->pitch + x; break; + + /* case 1: */ + /* For 1-bit bitmaps, addressing needs to be done at the bit level + * and it doesn't make sense, in general, to ask for a pointer + * to a particular pixel's data. */ } =20 return ptr; @@ -86,6 +91,17 @@ color =3D *(grub_uint8_t *)get_data_ptr (source, x, y); break; =20 + case 1: + if (source->mode_info->blit_format =3D=3D GRUB_VIDEO_BLIT_FORMAT_1BI= T_PACKED) + { + int bit_index =3D y * source->mode_info->width + x; + grub_uint8_t *ptr =3D (grub_uint8_t *)source->data + + bit_index / 8; + int bit_pos =3D 7 - bit_index % 8; + color =3D (*ptr >> bit_pos) & 0x01; + } + break; + default: break; } @@ -143,6 +159,17 @@ } break; =20 + case 1: + if (source->mode_info->blit_format =3D=3D GRUB_VIDEO_BLIT_FORMAT_1BI= T_PACKED) + { + int bit_index =3D y * source->mode_info->width + x; + grub_uint8_t *ptr =3D (grub_uint8_t *)source->data + + bit_index / 8; + int bit_pos =3D 7 - bit_index % 8; + *ptr =3D (*ptr & ~(1 << bit_pos)) | ((color & 0x01) << bit_pos); + } + break; + default: break; } =3D=3D=3D modified file 'video/video.c' --- video/video.c 2008-10-03 15:25:34 +0000 +++ video/video.c 2008-10-30 18:24:32 +0000 @@ -336,17 +336,6 @@ return grub_video_adapter_active->fill_rect (color, x, y, width, height); } =20 -/* Blit glyph to screen using specified color. */ -grub_err_t -grub_video_blit_glyph (struct grub_font_glyph *glyph, - grub_video_color_t color, int x, int y) -{ - if (! grub_video_adapter_active) - return grub_error (GRUB_ERR_BAD_DEVICE, "No video mode activated"); - - return grub_video_adapter_active->blit_glyph (glyph, color, x, y); -} - /* Blit bitmap to screen. */ grub_err_t grub_video_blit_bitmap (struct grub_video_bitmap *bitmap, --MP_/gl5hFA.k5o19toXYw/TFnHO-- --Sig_/5JJPp8f2UUZ.fQ3Lqt3ogW+ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkKgjQACgkQokx8fzcGbYeHogCdEABi3ngVLZlSLpt3MUflqPte U50An240EDlZsz1w09AD/7Bzm3Q9KS+P =t+6+ -----END PGP SIGNATURE----- --Sig_/5JJPp8f2UUZ.fQ3Lqt3ogW+-- From MAILER-DAEMON Fri Oct 31 14:31:38 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KvymY-0001CU-GF for mharc-grub-devel@gnu.org; Fri, 31 Oct 2008 14:31:38 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KvymV-0001B3-Kx for grub-devel@gnu.org; Fri, 31 Oct 2008 14:31:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvymT-0001AQ-Pc for grub-devel@gnu.org; Fri, 31 Oct 2008 14:31:35 -0400 Received: from [199.232.76.173] (port=60676 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvymT-0001AM-LO for grub-devel@gnu.org; Fri, 31 Oct 2008 14:31:33 -0400 Received: from el-out-1112.google.com ([209.85.162.179]:63839) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KvymT-0005Nb-Ie for grub-devel@gnu.org; Fri, 31 Oct 2008 14:31:33 -0400 Received: by el-out-1112.google.com with SMTP id n30so774354elf.12 for ; Fri, 31 Oct 2008 11:31:31 -0700 (PDT) Received: by 10.150.52.10 with SMTP id z10mr6000691ybz.130.1225477891422; Fri, 31 Oct 2008 11:31:31 -0700 (PDT) Received: by 10.150.191.2 with HTTP; Fri, 31 Oct 2008 11:31:31 -0700 (PDT) Message-ID: Date: Fri, 31 Oct 2008 18:31:31 +0000 From: "Matt Sturgeon" Sender: capt.gen@bberry.biz To: "The development of GRUB 2" In-Reply-To: <20081030205736.7e080a5e@gibibit.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_22376_22036252.1225477891414" References: <20080901092753.3918cf73@gamma.lan> <20081004214640.5ab21f53@gibibit.com> <48E87FB9.8070603@nic.fi> <20081030121106.4efffecc@gibibit.com> <20081030205736.7e080a5e@gibibit.com> X-Google-Sender-Auth: fc561cc7103bb345 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [PATCH] GSoC #10 new font engine (UTF-8 support+bugfix) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 18:31:36 -0000 ------=_Part_22376_22036252.1225477891414 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline will all these fonts be included in the next release of GRUB 2? 2008/10/31 Colin D Bennett > Update: > > I fixed an error pointed out to me by Y.Volta: > In grub_font_get(), if no fonts are loaded, a null pointer is > dereferenced. This is fixed in the attached patch. > > The grub_font_get() function now returns a dummy font object (a > statically allocated font object with no characters) so that callers of > grub_font_get() can be assured that the return value will never be > NULL. If no fonts are loaded, then the "unknown glyph" will be used > for all characters, but it will be safe. > > Regards, > Colin > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > ------=_Part_22376_22036252.1225477891414 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline will all these fonts be included in the next release of GRUB 2?

2008/10/31 Colin D Bennett <colin@gibibit.com>
Update:

I fixed an error pointed out to me by Y.Volta:
In grub_font_get(), if no fonts are loaded, a null pointer is
dereferenced.  This is fixed in the attached patch.

The grub_font_get() function now returns a dummy font object (a
statically allocated font object with no characters) so that callers of
grub_font_get() can be assured that the return value will never be
NULL.  If no fonts are loaded, then the "unknown glyph" will be used
for all characters, but it will be safe.

Regards,
Colin

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


------=_Part_22376_22036252.1225477891414-- From MAILER-DAEMON Fri Oct 31 15:52:07 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kw02R-0006eh-QU for mharc-grub-devel@gnu.org; Fri, 31 Oct 2008 15:52:07 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kw02P-0006cs-JS for grub-devel@gnu.org; Fri, 31 Oct 2008 15:52:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kw02N-0006bL-5K for grub-devel@gnu.org; Fri, 31 Oct 2008 15:52:04 -0400 Received: from [199.232.76.173] (port=47334 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kw02M-0006b4-O0 for grub-devel@gnu.org; Fri, 31 Oct 2008 15:52:02 -0400 Received: from gateway12.websitewelcome.com ([67.18.22.86]:52190) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Kw02M-00016Y-LV for grub-devel@gnu.org; Fri, 31 Oct 2008 15:52:02 -0400 Received: (qmail 2930 invoked from network); 31 Oct 2008 20:02:45 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway12.websitewelcome.com with SMTP; 31 Oct 2008 20:02:45 -0000 Received: from spk.venturedesignservices.com ([65.61.115.34]:44369 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Kw02I-0004ZD-Dj; Fri, 31 Oct 2008 14:51:58 -0500 Date: Fri, 31 Oct 2008 12:50:32 -0700 From: Colin D Bennett To: The development of GRUB 2 Message-ID: <20081031125032.13ab8b06@gibibit.com> In-Reply-To: References: <20080901092753.3918cf73@gamma.lan> <20081004214640.5ab21f53@gibibit.com> <48E87FB9.8070603@nic.fi> <20081030121106.4efffecc@gibibit.com> <20081030205736.7e080a5e@gibibit.com> X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/3YG2w/_bOTyXm+Nj_TenW7a"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: mttza1@gmail.com Subject: Re: [PATCH] GSoC #10 new font engine (UTF-8 support+bugfix) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 19:52:05 -0000 --Sig_/3YG2w/_bOTyXm+Nj_TenW7a Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 31 Oct 2008 18:31:31 +0000 "Matt Sturgeon" wrote: > will all these fonts be included in the next release of GRUB 2? Probably not; the licenses may not be compatible with GPLv3. These fonts are ones that came with X.Org on my system, and I just exported them to BDF files with 'xmbdfed' and then converted the BDF files to PF2 files with the GRUB font converter. Some of the fonts I used during my development of the graphical menu system are from the "Artwiz" bitmap font collection, which is a set of several fonts, but most all quite small in size (really no selection of font size within a font). I haven't spent a lot of time seeking out good free fonts that we could include in GRUB. I use the fabulous Liberation TrueType fonts on my desktop, but these are outline fonts, not bitmap fonts. I tried creating a bitmap font from some decent TrueType outline fonts using xmbdfed, but the results were quite ugly, so I gave up on that. Regards, Colin --Sig_/3YG2w/_bOTyXm+Nj_TenW7a Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkLYYoACgkQokx8fzcGbYdQ3wCfWI9RHnnmKUNLg+tFnxTH5/Qc yScAoIEchh/+B1Yw3/E9uyIcUiGrHpom =6OCQ -----END PGP SIGNATURE----- --Sig_/3YG2w/_bOTyXm+Nj_TenW7a--