| Message ID | 1481064781-16949-2-git-send-email-daniel.kiper@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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?
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
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
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(-)