Re: [PATCH 7/7] Add support for ARM UEFI ("EFI") platforms
On Wed, Apr 03, 2013 at 10:01:59PM +0200, Vladimir '??-coder/phcoder' Serbinenko wrote: > > I don't see grub-mkimage currently being fully cross-platform anyway, > > so I would (as mentioned in previous email) prefer to postpone any > > such adjustments until the basic support is in. I have the patches > > for it, if not entirely up to date. > > grub-mkimage is fully cross-platform and is intended to be usable this > way. If you see a problem, please tell. Well, the straightforward relocations for EM_386 and EM_X86_64 look OK, but much of the fiddly IA64 patching that goes on in grub-mkimagexx.c (add_value_to_slot_* and make_trampoline) does not appear endianess-safe to me. Since I didn't want to have to duplicate my relocation handling between kernel and grub-mkimage, I use kern/arm/dl.c for both. In order to do that in an endianess-safe way, I need to be able to export target platform information over there, as well as the host_to_target/target_to_host macros. This would involve moving these macros, as well as the struct image_target_desc definition, out of grub-mkimage.c. However, this would also make it possible to do the same for IA64, and get rid of some code duplication between grub-mkimagexx.c and kern/ia64/dl.c. / Leif ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Make grub_efidisk_get_device_name() work on 4K native disks.
On Wed, Apr 03, 2013 at 11:03:46PM +0400, Andrey Borzenkov wrote: > В Wed, 3 Apr 2013 11:53:06 -0400 > Peter Jones пишет: > > > When we have 4kB sectors instead of 512b sectors, hd.partition_start and > > grub_partition_get_start() won't match - the latter assumes 512-byte > > sectors, and the former gives us the correct number based on the > > physical media's sector size. So when we have to compare them, we need > > to compensate. > > > > Signed-off-by: Peter Jones > > --- > > grub-core/disk/efi/efidisk.c | 10 ++ > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/grub-core/disk/efi/efidisk.c b/grub-core/disk/efi/efidisk.c > > index 77ab5b0..a905b52 100644 > > --- a/grub-core/disk/efi/efidisk.c > > +++ b/grub-core/disk/efi/efidisk.c > > @@ -791,11 +791,13 @@ grub_efidisk_get_device_name (grub_efi_handle_t > > *handle) > >auto int find_partition (grub_disk_t disk, const grub_partition_t > > part); > > > > You need to rebase to current trunk which does not use nested functions > anymore. Also in current trunk there is second use of > grub_partition_get_start() which looks like it has the same issue. Oh, indeed, you're right, that has changed. Although the current tree looks like it already takes this in to consideration. So nevermind then :) Thanks for having a look. -- Peter ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Make grub_efidisk_get_device_name() work on 4K native disks.
В Thu, 4 Apr 2013 13:52:05 -0400 Peter Jones пишет: > On Wed, Apr 03, 2013 at 11:03:46PM +0400, Andrey Borzenkov wrote: > > В Wed, 3 Apr 2013 11:53:06 -0400 > > Peter Jones пишет: > > > > > When we have 4kB sectors instead of 512b sectors, hd.partition_start and > > > grub_partition_get_start() won't match - the latter assumes 512-byte > > > sectors, and the former gives us the correct number based on the > > > physical media's sector size. So when we have to compare them, we need > > > to compensate. > > > > > > Signed-off-by: Peter Jones > > > --- > > > grub-core/disk/efi/efidisk.c | 10 ++ > > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > > > diff --git a/grub-core/disk/efi/efidisk.c b/grub-core/disk/efi/efidisk.c > > > index 77ab5b0..a905b52 100644 > > > --- a/grub-core/disk/efi/efidisk.c > > > +++ b/grub-core/disk/efi/efidisk.c > > > @@ -791,11 +791,13 @@ grub_efidisk_get_device_name (grub_efi_handle_t > > > *handle) > > >auto int find_partition (grub_disk_t disk, const grub_partition_t > > > part); > > > > > > > You need to rebase to current trunk which does not use nested functions > > anymore. Also in current trunk there is second use of > > grub_partition_get_start() which looks like it has the same issue. > > Oh, indeed, you're right, that has changed. Although the current tree looks > like it already takes this in to consideration. > Hmm ... I do not see it. Your change looks still necessary. > So nevermind then :) > > Thanks for having a look. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 5/7] add imported "FDT" module for flattened device tree operations
On 04/02/2013 10:39 PM, Phillip Susi wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Your patches can not be reviewed inline because your mail client is > incorrectly setting the mime type to application/octet-stream and the > disposition to attachment. Please fix this. Actually the mime types are correct (text/x-csrc and text/x-cdhr). You are right about the content disposition though, my mail client ignores this option when displaying e-mails so I can actually view attachments inline even though the message source says differently. Will make sure to have this fixed next time. -- Francesco ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 5/7] add imported "FDT" module for flattened device tree operations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/4/2013 2:22 PM, Francesco Lavra wrote: > On 04/02/2013 10:39 PM, Phillip Susi wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> Your patches can not be reviewed inline because your mail client >> is incorrectly setting the mime type to application/octet-stream >> and the disposition to attachment. Please fix this. > > Actually the mime types are correct (text/x-csrc and text/x-cdhr). > You are right about the content disposition though, my mail client > ignores this option when displaying e-mails so I can actually view > attachments inline even though the message source says > differently. Will make sure to have this fixed next time. Quoting the headers from your original message: Content-Type: application/octet-stream; name="0005-fdt-support.patch" Additionally it used base64 encoding so it was treating the file as binary data, and encoding it to use more space that needed. Also you appear to be using the now popular and vile reply-to-list function to send replies only to the mailing list. This misfeature breaks cross posting, non subscribed posters, and delays people from seeing your response when they do not frequently check all of the mailing lists they are subscribed to, so please use reply-to-all instead. See http://david.woodhou.se/reply-to-list.html for more information. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRXc41AAoJEJrBOlT6nu75qH8H/0DRzBi5mJp5jhCTOSvFVOJl 9GlA20pad+IV9qMAKAV1OKe5zCe8izr24uG0Vc8+cH4p8CkieEMwyT36t/4oQ3hl kkQhJYnlNK9rodsIEoX8jbYvR/7iBbc6g8Bv8EoomAwgEcTVoERD4hpsYgrzZf73 AeSLf/HQAtnOptSwcf9JEHnhXFEubK30DmU7vqW187Brgx2PONwcvv7lLsw8mBXV Zmk9HOlSAH8fZ1eZ1yX42eN8vlaCEa6VldMpY1ijx2LNaHVBTjXlKTlJvltHyTxU VXOpEDNjkcNQRpf5oqt9h86O5vt1q86KJQowLauZubcK+K4XED8m8OYaB7CxAQo= =AaaX -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 5/7] add imported "FDT" module for flattened device tree operations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 В Thu, 04 Apr 2013 15:02:13 -0400 Phillip Susi пишет: >Also you > appear to be using the now popular and vile reply-to-list function to > send replies only to the mailing list. Actually list sets Reply-To, so it is not necessary reply-to-list. > so please use reply-to-all instead. > And I was so often chastised exactly for using reply-to-all. So what do you suggest when one subscriber requests reply-to-list and another - reply-to-all? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFd0U4ACgkQR6LMutpd94zsrACfYN31F0bdWblZ8K9KSjoCEoqz mogAnjl91W2Z47t7ioh0716uYml4z8uI =rzWI -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 5/7] add imported "FDT" module for flattened device tree operations
[Using reply-to-all now...] On 04/04/2013 09:02 PM, Phillip Susi wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 4/4/2013 2:22 PM, Francesco Lavra wrote: >> On 04/02/2013 10:39 PM, Phillip Susi wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>> >>> Your patches can not be reviewed inline because your mail client >>> is incorrectly setting the mime type to application/octet-stream >>> and the disposition to attachment. Please fix this. >> >> Actually the mime types are correct (text/x-csrc and text/x-cdhr). >> You are right about the content disposition though, my mail client >> ignores this option when displaying e-mails so I can actually view >> attachments inline even though the message source says >> differently. Will make sure to have this fixed next time. > > Quoting the headers from your original message: > > Content-Type: application/octet-stream; name="0005-fdt-support.patch" I realize now that your comments were addressed to Leif and not me. Sorry for the noise. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 5/7] add imported "FDT" module for flattened device tree operations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/4/2013 3:15 PM, Andrey Borzenkov wrote: > Actually list sets Reply-To, so it is not necessary reply-to-list. Only badly behaved ones do. This field is for the SENDER to set ( for instance, if they do not want to get a duplicate reply and have the reply only to to the mailing list ), not the mailing list. See http://www.unicom.com/pw/reply-to-harmful.html. >> so please use reply-to-all instead. > And I was so often chastised exactly for using reply-to-all. Then they were wrong. > So what do you suggest when one subscriber requests reply-to-list > and another - reply-to-all? Always use reply-to-all. If a subscriber does not want to get a direct reply, they can simply set the reply-to header to point to the mailing list and they won't get a duplicate reply, but other people who want the reply, or messages cross posted to multiple mailing lists will not be broken. Alternatively they can set up a filter to notice when the message has been sent to both them and a mailing list they subscribe to and delete the duplicate. Another alternative is offered by most mailing lists where you can configure it to not send you a copy of the message if you are already listed in the to or cc. Any way you do it, the onus is on the person not wanting the duplicate to avoid it, not on everyone else, especially when doing so causes some people who should get a copy of the message not to, which is much more harmful than someone getting a duplicate copy they don't want. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRXdWIAAoJEJrBOlT6nu7543QIAMs3qO2yqDRVVChrUGtv54wt M2VZx1+fyq3JJB3lvNQ1AfNAzqMFUZFK+rj3ugEdg1dCF0J+16kyMV4XO68wm4eb k1vHxfrjFxL+6wzMLun5LYTDU1u2NjlYhnTktKxlsMJd6xslB8vC9MwnXrsCe1Xc QCId4v5+FlM2Gt1kyf2MZzBEJ6CJfvds8i3DEA4GJJNGcylqd5gYLH5vyH9sveIP mP+ahqdPT1xnKN4q/+TrZtnKwXIRIg/rSVBBNt9Rru4GFwv5zZ5bZyLNyq8ilc13 wR1l6EDB5SHBZp/7Tgk1/ZHBb8S9Wcwu4kK6BeTs+SwkTcIuMA9mN4l4AGI/klc= =P+7M -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] docs/grub-dev.texi: Fix out of place @itemize and fix makeinfo warnings
In @node Bitmap_API, @itemize is not in the @subsection, and causes makeinfo to return 1. Fix this and move sections in the texi to match the menu order to get rid of the warnings. I'm new to bzr and contributing to grub. This unified patch applies against trunk/grub. I've looked around and found a contribution workflow from 2010 in the ML archives, and followed those directions. If there is a better way, please advise. Thanks, -Bryan cleanup_warnings_grub-dev_texi.patch Description: Binary data ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
