Re: [2.6 patch] scsi/qlogicpti.c section fixes

[Sam Ravnborg]

On Wed, Jan 30, 2008 at 03:00:16PM -0600, James Bottomley wrote:
> 
> On Wed, 2008-01-30 at 22:03 +0200, Adrian Bunk wrote:
> > This patch fixes the following section mismatches:
> > 
> > <--  snip  -->
> > 
> > ...
> > WARNING: drivers/scsi/qlogicpti.o(.devexit.text+0x8): Section mismatch in reference from the function qpti_sbus_remove() to the function .init.text:qpti_chain_del()
> > WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x56c): Section mismatch in reference from the function qpti_sbus_probe() to the function .init.text:qpti_map_regs()
> > WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x580): Section mismatch in reference from the function qpti_sbus_probe() to the function .init.text:qpti_register_irq()
> > WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x594): Section mismatch in reference from the function qpti_sbus_probe() to the function .init.text:qpti_get_scsi_id()
> > WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x5b8): Section mismatch in reference from the function qpti_sbus_probe() to the function .init.text:qpti_map_queues()
> > WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x780): Section mismatch in reference from the function qpti_sbus_probe() to the function .init.text:qpti_chain_add()
> > ...
> 
> OK, look, this is really getting out of hand.
We now at last have some infrastructure that does proper consistency
check of the use of annotation.
So it is by no means getting out-of-hands..

To my understanding Adrian just fixed a potential oops.
You have a driver that surely are thought to be hotplugable -
otherwise qpti_sbus_probe() would not have been annotated __devinit.
And had it ever been hotplugged then you had called a function in
a __init section that was long gone.

> __init is possibly justifiable with a few hundred k savings on boot.
> __devinit and the rest are surely killable on the grounds they provide
> little benefit for all the pain they cause.
For the embedded people a few kb here and there is worth it.

> all __exit seems to do is set us up for unreferenced pointers in
> discarded sections, so could we kill that too?
Again - savings when we build-in the drivers.
And without the checks we see 'funny' linker errors on the architectues
that can continue to add the .exit.text in /DISCARD/

	Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/