All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: Bug report: PXE blocksize
Date: Fri, 03 Sep 2010 00:01:17 +0200	[thread overview]
Message-ID: <4C801EAD.5070703@gmail.com> (raw)
In-Reply-To: <D1A3B6E525F5F943AB9D12DED819DD5F013EAFC8@NYCMBX3.winmail.deshaw.com>

[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]

On 08/30/2010 04:52 PM, Turner, Ian wrote:
>> I don't see where you mean. The only reference to pxe_blksize I see in
>> pxefs_read is following:
>>       o.packet_size = grub_pxe_blksize;
>>       grub_pxe_call (GRUB_PXENV_TFTP_OPEN, &o);
>> Which is called only when reopening file. Could you retry pulling? Now
>> newreloc is merged into mainline so you can just pull mainline.
>>     
> You're right. The problem is more complex that I thought originally. I think it's something more like this:
>
> 1. Start loading a file 'grub.cfg' with blksize=512
> 2. File contains a directive to change blocksize to something else (e.g., 1024). This updates grub_pxe_blksize but doesn't change the parameters of the grub.cfg session.
> 3. File also contains a directive that causes grub to load some other file (say, an insmod or source command). This causes pxe.c to close grub.cfg for now, but the grub_pxe_data object sticks around.
> 4. Upon resuming read of grub.cfg, pxe opens with the new blocksize but reads with the old one.
>
> I still think the solution is what I proposed originally (patch follows), which maintains the same PXE blocksize for a given file until it is finally closed by the requestor, no matter how many times PXE itself needs to open/close the TFTP session.
>   
There are 2 problems with changing blocksize in the middle of the stream:
1) pn isn't recomputed. Easy to fix
2) bufio doesn't change the size. Difficult and ugly to fix.
So I applied your patch. Thanks
> --- pxe-broken.c        2010-08-30 10:52:03.717580213 -0400
> +++ pxe-fixed.c 2010-08-30 10:52:49.370957060 -0400
> @@ -281,7 +281,7 @@
>        o.gateway_ip = disk_data->gateway_ip;
>        grub_strcpy ((char *)&o.filename[0], data->filename);
>        o.tftp_port = grub_cpu_to_be16 (GRUB_PXE_TFTP_PORT);
> -      o.packet_size = grub_pxe_blksize;
> +      o.packet_size = data->block_size;
>        grub_pxe_call (GRUB_PXENV_TFTP_OPEN, &o);
>        if (o.status)
>         {
>
> Cheers,
>
> --Ian
>
>   
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

      reply	other threads:[~2010-09-02 22:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-27 15:57 Bug report: PXE blocksize Turner, Ian
2010-08-30  0:06 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-08-30 14:52   ` Turner, Ian
2010-09-02 22:01     ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C801EAD.5070703@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.