Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756240AbcLAFEy (ORCPT ); Thu, 1 Dec 2016 00:04:54 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:32957 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750789AbcLAFEw (ORCPT ); Thu, 1 Dec 2016 00:04:52 -0500 Date: Thu, 1 Dec 2016 16:04:30 +1100 From: Nicholas Piggin To: "Luis R. Rodriguez" Cc: "H. Peter Anvin" , Michael Matz , Arnd Bergmann , Josh Poimboeuf , Kees Cook , Guenter Roeck , Masami Hiramatsu , "linux-kernel@vger.kernel.org" , Fengguang Wu , Adrian Hunter , David Ahern , Jiri Olsa , Namhyung Kim , Wang Nan , Arnaldo Carvalho de Melo , Borislav Petkov , Joerg Roedel Subject: Re: linker-tables v5 testing Message-ID: <20161201160430.6e95710a@roar.ozlabs.ibm.com> In-Reply-To: References: <20161130013349.GN1402@wotan.suse.de> <20161130140947.3ea27d9e@roar.ozlabs.ibm.com> <20161130173816.GP1402@wotan.suse.de> <20161201135146.295868f0@roar.ozlabs.ibm.com> Organization: IBM X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3685 Lines: 90 On Wed, 30 Nov 2016 19:15:27 -0800 "Luis R. Rodriguez" wrote: > On Wed, Nov 30, 2016 at 6:51 PM, Nicholas Piggin wrote: > > On Wed, 30 Nov 2016 18:38:16 +0100 > > "Luis R. Rodriguez" wrote: > > > >> On Wed, Nov 30, 2016 at 02:09:47PM +1100, Nicholas Piggin wrote: > >> What is wrong with that ? Separating linker table and section ranges is > > > > It's not that you separate those, of course you need that. It's that > > you also separate other sections from the input section descriptions: > > > > - *(.text.hot .text .text.fixup .text.unlikely) \ > > + *(.text.hot .text) \ > > + *(SORT(.text.rng.*)) \ > > + *(.text.fixup .text.unlikely) \ > > > > [snip] > > And ? Umm.. don't remember :) > >> > If we have an array of pointers and size, it's trivial C code to iterate over > >> > it. If it needs to have a set of LINKTABLE accessors over the top of it > >> > for this use case, then that would seem to be a failure of the underlying > >> > API, no? > >> > >> Still did not get it. > > > > Well fundamentally the linker table is just a way to declare some type of > > array that any code can add some elements to, right? > > Well in particular to a special section, and we're providing standard > easy way to do this without any hacky linker script or assembly. Right. > > The non-C aspect of it > > is this ability of producers to be decentralized. > > Not sure what you mean here, we only do a little bit of linker table > magic, tweaks and then provide helpers. I mean that you don't need some LINKTABLE_FOREACH accessor for it, because from the consumer point of view, it's a simple array. It can easily be handled by plain C. All we need is to get the array base and size. > > The consumer is not really different from any other array though. They just > > want to know the address and the number of elements, and that's all. You can > > provide that with two macros and don't really need macros like for each, run > > all, etc because it's just simple C iteration over an array. > > I added those at the request of hpa, and one of the reasons was that > we tend to historically use these "arrays" in special ways all over > the kernel. But these arrays are very special, they are not typical > arrays. This makes emphasis on its use. They are also needed given the > special formatting we have for start / end of these in a generic form. > This should all help consolidate this and make it easier to use in a > generic form. It should also help avoid mismatch use when the intent > was a section range and we're on a linker table, or the other way > around. I disagree. Making a simple iterator for array, or hiding a simple function call behind it, really doesn't buy you anything. It's not like linked list for example, where the result of the iterators is much nicer than the open coded C. > >> > - Is it really important to be able to add new allocators without modifying > >> > a central file for the linker script? Yes it's a benefit, but is it enough > >> > to justify the complexity? > >> > >> If by allocators you mean the ability to add new entries into sections easily > >> without having to modify the linker script -- then my answer is: > > > > Yes, but after reading a little closer it may not really be a problem I > > first thought. Thanks for providing the detailed points. > > OK. So just a bit of bike shedding ? No I just misread how a part of it was implemented. Thanks, Nick