[U-Boot] BIOS EMULATOR driver

[Marek Vasut]

Dear Graeme Russ,

> Hi Viktor,
> 
> On Wed, Mar 28, 2012 at 9:46 AM, Viktor Křivák <viktor.krivak at gmail.com> 
wrote:
> > Dear Timur Tabi,
> > 
> > 2012/3/27 Marek Vasut <marex at denx.de>:
> >> Dear Timur Tabi,
> >> 
> >>> Marek Vasut wrote:
> >>> > Agreed, but I expected there was some dead code and that was the
> >>> > point I was trying to express ;-)
> >>> 
> >>> Well, until you do a thorough analysis, you really have no idea if
> >>> there is any dead code at all.
> >> 
> >> I don't ... but Viktor probably does and I believe that's what he wants
> >> to ask about.
> > 
> > Yes I do the analysis, actually only one method is used
> > (PCI_mapBIOSImage), but there are two other methods related to video
> > card. Booth in file drivers/bios_emulator/atibios.c (PCI_mapBIOSImage,
> > PCI_unmapBIOSImage). Nothing calls they but I think they can be
> > preserved too.
> > 
> > But there are a lots of other code which can be removed. For example
> > BE_mapRealPointer() from drivers/bios_emulator/biosemu.c or
> > BE_getVESABuf() from same file. So my question is: It is safe remove
> > dead code or somebody can use it for debugging purposes ? I've got
> > same problem with another driver so this is general question.
> 
> What exactly is the problem?
> 
> Wolfgang previously pointed out:
> 
> "Did you check if you really find any such code in your linked image?
> As I already explained, normally -ffunction-sections / -fdata-sections
> with --gc-sections should make sure any unused functions get dropped
> automatically."
> 
> If these linker options successfully remove all of the dead code, then
> there should be no urgency in removing it. However, if you are
> experiencing compile errors due to unused functions, then yes, removing
> the dead code should be investigated. But if you plan to remove any
> code, make sure that there are no other boards which may potentially use
> the code you plan to remove

Greame, it's the UDM plight ... killing all dead code really helps streamlining 
the API.

> 
> Regards,
> 
> Graeme

Best regards,
Marek Vasut