From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ae710-0000j4-4S for mharc-grub-devel@gnu.org; Thu, 10 Mar 2016 15:16:58 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33229) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ae70x-0000in-Lu for grub-devel@gnu.org; Thu, 10 Mar 2016 15:16:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ae70w-0005zX-Fi for grub-devel@gnu.org; Thu, 10 Mar 2016 15:16:55 -0500 Received: from mail-wm0-x233.google.com ([2a00:1450:400c:c09::233]:35040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ae70w-0005z5-5h for grub-devel@gnu.org; Thu, 10 Mar 2016 15:16:54 -0500 Received: by mail-wm0-x233.google.com with SMTP id l68so2509334wml.0 for ; Thu, 10 Mar 2016 12:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=e7pYGI57xVPkBkfdYGMoSWH/H3KYGSz6bFaaBeZIpBc=; b=UVLWgV8fKFTEA03Yw5a+EE/GrORr0qmdJ3jfleAMO3X47uavFna+2Zkx0C1hvh5XRe GB9T+o/OD5Oi0yZ4I9pDVb1itikIcz5EGULfp4zJz+3wjsB5iRF2gd8rLO33CaXAOPyu DahjY4z9T10Om401+gsax0t16pzMx9zDEOoV43GFEuHvj8fbstcdk5SnW6cyh1QhAHRZ TSOjvd+UcEiw42MhsY/9W3FPRLpee/nsyFDpla0QtL/+ugBD4Yg62Z9Xo/DiG+Aur2KJ gPkMSoDAE6UyZ5o9Ui00DiAPGO4NlD6jf3oSSTOh8QgUAC8T6iVzsXJ78mK7RQZgygHy Wd9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=e7pYGI57xVPkBkfdYGMoSWH/H3KYGSz6bFaaBeZIpBc=; b=lxz3h+wxEl16RIJ0tLwBGNGChT2SgFgs99Bw88Un73OGq3oHe7Pt+FR343dHrOe+/6 ZaIUMWK9oxkcKf0SEbiXf32P4K15IJ/cTBwaHjq07XQaW82vGNhhSnkMNWfzDLdAl0xk Uv9fxXT4jM9NUWSIs0wJkk3tx+g+bAGKk8ESqGOUSCs8G8FOTtydKq1ws6xgpfD6yLiR hvFW29rKhk3+jm3cfW9YLP1P9yviFwLp67BZVlDMkOb0ksJr+5AHhTBd7vHZKeyEdLLX NWdcdEsW7YN7H8ChZQ4IkSHoASmoL0w5xefw6oSkgR2I/VmfcbVdhtXp7VG+A2nkoQAM FTFg== X-Gm-Message-State: AD7BkJKim+Oo9VrMXUKOSxJ/inHPW0jzZ0NYnpu92MCg8TF8ayLrZPQd5jpgf7oXa9pppVlqj4eXQx6r/pvUnA== MIME-Version: 1.0 X-Received: by 10.28.113.155 with SMTP id d27mr187942wmi.67.1457641013415; Thu, 10 Mar 2016 12:16:53 -0800 (PST) Received: by 10.28.22.211 with HTTP; Thu, 10 Mar 2016 12:16:53 -0800 (PST) In-Reply-To: <20160308200703.GG3500@olila.local.net-space.pl> References: <20160307133452.GC3500@olila.local.net-space.pl> <20160308200703.GG3500@olila.local.net-space.pl> Date: Thu, 10 Mar 2016 21:16:53 +0100 Message-ID: Subject: Re: multiboot2 structs and packed attribute From: "Vladimir 'phcoder' Serbinenko" To: Daniel Kiper Content-Type: multipart/alternative; boundary=001a1147cd9cd0abce052db77e9a X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::233 Cc: "arvidjaar@gmail.com" , "grub-devel@gnu.org" X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 20:16:56 -0000 --001a1147cd9cd0abce052db77e9a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, March 8, 2016, Daniel Kiper wrote: > On Mon, Mar 07, 2016 at 08:42:38PM +0000, Vladimir 'phcoder' Serbinenko > wrote: > > Le lun. 7 mars 2016 14:35, Daniel Kiper > a =C3=A9crit : > > > > > Hi, > > > > > > Does anybody know why only multiboot2 multiboot_mmap_entry struct > > > has packed attribute? Is it by design or by mistake? I think that > > > we should use packed attribute for every multiboot2 protocol related > > > struct. If not then we should probably remove this attribute from > > > multiboot_mmap_entry struct too. What do you think about that? > > > > > We put packed only when it changes relative offsets of members or size = of > > the structure. Is it the case for structures you have in mind? > > I do not have anything specific. However, it looks like stray stuff. > > Hmmm... I took a look at multiboot_mmap_entry once again and it seems > that this struct really does not need packed attribute. All members are > in right order and even compiler should not add padding. Am I right? > Yes, good catch. > > Anyway, maybe we should add somewhere in the header comment saying that > all/most of multiboot2 structures are build in a way that fulfill alignme= nt > requirements out of the box and compiler does not need to do any > rearrangements. > However, we should warn that new extensions should be added carefully and > some structs may require GRUB_PACKED attribute in the future to properly > represent added interface. > This probably should go to spec rather than the header file. > > Or we can add GRUB_PACKED to every struct. However, this seems redundant > here. > There is no chance that somebody will rearrange, especially blindly, > existing structs. > > Daniel > --=20 Regards Vladimir 'phcoder' Serbinenko --001a1147cd9cd0abce052db77e9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, March 8, 2016, Daniel Kiper <daniel.kiper@oracle.com> wrote:
On Mon, Mar 07, 2016 at 08:42:38PM +0000, Vladimir 'p= hcoder' Serbinenko wrote:
> Le lun. 7 mars 2016 14:35, Daniel Kiper <dan= iel.kiper@oracle.com> a =C3=A9crit :
>
> > Hi,
> >
> > Does anybody know why only multiboot2 multiboot_mmap_entry struct=
> > has packed attribute? Is it by design or by mistake? I think that=
> > we should use packed attribute for every multiboot2 protocol rela= ted
> > struct. If not then we should probably remove this attribute from=
> > multiboot_mmap_entry struct too. What do you think about that? > >
> We put packed only when it changes relative offsets of members or size= of
> the structure. Is it the case for structures you have in mind?

I do not have anything specific. However, it looks like stray stuff.

Hmmm... I took a look at multiboot_mmap_entry once again and it seems
that this struct really does not need packed attribute. All members are
in right order and even compiler should not add padding. Am I right?
Yes, good catch.=C2=A0

Anyway, maybe we should add somewhere in the header comment saying that
all/most of multiboot2 structures are build in a way that fulfill alignment=
requirements out of the box and compiler does not need to do any rearrangem= ents.
However, we should warn that new extensions should be added carefully and some structs may require GRUB_PACKED attribute in the future to properly represent added interface.
This probably should go to = spec rather than the header file.

Or we can add GRUB_PACKED to every struct. However, this seems redundant he= re.
There is no chance that somebody will rearrange, especially blindly, existi= ng structs.

Daniel


--
Regards
Vladimir 'phcoder' Serbinenk= o

--001a1147cd9cd0abce052db77e9a--