public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kyle Moffett <mrmacman_g4@mac.com>
To: Takashi Ikebe <ikebe.takashi@lab.ntt.co.jp>
Cc: Valdis.Kletnieks@vt.edu, linux-kernel@vger.kernel.org,
	Andi Kleen <ak@muc.de>
Subject: Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Date: Mon, 25 Apr 2005 22:15:13 -0400	[thread overview]
Message-ID: <d3d20c47f8bb1b095b6240baf5fa5465@mac.com> (raw)
In-Reply-To: <426D9AC0.5020908@lab.ntt.co.jp>

On Apr 25, 2005, at 21:34, Takashi Ikebe wrote:
> Valdis.Kletnieks@vt.edu wrote:
>> When asked "Why don't you just reboot the affected switches?" his
>> response was "This assumes that the switch had ever been booted in
>> the first place". (Apparently, the *whole thing* had been
>> on-the-fly replaced/patched without an actual reload happening...)
>> Gaaahhh! :)
>
> I think that's the common sense in every carrier.

That is definitely not common sense.  It may be good business
practice, but those are two *entirely* different things.

> If we reboot the switch, the service will be disrupted.

Yes.  My personal favorite solution to this problem is HeartBeat,
some Open-Source software that is very good at maintaining high
availability.  With a properly written multi-system clustering
switch application that utilizes the Linux Virtual-Server tools,
you could reasonably efficiently run a system such that you can
reboot any individual system without any loss of service.

> The phone network is lifeline, and does not allow to be disrupt
> by just bug fix.  I think same kind of function is needed in many
> real enterprise/mission-critical/business area.

But you miss the point.  Linux is *NOT* about "business", or
"enterprise", or "mission-critical".  Linux is (at least to
many hackers) about hacking, having fun, and Good Design(TM).

> All do with ptrace may affect target process's time critical
> task. (need to stop target process whenever fix)

So don't do it with ptrace!!! I've given you one other method
that uses minimal changes to existing software and emulates the
crappy mmap3 call you keep trying to push.

> All implement in user application costs too much,

What about one of the dozen other offered methods?

> need to implement all the application...

So why not write a utility library?  You'd need to "implement
all in the kernel", too, and since it can be done better in
userspace, let's keep out the bloat while we're at it.

> (and I do not know this approach really works on time critical
> applications yet.)

So test it! You're clearly working for a big corporation with
the money and resources to develop something like this, so do
so, and if you get something that works well, *and* uses good
design, we'll welcome patches!

> There are clear demand to realize this common and GPL-ed
> function....

The kernel is not about business, demand, or what the CEO of
some big-name company wants.  The kernel strives for the goal
of "Good Engineering (TM)".


Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------



  reply	other threads:[~2005-04-26  2:15 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-18  3:19 [PATCH x86_64] Live Patching Function on 2.6.11.7 Takashi Ikebe
2005-04-18  4:07 ` Chris Wedgwood
2005-04-18  4:19   ` Takashi Ikebe
2005-04-18  4:42     ` Daniel Jacobowitz
2005-04-18  4:55       ` Nicholas Miell
2005-04-18  5:01         ` Davide Libenzi
2005-04-18  5:41           ` Takashi Ikebe
2005-07-11  7:18           ` [PATCH] eventpoll : Suppress a short lived lock from struct file Eric Dumazet
2005-07-11  8:34             ` Peter Zijlstra
2005-07-11  9:29               ` Eric Dumazet
2005-07-11 14:00                 ` Davide Libenzi
2005-07-11 15:20                   ` Eric Dumazet
2005-04-18  5:00       ` [PATCH x86_64] Live Patching Function on 2.6.11.7 David S. Miller
2005-04-18  6:12     ` Chris Wedgwood
2005-04-18  6:35       ` Chris Friesen
2005-04-18  6:48         ` Chris Wedgwood
2005-04-18 10:03         ` James Courtier-Dutton
2005-04-18  9:10           ` Chris Wedgwood
2005-04-18  7:32       ` Takashi Ikebe
2005-04-18  7:56         ` Chris Wedgwood
2005-04-18  8:37           ` Takashi Ikebe
2005-04-18  8:59             ` Chris Wedgwood
2005-04-18  9:16           ` Paul Jackson
2005-04-18  9:25             ` Chris Wedgwood
2005-04-18 11:30               ` Rik van Riel
2005-04-18 12:52                 ` Takashi Ikebe
2005-04-18 14:06                   ` Rik van Riel
2005-04-19  2:14                     ` Takashi Ikebe
2005-04-19  4:27                       ` Chris Wedgwood
2005-04-19  5:19                         ` Takashi Ikebe
2005-04-19  5:52                           ` Chris Wedgwood
2005-04-20  4:18                             ` Takashi Ikebe
2005-04-20  5:43                               ` Chris Wedgwood
2005-04-20  7:35                                 ` Takashi Ikebe
2005-04-20  7:50                                   ` Chris Wedgwood
2005-04-20  7:57                                     ` Takashi Ikebe
2005-04-20  8:26                                       ` Chris Wedgwood
2005-04-20  8:45                                         ` Takashi Ikebe
2005-04-20  8:51                                           ` Chris Wedgwood
2005-04-20 11:19                                           ` Rik van Riel
2005-04-20 15:06                                             ` Chris Friesen
2005-04-20  8:34                                       ` Miquel van Smoorenburg
2005-04-19  5:57                           ` Takashi Ikebe
2005-04-18 14:28               ` Paul Jackson
2005-04-20 13:10               ` Ralf Baechle
2005-04-20 15:08                 ` Chris Friesen
2005-04-23 16:17 ` Andi Kleen
2005-04-25  2:11   ` Takashi Ikebe
2005-04-25  2:48     ` Kyle Moffett
2005-04-25 10:39       ` Takashi Ikebe
2005-04-25 11:15         ` Kyle Moffett
2005-04-25 15:09         ` Pavel Machek
2005-04-25 15:54         ` Andi Kleen
2005-04-25 16:36         ` Valdis.Kletnieks
2005-04-26  1:34           ` Takashi Ikebe
2005-04-26  2:15             ` Kyle Moffett [this message]
2005-04-26  9:36             ` Pavel Machek
2005-04-26 13:05             ` Andi Kleen
     [not found] <3Uv7B-5lv-7@gated-at.bofh.it>
     [not found] ` <3UvKd-5RT-1@gated-at.bofh.it>
     [not found]   ` <3Uw3y-65a-1@gated-at.bofh.it>
     [not found]     ` <3UwmX-6gm-5@gated-at.bofh.it>
     [not found]       ` <3UwwG-6lY-7@gated-at.bofh.it>
     [not found]         ` <3UwGk-6Cv-9@gated-at.bofh.it>
     [not found]           ` <3Uxj2-6YL-1@gated-at.bofh.it>
2005-04-18 10:59             ` Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>

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=d3d20c47f8bb1b095b6240baf5fa5465@mac.com \
    --to=mrmacman_g4@mac.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=ak@muc.de \
    --cc=ikebe.takashi@lab.ntt.co.jp \
    --cc=linux-kernel@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