public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Hildner <christian.hildner@hob.de>
To: linux-ia64@vger.kernel.org
Subject: Re: [patch 1/2] remove per-cpu ia64_phys_stacked_size_p8
Date: Mon, 27 Feb 2006 08:15:13 +0000	[thread overview]
Message-ID: <4402B511.3000801@hob.de> (raw)
In-Reply-To: <200602240233.k1O2Xeg05945@unix-os.sc.intel.com>

Chen, Kenneth W schrieb:

>Christian Hildner wrote on Friday, February 24, 2006 2:08 AM
>  
>
>>self-modifing code isn't the straight forward way of programming. So 
>>wouldn't it be an idea to let the code crash instead of silently work 
>>with a potentially wrong number of registers here, if by any reason the 
>>patch mechanism doesn't work.
>>    
>>
>
>This argument is very biased.  A bug is a bug, regardless where the
>origin or through which mechanism.  Programming error like wrongly
>initialize a value has the same severity compare to patching wrong code.
>
True. However this isn't an argument against it. You might not even 
recognize that there is a bug. It might silently fail and maybe nobody 
would find it for years. With the break it would fail so you would be 
able to fix it immediately. And there is about no additional cost for 
using the break instruction.

>This argument is equally flawed.  If you don't have any trust in patching
>mechanism in previous argument, why would you trust that patch out a break
>instruction is going to be any better?
>
It is better because it would detect failure in the patch mechanism. Not 
more, not less.

Christian


  parent reply	other threads:[~2006-02-27  8:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-24  2:33 [patch 1/2] remove per-cpu ia64_phys_stacked_size_p8 Chen, Kenneth W
2006-02-24 10:08 ` Christian Hildner
2006-02-24 18:58 ` Chen, Kenneth W
2006-02-24 19:13 ` Chen, Kenneth W
2006-02-27  8:15 ` Christian Hildner [this message]
2006-02-27 19:26 ` Chen, Kenneth W
2006-10-13 17:05 ` Chen, Kenneth W

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=4402B511.3000801@hob.de \
    --to=christian.hildner@hob.de \
    --cc=linux-ia64@vger.kernel.org \
    /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