On Wed, 2014-06-25 at 10:34 +0200, Mathias Krause wrote:
> On 25 June 2014 09:48, Joe Perches wrote:
> > On Wed, 2014-06-25 at 09:35 +0200, Rasmus Villemoes wrote:
> >> Speaking of dangling pointers: A similar disaster would happen if some
> >> code containing pi_* calls gets copy-pasted to some n
On 25 June 2014 09:48, Joe Perches wrote:
> On Wed, 2014-06-25 at 09:35 +0200, Rasmus Villemoes wrote:
>> Speaking of dangling pointers: A similar disaster would happen if some
>> code containing pi_* calls gets copy-pasted to some non-__init
>> function.
>
> This is my biggest issue with adding t
On 25 June 2014 09:35, Rasmus Villemoes wrote:
> Mathias Krause writes:
>
>> On 24 June 2014 16:31, Rasmus Villemoes wrote:
>>> gcc already seems to contain infrastructure for this kind of thing, so
>>> maybe it doesn't even require a plugin, but simply a little coordination
>>> with the gcc fol
On Wed, 2014-06-25 at 09:35 +0200, Rasmus Villemoes wrote:
> yes, the source would need
> to be annotated some way or other, or gcc would need to learn the
> semantics of certain kernel functions.
>
> Speaking of dangling pointers: A similar disaster would happen if some
> code containing pi_* ca
Mathias Krause writes:
> On 24 June 2014 16:31, Rasmus Villemoes wrote:
>> gcc already seems to contain infrastructure for this kind of thing, so
>> maybe it doesn't even require a plugin, but simply a little coordination
>> with the gcc folks. This snippet from gcc internals seems relevant:
>>
On 24 June 2014 23:45, Joe Perches wrote:
> On Tue, 2014-06-24 at 23:06 +0200, Mathias Krause wrote:
>> On 24 June 2014 22:57, Joe Perches wrote:
>> > On Tue, 2014-06-24 at 22:41 +0200, Mathias Krause wrote:
>> >> And all of those strings should be in the .rodata section, now. But
>> >> why you'r
On Tue, 2014-06-24 at 23:06 +0200, Mathias Krause wrote:
> On 24 June 2014 22:57, Joe Perches wrote:
> > On Tue, 2014-06-24 at 22:41 +0200, Mathias Krause wrote:
> >> And all of those strings should be in the .rodata section, now. But
> >> why you're asking?
> > Because now they will be duplicated
On 24 June 2014 22:57, Joe Perches wrote:
> On Tue, 2014-06-24 at 22:41 +0200, Mathias Krause wrote:
>> there is more to optimize
>> if one is patient enough ;)
>
> Ever thus.
>
>> And all of those strings should be in the .rodata section, now. But
>> why you're asking?
>
> Because now they will b
On Tue, 2014-06-24 at 22:41 +0200, Mathias Krause wrote:
> there is more to optimize
> if one is patient enough ;)
Ever thus.
> And all of those strings should be in the .rodata section, now. But
> why you're asking?
Because now they will be duplicated in .rodata
and the __init section no?
> Ye
On Tue, 2014-06-24 at 22:10 +0200, Mathias Krause wrote:
> I would like to handle the easy ones, too. E.g. strings used in
> parameter parsing, i.e. strcmp()s.
Sure, but that change is separable from printk conversions.
Any idea how much would be changed treewide and whether
or not those strings
On 24 June 2014 22:30, Joe Perches wrote:
> On Tue, 2014-06-24 at 22:10 +0200, Mathias Krause wrote:
>> I would like to handle the easy ones, too. E.g. strings used in
>> parameter parsing, i.e. strcmp()s.
>
> Sure, but that change is separable from printk conversions.
Yes. Those need to be marke
On 24 June 2014 21:37, Joe Perches wrote:
> On Tue, 2014-06-24 at 21:13 +0200, Mathias Krause wrote:
>> I don't think it's that easy. You cannot simply put all strings into
>> the .init.rodata section when code currently gets emitted to
>> .init.text. The reason is because strings used in __init c
On Tue, 2014-06-24 at 21:13 +0200, Mathias Krause wrote:
> On 24 June 2014 16:31, Rasmus Villemoes wrote:
[]
> > gcc already seems to contain infrastructure for this kind of thing, so
> > maybe it doesn't even require a plugin, but simply a little coordination
> > with the gcc folks. This snippet
On 24 June 2014 16:31, Rasmus Villemoes wrote:
> Joe Perches writes:
>
>> On Mon, 2014-06-23 at 08:23 +0200, Mathias Krause wrote:
>>> On 23 June 2014 00:56, Joe Perches wrote:
>>> > On Mon, 2014-06-23 at 00:46 +0200, Mathias Krause wrote:
>>> >> [...] patch 2 adds some syntactical sugar for the
Joe Perches writes:
> On Mon, 2014-06-23 at 08:23 +0200, Mathias Krause wrote:
>> On 23 June 2014 00:56, Joe Perches wrote:
>> > On Mon, 2014-06-23 at 00:46 +0200, Mathias Krause wrote:
>> >> [...] patch 2 adds some syntactical sugar for the most popular use
>> >> case, by providing pr_ alike ma
On Mon, 2014-06-23 at 08:23 +0200, Mathias Krause wrote:
> On 23 June 2014 00:56, Joe Perches wrote:
> > On Mon, 2014-06-23 at 00:46 +0200, Mathias Krause wrote:
> >> [...] patch 2 adds some syntactical sugar for the most popular use
> >> case, by providing pr_ alike macros, namely pi_ for __init
On 23 June 2014 03:30, Joe Perches wrote:
> On Mon, 2014-06-23 at 00:46 +0200, Mathias Krause wrote:
>> This RFC series tries to address the problem of dangling strings of
>> __init functions after initialization, as well as __exit strings for
>> code not even included in the final kernel image. T
On 23 June 2014 00:56, Joe Perches wrote:
> On Mon, 2014-06-23 at 00:46 +0200, Mathias Krause wrote:
>> [...] patch 2 adds some syntactical sugar for the most popular use
>> case, by providing pr_ alike macros, namely pi_ for __init
>> code and pe_ for __exit code. This hides the use of the marker
On Mon, 2014-06-23 at 00:46 +0200, Mathias Krause wrote:
> This RFC series tries to address the problem of dangling strings of
> __init functions after initialization, as well as __exit strings for
> code not even included in the final kernel image. The code might get
> freed, but the format string
On Mon, 2014-06-23 at 00:46 +0200, Mathias Krause wrote:
> This RFC series tries to address the problem of dangling strings of
> __init functions after initialization, as well as __exit strings for
> code not even included in the final kernel image. The code might get
> freed, but the format string
This RFC series tries to address the problem of dangling strings of
__init functions after initialization, as well as __exit strings for
code not even included in the final kernel image. The code might get
freed, but the format strings are not.
One solution to the problem might be to declare varia
21 matches
Mail list logo
