Re: [PATCH] printk: Export struct log size and member offsets through vmcoreinfo

[Vivek Goyal <vgoyal@redhat.com>]

On Thu, Jul 19, 2012 at 11:38:57AM +0200, Kay Sievers wrote:
> On Wed, Jul 18, 2012 at 7:56 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Wed, Jul 18, 2012 at 07:27:08PM +0200, Kay Sievers wrote:
> >> On Wed, Jul 18, 2012 at 7:18 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> >>
> >> > Currently I am not exporting log "level" info as that is a bitfield and
> >> > offsetof() bitfields can't be calculated.
> >>
> >> We could make the level the lower 3 bits of the byte, export the byte,
> >> and define that only 3 bits of the byte are valid? Would that help?
> >
> > Yes, that should work. Here is the prototype patch which stores 5 bits
> > of flag and 3 bits of level in a byte. I have not tested it yet, but
> > if you like the approach, I will test it.
> 
> > -       u8 flags:5;             /* internal record flags */
> > -       u8 level:3;             /* syslog level */
> > +       u8 flags_level;         /* 5 bit internal record flags, 3 bits syslog
> 
> Looks ok.
> 
> If we would swap the 5 + 3 bit field byte declaration, and add
> __packed, we can still not rely on the level to be consistently the
> lower 3 bits of the byte, right?

Current code assumes that level bits are least significant bits in
flags_level. I could export another field say "log_level_bit_offset=0" to
represent the offset of level bits and that way you will retain the
flexibilty of changing the position of level bits. I am not sure if it
is worth. Down the line if numeber of flags outgrow 5bits, one can 
just move flags to a separate field and possibly use those 5bits for
something else.

I guess I will change the patch to also level bit offset and remove
the assumption that level bits are always starting at offset 0. Will test
changes and repost the V2 of patches.

Thanks
Vivek