public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] BIOS EMULATOR driver
Date: Wed, 28 Mar 2012 01:46:08 +0200	[thread overview]
Message-ID: <201203280146.09023.marex@denx.de> (raw)
In-Reply-To: <CALButCJKiPC0dsC+90XzR5F4OCDyhNCwp19cGKc_JVm+r6ckng@mail.gmail.com>

Dear Graeme Russ,

> Hi Viktor,
> 
> On Wed, Mar 28, 2012 at 9:46 AM, Viktor K?iv?k <viktor.krivak@gmail.com> 
wrote:
> > Dear Timur Tabi,
> > 
> > 2012/3/27 Marek Vasut <marex@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

  reply	other threads:[~2012-03-27 23:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-25 17:23 [U-Boot] BIOS EMULATOR driver Viktor Křivák
2012-03-25 18:30 ` Wolfgang Denk
2012-03-25 23:09   ` Viktor Křivák
2012-03-26  5:51     ` Wolfgang Denk
2012-03-26 10:43       ` Marek Vasut
2012-03-26 13:08         ` Wolfgang Denk
2012-03-26 13:31           ` Marek Vasut
2012-03-26 20:14             ` Wolfgang Denk
2012-03-26 23:06               ` Marek Vasut
2012-03-27  5:18                 ` Viktor Křivák
2012-03-27 17:28                   ` Wolfgang Denk
2012-03-27 17:48                     ` Marek Vasut
2012-03-27 17:51                       ` Timur Tabi
2012-03-27 17:58                         ` Marek Vasut
2012-03-27 17:59                           ` Timur Tabi
2012-03-27 20:11                             ` Marek Vasut
2012-03-27 22:46                               ` Viktor Křivák
2012-03-27 22:56                                 ` Graeme Russ
2012-03-27 23:46                                   ` Marek Vasut [this message]
2012-03-27 23:51                                     ` Graeme Russ
2012-03-27 23:56                                       ` Marek Vasut
2012-03-28  0:00                                         ` Graeme Russ
2012-03-28  0:17                                           ` Marek Vasut
2012-03-26 13:47           ` Viktor Křivák
2012-03-26 14:10             ` Anatolij Gustschin
2012-03-26 14:42             ` Timur Tabi
2012-03-26 20:17               ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201203280146.09023.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox