On Wed, 30 Nov 2016 19:15:27 -0800 "Luis R. Rodriguez" <mcg...@kernel.org> wrote:
> On Wed, Nov 30, 2016 at 6:51 PM, Nicholas Piggin <npig...@gmail.com> wrote: > > On Wed, 30 Nov 2016 18:38:16 +0100 > > "Luis R. Rodriguez" <mcg...@kernel.org> 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
