All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Kay Sievers <kay@vrfy.org>
Cc: Greg Kroah-Hartmann <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kexec Mailing List <kexec@lists.infradead.org>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH] printk: Export struct log size and member offsets through vmcoreinfo
Date: Thu, 19 Jul 2012 10:08:26 -0400	[thread overview]
Message-ID: <20120719140826.GD2761@redhat.com> (raw)
In-Reply-To: <20120719135736.GC2761@redhat.com>

On Thu, Jul 19, 2012 at 09:57:36AM -0400, Vivek Goyal wrote:
> 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?
> 

I think I missed your point in last response. Are you saying that retain
bit fields  for flags and level, and add __packed() and that will make sure
level bits are always lowest 3bits? I am really not sure how that is going
to work. Also if you want to add more fields to struct log down the line,
it will be a problem to determine the offset of byte where level bits are
stored. 

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Kay Sievers <kay@vrfy.org>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Kexec Mailing List <kexec@lists.infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartmann <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] printk: Export struct log size and member offsets through vmcoreinfo
Date: Thu, 19 Jul 2012 10:08:26 -0400	[thread overview]
Message-ID: <20120719140826.GD2761@redhat.com> (raw)
In-Reply-To: <20120719135736.GC2761@redhat.com>

On Thu, Jul 19, 2012 at 09:57:36AM -0400, Vivek Goyal wrote:
> 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?
> 

I think I missed your point in last response. Are you saying that retain
bit fields  for flags and level, and add __packed() and that will make sure
level bits are always lowest 3bits? I am really not sure how that is going
to work. Also if you want to add more fields to struct log down the line,
it will be a problem to determine the offset of byte where level bits are
stored. 

Thanks
Vivek

  reply	other threads:[~2012-07-19 14:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-18 17:18 [PATCH] printk: Export struct log size and member offsets through vmcoreinfo Vivek Goyal
2012-07-18 17:18 ` Vivek Goyal
2012-07-18 17:27 ` Kay Sievers
2012-07-18 17:27   ` Kay Sievers
2012-07-18 17:56   ` Vivek Goyal
2012-07-18 17:56     ` Vivek Goyal
2012-07-19  9:38     ` Kay Sievers
2012-07-19  9:38       ` Kay Sievers
2012-07-19 13:57       ` Vivek Goyal
2012-07-19 13:57         ` Vivek Goyal
2012-07-19 14:08         ` Vivek Goyal [this message]
2012-07-19 14:08           ` Vivek Goyal
2012-07-20  9:23           ` Kay Sievers
2012-07-20  9:23             ` Kay Sievers
2012-07-20  9:50             ` Eric W. Biederman
2012-07-20  9:50               ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120719140826.GD2761@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kay@vrfy.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.