AU: Include the old/new kernel/rootfs size/hash in the update metadata.

AU: Include the old/new kernel/rootfs size/hash in the update metadata.

This is the server side change.

BUG=7348
TEST=unit test

Change-Id: I956e056826dbb13b0f97509f9992ebcedb48ea42

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=36a5822

[petkov, 2010-10-08 00:32:47]

Do we need to bump any version number?

Also, a slight issue is that we include this data in the manifest. However, we
don't part the manifest until after the FilesystemCopier is done. So, to verify
the original hash, we would need to do another read of the source rootfs. Unless
the FilesystemCopier can be smarter and copy just the filesystem bytes rather
than the full partition. Thoughts?

[adlr, 2010-10-08 01:21:58]

LGTM

No version number bump needed, since this is all backward compatible.

As for the lengths, we could hard-code it :/

I emailed will drewry since he had to deal w/ this for verified rootfs, so i'll
see if he has any tricks.

http://codereview.chromium.org/3588015/diff/4001/5003
File omaha_hash_calculator.cc (right):

http://codereview.chromium.org/3588015/diff/4001/5003#newcode52
omaha_hash_calculator.cc:52: ssize_t rc = HANDLE_EINTR(read(fd, &buffer[0],
bytes_to_read));
I never heard of HANDLE_EINTR and just looked it up. What's the deal w/ it?

[adlr, 2010-10-08 02:04:52]

On Thu, Oct 7, 2010 at 6:21 PM, <adlr@chromium.org> wrote:

> LGTM
>
> No version number bump needed, since this is all backward compatible.
>
> As for the lengths, we could hard-code it :/
>
> I emailed will drewry since he had to deal w/ this for verified rootfs, so
> i'll
> see if he has any tricks.
>

So, he says you can use dumpe2fs to get the block count, and that's the
filesystem size. You could probably just peek in the superblock if you
wanted to avoid calling another program.

-andrew


>
>
> http://codereview.chromium.org/3588015/diff/4001/5003
> File omaha_hash_calculator.cc (right):
>
> http://codereview.chromium.org/3588015/diff/4001/5003#newcode52
> omaha_hash_calculator.cc:52: ssize_t rc = HANDLE_EINTR(read(fd,
> &buffer[0], bytes_to_read));
> I never heard of HANDLE_EINTR and just looked it up. What's the deal w/
> it?
>
>
> http://codereview.chromium.org/3588015/show
>

[petkov, 2010-10-08 04:14:29]

Thanks, I'll submit this server side change then.

http://codereview.chromium.org/3588015/diff/4001/5003
File omaha_hash_calculator.cc (right):

http://codereview.chromium.org/3588015/diff/4001/5003#newcode52
omaha_hash_calculator.cc:52: ssize_t rc = HANDLE_EINTR(read(fd, &buffer[0],
bytes_to_read));
On 2010/10/08 01:21:58, adlr wrote:
> I never heard of HANDLE_EINTR and just looked it up. What's the deal w/ it?

open/read/close can theoretically (but somewhat unlikely) be  interrupted by
system calls and return -1 with errno set to EINTR. In these cases you have to
reinvoke the calls. HANDLE_EINTR is a macro in libbase that wraps the system
calls so you don't have to explicitly check and re-invoke them when they're
interrupted -- it does it for you.