All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: WANG Chao <chaowang@redhat.com>
Cc: kexec@lists.infradead.org, horms@verge.net.au, linn@hp.com,
	hpa@zytor.com, dyoung@redhat.com, trenn@suse.de,
	ebiederm@xmission.com
Subject: Re: [PATCH v4 4/4] x86: Pass memory range via E820 for kdump
Date: Fri, 28 Mar 2014 09:53:13 -0400	[thread overview]
Message-ID: <20140328135313.GD2089@redhat.com> (raw)
In-Reply-To: <20140328045254.GB2944@dhcp-17-89.nay.redhat.com>

On Fri, Mar 28, 2014 at 12:52:54PM +0800, WANG Chao wrote:

[..]
> > > +static void add_setup_data(struct kexec_info *info,
> > > +			   struct x86_linux_param_header *real_mode,
> > > +			   struct setup_data *sd)
> > > +{
> > 
> > What is setup_data? A little comment above function will make it easy
> > to read. Is it that list of elements which contains extra memory map
> > entries?
> 
> Not exactly. All extra memory maps (for SETUP_E820_EXT type) are
> sealed into a single setup_data structure. Different types of setup_data
> are linked in a list.
> 
> setup_data can be used to pass extra data for boot, for example EFI
> data (SETUP_EFI), extended E820 map (SETUP_E820_EXT), SETUP_PCI and
> SETUP_DTB. These types are defined when defining struct setup_data.
> 
> It's offically documented in Documentation/x86/boot.txt.
> 
> Field name:	setup_data
> Type:		write (special)
> Offset/size:	0x250/8
> Protocol:	2.09+
> 
>   The 64-bit physical pointer to NULL terminated single linked list of
>   struct setup_data. This is used to define a more extensible boot
>   parameters passing mechanism. The definition of struct setup_data
>   is as follow:
> 
>   struct setup_data {
> 	  u64 next;
> 	  u32 type;
> 	  u32 len;
> 	  u8  data[0];
>   };
> 
>   Where, the next is a 64-bit physical pointer to the next node of
>   linked list, the next field of the last node is 0; the type is used
>   to identify the contents of data; the len is the length of data
>   field; the data holds the real payload.
> 
>   This list may be modified at a number of points during the bootup
>   process. Therefore, when modifying this list one should always make
>   sure to consider the case where the linked list already contains
>   entries.
> 
> I think I would comment add_setup_data as follows:
> 
> /*
>  * Added another instance to single linked list of struct setup_data.
>  * Please refer to kernel Documentation/x86/boot.txt for more details
>  * about setup_data structure.
>  */

Thanks for the explanation. Above comment will help the reader.

Thanks
Vivek

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

  reply	other threads:[~2014-03-28 13:53 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19  8:03 [PATCH v4 0/4] kexec-tools, x86: E820 memmap pass for kdump WANG Chao
2014-03-19  8:03 ` [PATCH v4 1/4] cleanup: add dbgprint_mem_range function WANG Chao
2014-03-20  3:49   ` Simon Horman
2014-03-19  8:03 ` [PATCH v4 2/4] x86: Store memory ranges globally used for crash kernel to boot into WANG Chao
2014-03-27 22:32   ` Vivek Goyal
2014-03-28  5:23     ` WANG Chao
2014-03-28 14:01       ` Vivek Goyal
2014-03-28 15:44       ` Thomas Renninger
2014-03-28 16:05         ` Vivek Goyal
2014-03-28  2:19   ` Dave Young
2014-03-28  5:36     ` WANG Chao
2014-03-28  3:24   ` Dave Young
2014-03-28  6:13     ` WANG Chao
2014-03-28  6:43       ` Dave Young
2014-03-28  6:51         ` Dave Young
2014-03-28  7:12           ` Dave Young
2014-04-01  7:04         ` WANG Chao
2014-04-01  8:41           ` Dave Young
2014-04-01  8:54             ` WANG Chao
2014-04-01  9:36               ` Dave Young
2014-04-01  9:52                 ` WANG Chao
2014-03-19  8:04 ` [PATCH v4 3/4] x86: add --pass-memmap-cmdline option WANG Chao
2014-03-19  8:04 ` [PATCH v4 4/4] x86: Pass memory range via E820 for kdump WANG Chao
2014-03-27 22:50   ` Vivek Goyal
2014-03-28  4:52     ` WANG Chao
2014-03-28 13:53       ` Vivek Goyal [this message]
2014-03-28  3:28   ` Dave Young
2014-03-28  4:53     ` WANG Chao
2014-03-19 17:57 ` [PATCH v4 0/4] kexec-tools, x86: E820 memmap pass " Linn Crosetto
2014-03-20  3:50   ` Simon Horman
2014-03-20  5:00     ` WANG Chao
2014-03-20 15:42 ` Vivek Goyal
2014-03-27 10:31   ` WANG Chao
2014-03-27 22:23     ` Vivek Goyal

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=20140328135313.GD2089@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=chaowang@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=horms@verge.net.au \
    --cc=hpa@zytor.com \
    --cc=kexec@lists.infradead.org \
    --cc=linn@hp.com \
    --cc=trenn@suse.de \
    /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.