All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Alexander Aring <alex.aring@gmail.com>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH] read_file: Make it work on tftp servers which do not pass size
Date: Thu, 20 Jun 2013 10:12:28 +0200	[thread overview]
Message-ID: <20130620081228.GP32299@pengutronix.de> (raw)
In-Reply-To: <20130620072843.GA2086@x61s>

On Thu, Jun 20, 2013 at 09:28:44AM +0200, Alexander Aring wrote:
> Hi Sascha,
> 
> > 
> > No no, you were right. This indeed has to be a loff_t. Where did you
> > find that the fs layer uses size_t? It should do so only for the length
> > arguments of read/write and friends.
> > 
> 
> In function read_file :). The parameter size should be changed to
> loff_t instead of size_t, because we make "*size = s.st_size;".
> 
> 
> 
> The point is, that a file can be greater than 4GB, but we _can't_
> read/write a "block" from a file that is greather than 4GB.
> 
> But in this function we do "read(fd, buf, s.st_size) < s.st_size", this
> need to be in small (max) 4GB pieces(if necessary). In other words, we
> can't use s.st_size here if the file is greater than ((size_t)-1).
> 
> I don't think if we need something like this, because we never handle
> files which are greater than 4GB.
> 
> That's my point of view. This example is only for a 32Bit architecture.

Ok, so read_file is broken for files > 4GiB. I think we can live with
this for a while ;)

BTW the maximum memory size the tlsf allocator can handle is 1GiB, we
have to overcome this first.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2013-06-20  8:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-19 20:58 [PATCH] read_file: Make it work on tftp servers which do not pass size Sascha Hauer
2013-06-19 21:32 ` Alexander Aring
2013-06-19 21:57   ` Alexander Aring
2013-06-20  6:42     ` Sascha Hauer
2013-06-20  7:28       ` Alexander Aring
2013-06-20  8:12         ` Sascha Hauer [this message]
2013-06-20 11:15 ` Jan Weitzel
2013-06-20 15:24   ` Sascha Hauer
2013-06-21  7:03     ` Jan Weitzel
2013-06-21  7:10       ` Sascha Hauer
2013-06-21  7:46         ` Jan Weitzel
2013-06-21  8:21           ` Sascha Hauer

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=20130620081228.GP32299@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=alex.aring@gmail.com \
    --cc=barebox@lists.infradead.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.