Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1338193 > unrolled thread
| Started by | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| First post | 2016-02-19 14:50 +0100 |
| Last post | 2016-02-19 22:20 +0100 |
| Articles | 3 on this page of 23 — 6 participants |
Back to article view | Back to linux.kernel
[RFC v2 0/7] linux: add linker tables "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:50 +0100
[RFC v2 3/7] firmware: port built-in section to linker table "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:50 +0100
[RFC v2 6/7] dynamic_debug: port to use linker tables "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:50 +0100
[RFC v2 5/7] jump_label: port __jump_table to linker tables "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:50 +0100
[RFC v2 1/7] sections.h: add sections header to collect all section info "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:50 +0100
Re: [RFC v2 1/7] sections.h: add sections header to collect all section info Greg KH <gregkh@linuxfoundation.org> - 2016-02-19 17:30 +0100
Re: [RFC v2 1/7] sections.h: add sections header to collect all section info "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-02-19 21:10 +0100
Re: [RFC v2 1/7] sections.h: add sections header to collect all section info Greg KH <gregkh@linuxfoundation.org> - 2016-02-19 22:30 +0100
Re: [RFC v2 1/7] sections.h: add sections header to collect all section info "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 23:10 +0100
[RFC v2 4/7] asm/sections: add a generic push_section_tbl() "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:50 +0100
Re: [RFC v2 4/7] asm/sections: add a generic push_section_tbl() "H. Peter Anvin" <hpa@zytor.com> - 2016-02-19 21:40 +0100
Re: [RFC v2 4/7] asm/sections: add a generic push_section_tbl() "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 22:10 +0100
Re: [RFC v2 4/7] asm/sections: add a generic push_section_tbl() "H. Peter Anvin" <hpa@zytor.com> - 2016-02-22 04:00 +0100
[RFC v2 7/7] kprobes: port to linker table "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:50 +0100
Re: [RFC v2 7/7] kprobes: port to linker table Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-02-19 15:20 +0100
Re: [RFC v2 7/7] kprobes: port to linker table "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-02-19 16:00 +0100
RE: [RFC v2 7/7] kprobes: port to linker table 平松雅巳 / HIRAMATU，MASAMI <masami.hiramatsu.pt@hitachi.com> - 2016-02-22 02:40 +0100
Re: [RFC v2 0/7] linux: add linker tables "H. Peter Anvin" <hpa@zytor.com> - 2016-02-19 21:30 +0100
Re: [RFC v2 0/7] linux: add linker tables "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 22:30 +0100
Re: [RFC v2 2/7] tables.h: add linker table support "H. Peter Anvin" <hpa@zytor.com> - 2016-02-19 21:40 +0100
Re: [RFC v2 2/7] tables.h: add linker table support "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 22:50 +0100
Re: [RFC v2 2/7] tables.h: add linker table support "H. Peter Anvin" <hpa@zytor.com> - 2016-02-19 21:40 +0100
Re: [RFC v2 2/7] tables.h: add linker table support "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-02-19 22:20 +0100
Page 2 of 2 — ← Prev page 1 [2]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-02-19 22:50 +0100 |
| Subject | Re: [RFC v2 2/7] tables.h: add linker table support |
| Message-ID | <r4162-3e8-7@gated-at.bofh.it> |
| In reply to | #1338442 |
On Fri, Feb 19, 2016 at 12:25:55PM -0800, H. Peter Anvin wrote:
> On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote:
> > +
> > +/**
> > + * DOC: Regular linker linker table constructors
> > + *
> > + * Regular constructors are expected to be used for valid linker table entries.
> > + * Valid uses of weak entries other than the beginning and is currently
> > + * untested but should in theory work.
> > + */
> > +
> > +/**
> > + * LINKTABLE_TEXT - Declares a linker table entry for execution
> > + *
> > + * @name: linker table name
> > + * @level: order level
> > + *
> > + * Declares a linker table to be used for execution.
> > + */
> > +#define LINKTABLE_TEXT(name, level) \
> > + __typeof__(name[0]) \
> > + __attribute__((used, \
> > + __aligned__(LINKTABLE_ALIGNMENT(name)), \
> > + section(SECTION_TBL(SECTION_TEXT, name, level))))
>
> I'm really confused by this. Text should obviously be readonly,
So this uses SECTION_TEXT, so we just pegged the linker table entry right below
the standard SECTION_TEXT:
@@ -422,7 +426,8 @@
* during second ld run in second ld pass when generating System.map */
#define TEXT_TEXT \
ALIGN_FUNCTION(); \
- *(.text.hot .text .text.fixup .text.unlikely) \
+ *(.text.hot SECTION_TEXT .text.fixup .text.unlikely) \
+ *(SORT(SECTION_TBL_ALL(SECTION_TEXT))) \
*(.ref.text) \
MEM_KEEP(init.text) \
MEM_KEEP(exit.text)
So this gets folded under TEXT_TEXT and we don't see to force all
architectures for this to be read-only specifically. I can't be sure
if it is always read-only for all architectures based on a cursory
review.
> but I'm not at all clear how this works here.
Its simply trying to piggy back on top of where the standard section
it is using so in this case SECTION_TEXT (.text). What attributes are
part of that follow.
> The issue with linktables for text is kind of confusing if nothing else;
> Russel is right about that. It doesn't prevent us from doing something
> similar, but perhaps it ought to have a different name.
Any recommendations?
> For one thing, priority level is meaningless for text, since it is not a
> table that can be indexed into.
Ah right, there is no structure so we can't foo->in, let alone, know what
arguments to pass... the order level certainly would still kick in but
I agree that it would seem kind of pointless as something else would
have to know how to use it. I could simply remove the iterator and
order-level for SECTION_TEXT linker tables if we are sure we can't use it.
The only gain then here would be that of saving custom linker script
changes and having a unified way to represent the attributes.
If order is desired a structured data would would make more sense and
I could document / recommend that, however I don't yet have a ported
use case in mind yet, any ideas? The use case I have that follows
similar logic is for the x86 init stuff which I am sending separately
and that's a new use case though. It uses SECTION_INIT (.init.text)
and that allows for both use of structuralized data + callbacks we
can execute. It was not clear to me what section to use for this sort
of stuff for non init stuff, and I can envision people highly wanting
to use this to help clean up init paths on code, what sectoin
should be used in those cases?
Luis
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2016-02-19 21:40 +0100 |
| Subject | Re: [RFC v2 2/7] tables.h: add linker table support |
| Message-ID | <r400i-2qQ-15@gated-at.bofh.it> |
| In reply to | #1338193 |
On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote:
> +/**
> + * LINKTABLE_RUN_ERR - run each linker table entry func and return error if any
> + *
> + * @tbl: linker table
> + * @func: structure name for the function name we want to call.
> + * @args...: arguments to pass to func
> + *
> + * Example usage:
> + *
> + * unsigned int err = LINKTABLE_RUN_ERR(frobnicator_fns, some_run,);
> + */
> +#define LINKTABLE_RUN_ERR(tbl, func, args...) \
> +({ \
> + size_t i; \
> + int err = 0; \
> + for (i = 0; !err && i < LINKTABLE_SIZE(tbl); i++) \
> + err = (tbl[i]).func (args); \
> + err; \
> +})
This is wrong and pointless. As written it returns the error code of
the last instance.
What I suggested for this macro was that we ought to exit the loop on error.
Furthermore:
1. Using an advancing pointer would make more sense than a counter.
2. .func doesn't make any sense -- it ought to be "func"; otherwise you
can't call into either a table containing pure function pointers,
nor into a field of table *pointed to* by the table; which is
likely to be quite common.
So the idea is to use something like:
/* Array of function pointers */
LINKTABLE_RUN_ALL(frobnicator_fns, , arg1, arg2);
/* Array of structures */
LINKTABLE_RUN_ALL(frobnicator_fns, .some_run, arg1, arg2);
/* Array of structure pointers */
LINKTABLE_RUN_ALL(frobnicator_fns, ->some_run, arg1, arg2);
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@suse.com> |
|---|---|
| Date | 2016-02-19 22:20 +0100 |
| Subject | Re: [RFC v2 2/7] tables.h: add linker table support |
| Message-ID | <r40D0-2XK-23@gated-at.bofh.it> |
| In reply to | #1338447 |
On Fri, Feb 19, 2016 at 12:33:27PM -0800, H. Peter Anvin wrote:
> On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote:
> > +/**
> > + * LINKTABLE_RUN_ERR - run each linker table entry func and return error if any
> > + *
> > + * @tbl: linker table
> > + * @func: structure name for the function name we want to call.
> > + * @args...: arguments to pass to func
> > + *
> > + * Example usage:
> > + *
> > + * unsigned int err = LINKTABLE_RUN_ERR(frobnicator_fns, some_run,);
> > + */
> > +#define LINKTABLE_RUN_ERR(tbl, func, args...) \
> > +({ \
> > + size_t i; \
> > + int err = 0; \
> > + for (i = 0; !err && i < LINKTABLE_SIZE(tbl); i++) \
> > + err = (tbl[i]).func (args); \
> > + err; \
> > +})
>
> This is wrong and pointless. As written it returns the error code of
> the last instance.
>
> What I suggested for this macro was that we ought to exit the loop on error.
>
> Furthermore:
>
> 1. Using an advancing pointer would make more sense than a counter.
OK I'll modify to use LINKTABLE_FOR_EACH and much cleaner and obvious
code to bail on error.
> 2. .func doesn't make any sense -- it ought to be "func"; otherwise you
> can't call into either a table containing pure function pointers,
> nor into a field of table *pointed to* by the table; which is
> likely to be quite common.
>
> So the idea is to use something like:
>
> /* Array of function pointers */
> LINKTABLE_RUN_ALL(frobnicator_fns, , arg1, arg2);
>
> /* Array of structures */
> LINKTABLE_RUN_ALL(frobnicator_fns, .some_run, arg1, arg2);
>
> /* Array of structure pointers */
> LINKTABLE_RUN_ALL(frobnicator_fns, ->some_run, arg1, arg2);
Ah that's sexy, thanks. Will amend.
Luis
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web