From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from out01.mta.xmission.com ([166.70.13.231]) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1Ss9rl-0001Tz-71 for kexec@lists.infradead.org; Fri, 20 Jul 2012 09:51:23 +0000 From: ebiederm@xmission.com (Eric W. Biederman) References: <20120718171812.GC21746@redhat.com> <20120718175625.GD21746@redhat.com> <20120719135736.GC2761@redhat.com> <20120719140826.GD2761@redhat.com> Date: Fri, 20 Jul 2012 02:50:15 -0700 In-Reply-To: (Kay Sievers's message of "Fri, 20 Jul 2012 11:23:10 +0200") Message-ID: <87bojasqw8.fsf@xmission.com> MIME-Version: 1.0 Subject: Re: [PATCH] printk: Export struct log size and member offsets through vmcoreinfo List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kexec-bounces@lists.infradead.org Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Kay Sievers Cc: Greg Kroah-Hartmann , Andrew Morton , Kexec Mailing List , linux kernel mailing list , Vivek Goyal Kay Sievers writes: > On Thu, Jul 19, 2012 at 4:08 PM, Vivek Goyal 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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753310Ab2GTJu2 (ORCPT ); Fri, 20 Jul 2012 05:50:28 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:48098 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752905Ab2GTJuZ (ORCPT ); Fri, 20 Jul 2012 05:50:25 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Kay Sievers Cc: Vivek Goyal , linux kernel mailing list , Kexec Mailing List , Andrew Morton , Greg Kroah-Hartmann References: <20120718171812.GC21746@redhat.com> <20120718175625.GD21746@redhat.com> <20120719135736.GC2761@redhat.com> <20120719140826.GD2761@redhat.com> Date: Fri, 20 Jul 2012 02:50:15 -0700 In-Reply-To: (Kay Sievers's message of "Fri, 20 Jul 2012 11:23:10 +0200") Message-ID: <87bojasqw8.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=;;;mid=;;;hst=in01.mta.xmission.com;;;ip=98.207.153.68;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+bmKm7brOacWEyOKV+OvaF9ZiUK9H1Qic= X-SA-Exim-Connect-IP: 98.207.153.68 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.1 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -3.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa02 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 XM_Sft_Co_L33T XM_Sft_Co_L33T * 0.0 T_XMDrugObfuBody_08 obfuscated drug references X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Kay Sievers X-Spam-Relay-Country: Subject: Re: [PATCH] printk: Export struct log size and member offsets through vmcoreinfo X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kay Sievers writes: > On Thu, Jul 19, 2012 at 4:08 PM, Vivek Goyal 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