From: "Suzuki K. Poulose" <suzuki@in.ibm.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: lethal@linux-sh.org, horms@verge.net.au,
kexec@lists.infradead.org, mat@brain-dump.org
Subject: Re: [PATCH 3/3] ppc/uImage: Add support for RAM Disks
Date: Thu, 17 Jan 2013 15:17:19 +0530 [thread overview]
Message-ID: <50F7C8A7.4000100@in.ibm.com> (raw)
In-Reply-To: <20130116172601.GB20369@linutronix.de>
On 01/16/2013 10:56 PM, Sebastian Andrzej Siewior wrote:
> * Suzuki K. Poulose | 2013-01-11 12:12:11 [+0530]:
>
> only some stylish comments…
>
>> diff --git a/kexec/arch/ppc/kexec-uImage-ppc.c b/kexec/arch/ppc/kexec-uImage-ppc.c
>> index eaea3c1..58935c0 100644
>> --- a/kexec/arch/ppc/kexec-uImage-ppc.c
>> +++ b/kexec/arch/ppc/kexec-uImage-ppc.c
>> @@ -46,6 +46,26 @@ void uImage_ppc_usage(void)
>> );
>> }
>>
>> +char* slurp_ramdisk_ppc(const char *filename, off_t *r_size)
> char *slurp_ramdisk_ppc(const char *filename, off_t *r_size)
> ?
OK
>
>> +{
>> + struct Image_info img;
>> + off_t size;
>> + const unsigned char *buf =
>> + (const unsigned char *)slurp_file(filename, &size);
>
> is the const cast required here?
Yes, the uImage_probe() expects (const unsigned char *) as the first
argument.
>
>> + /* Check if this is a uImage RAMDisk */
>> + if (buf != (void*)0 &&
> this should be NULL if at all
>
OK
>> + uImage_probe(buf, size, IH_ARCH_PPC) == IH_TYPE_RAMDISK) {
> and maybe splitted in more than one line
>
OK
>> + if (uImage_load(buf, size, &img) != 0)
>> + die ("uImage: Reading %ld bytes from %s failed\n", size, filename);
> no space between the function.
>
OK
>> + buf = img.buf;
>> + size = img.len;
>> + }
>> +
>> + *r_size = size;
>> + return buf;
>> +}
>> +
>> int uImage_ppc_probe(const char *buf, off_t len)
>> {
>> int type;
>> @@ -196,7 +216,7 @@ static int ppc_load_bare_bits(int argc, char **argv, const char *buf,
>> blob_buf = fixup_dtb_init(info, blob_buf, &blob_size, load_addr, &dtb_addr);
>>
>> if (ramdisk) {
>> - seg_buf = slurp_file(ramdisk, &seg_size);
>> + seg_buf = slurp_ramdisk_ppc(ramdisk, &seg_size);
>
> I'm not sure but this kinda breaks the case where someone was using a
> plain file without the uImage header. I don't know if someone used this
> at all but it seems we have code for this. The way you load the uImage
> is very generic and I would expect to load it the same way on ARM or SH.
>
If the ramdisk doesn't have uImage header, the slurp_ramdisk_ppc()
defaults to the original behaviour. i.e, it just does a slurp_file()
as it used to do earlier.
> One thing that is different compared to kernel: If the compression is
> set to GZ on a ramdisk image you should not uncompress it. I think that
> uImage_load() decompresses the .gz part for you but I am not sure.
>
Did you mean, uImage_load() shouldn't do a decompression for ramdisk ?
We rely on uImage_load to get what is required.
>> /* Load ramdisk at top of memory */
>> hole_addr = add_buffer(info, seg_buf, seg_size, seg_size,
>> 0, dtb_addr + blob_size, max_addr, -1);
>>
>
Thanks for the detailed review.
Suzuki
> Sebastian
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-01-17 9:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-11 6:41 [PATCH 0/3] kexec: Support for uImage RAMDisks Suzuki K. Poulose
2013-01-11 6:41 ` [PATCH 1/3] kexec/uImage: Return the image type for uImage_probe Suzuki K. Poulose
2013-01-16 17:20 ` Sebastian Andrzej Siewior
2013-01-17 3:10 ` Suzuki K. Poulose
2013-01-11 6:41 ` [PATCH 2/3] kexec/uImage: Recognize uImage RAM Disks Suzuki K. Poulose
2013-01-11 6:42 ` [PATCH 3/3] ppc/uImage: Add support for " Suzuki K. Poulose
2013-01-11 7:11 ` McClintock Matthew-B29882
2013-01-14 5:14 ` Suzuki K. Poulose
2013-01-14 15:14 ` McClintock Matthew-B29882
2013-01-16 17:30 ` Sebastian Andrzej Siewior
2013-01-16 17:37 ` McClintock Matthew-B29882
2013-01-16 17:26 ` Sebastian Andrzej Siewior
2013-01-17 9:47 ` Suzuki K. Poulose [this message]
2013-01-27 16:39 ` Sebastian Andrzej Siewior
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=50F7C8A7.4000100@in.ibm.com \
--to=suzuki@in.ibm.com \
--cc=bigeasy@linutronix.de \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=lethal@linux-sh.org \
--cc=mat@brain-dump.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.