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

[Eric W. Biederman]

Kay Sievers <kay at vrfy.org> writes:

> On Thu, Jul 19, 2012 at 4:08 PM, Vivek Goyal <vgoyal at redhat.com> wrote:
>> 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:
>
>>> > 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?
>
> It was more a question, I don't know how reliable that would be.
>
>> 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.
>
> I guess, we could make sure that it's always the lowest 3 bits of a
> byte. But the question if that is safe to do at all still remains. :)

Using bit fields in interfaces is probably not a good idea in practice.

The order of the bits is constrained by whatever your C ABI is.  However
the C abi can choose different orders on different architectures.

So if my memory is correct you can not use bitfields portably to choose
the low 3 bits of a byte, without a lot of #ifdef LITTLE_ENDIAN_BIT_FIELD
and the like.

So as general advice bitfields are good for saving space for purely
internal structures (if your compiler generates good code for them)
but for interfacing with other code or hardware you don't want to use
them.  Too much complexity for too little gain.

If bitfields were easily portable the kernel would be full of them as
they would make talking with hardware control registers much easier.

Eric