Section Mismatches
Felipe Balbi
I see that your commit 0db252452378aa7a9e001a13226e1cd1dc61453d removed
the *_driver from the symbol whitelist when referencing init section
(heh, it took a while), but could you explain what's the rationale
behind that ?
Thanks a lot
--
balbi
DefectiveByDesign.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Uwe Kleine-König
On Wed, Aug 04, 2010 at 02:11:56PM +0300, Felipe Balbi wrote:
> I see that your commit 0db252452378aa7a9e001a13226e1cd1dc61453d removed
> the *_driver from the symbol whitelist when referencing init section
> (heh, it took a while), but could you explain what's the rationale
> behind that ?
The rational is that it's AFAIK wrong if a driver references a function
that lives in .init.text.
Do you think that's wrong?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Felipe Balbi
>Hi Felipe,
>
>On Wed, Aug 04, 2010 at 02:11:56PM +0300, Felipe Balbi wrote:
>> I see that your commit 0db252452378aa7a9e001a13226e1cd1dc61453d removed
>> the *_driver from the symbol whitelist when referencing init section
>> (heh, it took a while), but could you explain what's the rationale
>> behind that ?
>The rational is that it's AFAIK wrong if a driver references a function
>that lives in .init.text.
how about all the driver structures ? should they remove __init from
probe() or stop saving the probe() function's pointer ?
That can be done for e.g. platform drivers, but for cpufreq_driver
structures, I can't see a way to avoid a section mismatch (not without
changing the cpufreq code a bit, at least). And, to me, that init has to
live in the .init.text section as it's pretty much only called to
initialize the frequency table for the cpu.
>Do you think that's wrong?
no, no. Not saying that. Just wondering what will happen with several
drivers, will they change from _driver to _ops or try to stop saving
probe() pointers into the driver structure.
--
balbi
DefectiveByDesign.org
Uwe Kleine-König
On Mon, Aug 09, 2010 at 09:08:31AM +0300, Felipe Balbi wrote:
> On Wed, Aug 04, 2010 at 02:26:59PM +0200, ext Uwe Kleine-König wrote:
>> Hi Felipe,
>>
>> On Wed, Aug 04, 2010 at 02:11:56PM +0300, Felipe Balbi wrote:
>>> I see that your commit 0db252452378aa7a9e001a13226e1cd1dc61453d removed
>>> the *_driver from the symbol whitelist when referencing init section
>>> (heh, it took a while), but could you explain what's the rationale
>>> behind that ?
>> The rational is that it's AFAIK wrong if a driver references a function
>> that lives in .init.text.
>
> how about all the driver structures ? should they remove __init from
> probe() or stop saving the probe() function's pointer ?
>
> That can be done for e.g. platform drivers, but for cpufreq_driver
> structures, I can't see a way to avoid a section mismatch (not without
> changing the cpufreq code a bit, at least). And, to me, that init has to
> live in the .init.text section as it's pretty much only called to
> initialize the frequency table for the cpu.
I think they need handling similar handling like the usb gadget drivers.
See
http://thread.gmane.org/gmane.linux.ports.ppc.embedded/37291/focus=34468
for the changes I suggested there.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Felipe Balbi
On Mon, Aug 09, 2010 at 08:49:36AM +0200, ext Uwe Kleine-König wrote:
> http://thread.gmane.org/gmane.linux.ports.ppc.embedded/37291/focus=34468
>
>for the changes I suggested there.
I see, will look into it. Thanks
--
balbi
DefectiveByDesign.org