I have not read the entire thread, but just in case it was not
mentioned before: even when the structure elements come together very
snugly on their own, without __packed(), it still is required if the
structure comes over a wire or from a file, etc. as __packed()
guarantees that there is no unali
> The point is, that without ((packed)) there is no guarantee that gcc
> won't choose a different alignment over what you and I think would make
> sense.
In practice it is very predictable and there should be no sane reason
to do it otherwise. Like with many of the other "it's not guaranteed
in th
* Julius Werner [160727 23:41]:
> > typedef struct dmar_atsr_entry {
> >u16 type;
> >u16 length;
> >u8 flags;
> >u8 reserved;
> >u16 segment;
> > } __attribute__ ((packed)) dmar_atsr_entry_t;
>
> Looking at the original example here, I w
> typedef struct dmar_atsr_entry {
>u16 type;
>u16 length;
>u8 flags;
>u8 reserved;
>u16 segment;
> } __attribute__ ((packed)) dmar_atsr_entry_t;
Looking at the original example here, I would still recommend not to
use the packed attribut
Ah well, Werner, I've had the error of my ways pointed out to me, turns out
this packed stuff is a standard practice in coreboot now. I must have
missed the memo. So, I'm not a fan but if that's how we do it, it's how we
do it.
thanks and apologies
ron
On Wed, Jul 27, 2016 at 10:07 AM ron minnic
On Tue, Jul 26, 2016 at 9:25 PM Zeh, Werner wrote:
>
>
>
> In the case of ACPI we need to provide a table which has constrains on the
> used data types and alignment
> as the contents of the table will be interpreted by the ACPI interpreter
> of the OS.
> So if we omit the usage of packed it may
On Tue, Jul 26, 2016 at 7:15 PM Stefan Reinauer <
stefan.reina...@coreboot.org> wrote:
>
>
> > Finally, why the use of packed? In general you really only want to use
> packed
> > when you're using it to directly address data. Why not deserialize the
> data
> > from memory into an unpacked struct?
* ron minnich [160727 02:26]:
> A couple of questions preceded by the usual curmudgeonly comment :-)
>
> I'm not a big fan of checkpatch.pl. It's 5965 lines of dense perl spaghetti
> code, continues to grow, and is attempting to achieve that which I understand
> may be impossible: parsing C with
A couple of questions preceded by the usual curmudgeonly comment :-)
I'm not a big fan of checkpatch.pl. It's 5965 lines of dense perl spaghetti
code, continues to grow, and is attempting to achieve that which I
understand may be impossible: parsing C with REs and random blobs of PERL.
Given that
Does git commit --no-verify (or -n for short) allow you to commit?
I think we should try to do a little of option 1 within reason, not by
forking the script but rather by disabling more check steps that don't
match the coreboot code style (by having our wrapper pass --ignore XXX
flags to checkpatc
I am not sure if this happened in coreboot upstream: on some other projects
checkpatch.pl was recently updated to the latest Linux kernel version, and
some more stupid warnings/errors started popping out.
There is a fine controlling checkpatch.pl behavior, .checkpatch.conf in the
coreboot root dir
Hi community.
I recently ran into a blocked commit due to warnings reported by checkpatch.pl.
In this particular case I wanted to add the "ATSR" structure to the DMAR
tables. To do that, I need to define a new structure
which reflects the per specification needed layout of this table entry.
I did
12 matches
Mail list logo
