[MULTIBOOT2,DOC,v3,01/13] multiboot2: Replace u_phys with u32
diff mbox

Message ID 1481064781-16949-2-git-send-email-daniel.kiper@oracle.com
State New, archived
Headers show

Commit Message

Daniel Kiper Dec. 6, 2016, 10:52 p.m. UTC
u_phys is used just in two places and sometimes it may confuse reader.
Additionally, GRUB multiboot2 implementation does not use u_phys anywhere.
So, replace it with basic well defined and used in implementation u32 type.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 doc/multiboot.texi |   11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

Comments

Andrei Borzenkov Dec. 10, 2016, 5:23 p.m. UTC | #1
07.12.2016 01:52, Daniel Kiper пишет:
> u_phys is used just in two places and sometimes it may confuse reader.
> Additionally, GRUB multiboot2 implementation does not use u_phys anywhere.
> So, replace it with basic well defined and used in implementation u32 type.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  doc/multiboot.texi |   11 ++++-------
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index 4b92918..2bda9b7 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -299,9 +299,6 @@ little-endian, u32 is coded in little-endian.
>  The type of unsigned 64-bit data. Because the target architecture is
>  little-endian, u64 is coded in little-endian.
>  
> -@item u_phys
> -The type of unsigned data of the same size as target architecture physical address size.
> -
>  @item u_virt
>  The type of unsigned data of the same size as target architecture virtual address size.
>  

So if I understand it correctly, any address used in multiboot2 is
limited to 32 bit, so anything that is relevant to boot protocol must
reside below 4G. Is my assumption correct?
Daniel Kiper Dec. 12, 2016, 1:48 p.m. UTC | #2
On Sat, Dec 10, 2016 at 08:23:15PM +0300, Andrei Borzenkov wrote:
> 07.12.2016 01:52, Daniel Kiper пишет:
> > u_phys is used just in two places and sometimes it may confuse reader.
> > Additionally, GRUB multiboot2 implementation does not use u_phys anywhere.
> > So, replace it with basic well defined and used in implementation u32 type.
> >
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > ---
> >  doc/multiboot.texi |   11 ++++-------
> >  1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> > index 4b92918..2bda9b7 100644
> > --- a/doc/multiboot.texi
> > +++ b/doc/multiboot.texi
> > @@ -299,9 +299,6 @@ little-endian, u32 is coded in little-endian.
> >  The type of unsigned 64-bit data. Because the target architecture is
> >  little-endian, u64 is coded in little-endian.
> >
> > -@item u_phys
> > -The type of unsigned data of the same size as target architecture physical address size.
> > -
> >  @item u_virt
> >  The type of unsigned data of the same size as target architecture virtual address size.
> >
>
> So if I understand it correctly, any address used in multiboot2 is
> limited to 32 bit, so anything that is relevant to boot protocol must

More or less. There are some exceptions when EFI x64 platforms come on the stage.
It is described in spec.

> reside below 4G. Is my assumption correct?

Yep. More info you can find in patch #07.

Daniel

Patch
diff mbox

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 4b92918..2bda9b7 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -299,9 +299,6 @@  little-endian, u32 is coded in little-endian.
 The type of unsigned 64-bit data. Because the target architecture is
 little-endian, u64 is coded in little-endian.
 
-@item u_phys
-The type of unsigned data of the same size as target architecture physical address size.
-
 @item u_virt
 The type of unsigned data of the same size as target architecture virtual address size.
 
@@ -840,8 +837,8 @@  zero-terminated UTF-8 string.
         +-------------------+
 u32     | type = 3          |
 u32     | size              |
-u_phys  | mod_start         |
-u_phys  | mod_end           |
+u32     | mod_start         |
+u32     | mod_end           |
 u8[n]   | string            |   
         +-------------------+
 @end group
@@ -850,8 +847,8 @@  u8[n]   | string            |
 This tag indicates to the kernel what boot module was loaded along with the
 kernel image, and where it can be found.
 
-The @samp{mod_start} and @samp{mod_end} contain the start and end addresses of the boot
-module itself. The @samp{string} field provides an arbitrary string to
+The @samp{mod_start} and @samp{mod_end} contain the start and end physical addresses
+of the boot module itself. The @samp{string} field provides an arbitrary string to
 be associated with that particular boot module; it is a zero-terminated
 UTF-8 string, just like the kernel command line. Typically the
 string might be a command line (e.g. if the operating system treats boot