LKCD (Re: velikost swap odilu)

Ladislav Dobias Lada na Dobias.info
Neděle Duben 13 09:16:10 CEST 2003


Ahoj.

On Sat, 12 Apr 2003, Ladislav Dobias wrote:

> To, ze tuto vlastnost nemame ve standardnim Linuxu,
> nadavejte Linusovi :-) Ten rika, ze to nema cenu davat do
> jadra Linuxu, protoze nejsou poradne automatizovane
> analyzatory. A ze je to pry zalezitost Linuxovych vendoru,
> ktery to chteji zakaznikovi nabidnout jako soucast
> enterprise sluzeb...

Jeste bych chtel pridat neco z archivu linux-kernel, aby
jste nemuseli prohledavat archiv sami. Je to trochu delsi...

Dumpovaci mechanismus se da najit v patchi, a nazyva se
LKCD - Linux Kernel Crash Dumping, lze nalezt na URL:
  http://lkcd.sourceforge.net/download/latest/
a zde je, co si o tom mysli Linus Torvalds:

==========================================================
Date: Wed, 30 Oct 2002 18:31:36 -0800 (PST)
From: Linus Torvalds <torvalds na transmeta.com>
To: Rusty Russell <rusty na rustcorp.com.au>
Cc: linux-kernel na vger.kernel.org
Subject: Re: What's left over.

:
> Crash Dumping (LKCD)

This is definitely a vendor-driven thing. I don't believe it has any
relevance unless vendors actively support it.
:
==========================================================
Date: Wed, 30 Oct 2002 22:25:46 -0800 (PST)
From: Matt D. Robinson <yakker na aparity.com>
To: Linus Torvalds <torvalds na transmeta.com>
Cc: Rusty Russell <rusty na rustcorp.com.au>, linux-kernel na vger.kernel.org,
     lkcd-general na lists.sourceforge.net, lkcd-devel na lists.sourceforge.net
Subject: Re: What's left over.

Linus Torvalds wrote:
> > Crash Dumping (LKCD)
>
> This is definitely a vendor-driven thing. I don't believe it has any
> relevance unless vendors actively support it.

There are people within IBM in Germany, India and England, as well as
a number of companies (Intel, NEC, Hitachi, Fujitsu), as well as SGI
that are PAID to support this.  In addition, Global Services at IBM
uses this as a front-line method for resolving customer problems.
If you're looking for names of people to sign up to support it
(both vendors and non-vendors), I can make that list up for you.

There are a number of us (developers, support staff, and other
interested parties) who bend over backwards, day in and day out
to make sure this stuff works and helps people, even if it isn't
kernel developers (directly -- indirectly, you get bug reports that
are sane and useful).

It's not sexy kernel stuff, but it is very important, and if you'd
like, I can have representatives from at least 10 major corporations
(Fortune 500 companies) contact you to request that this go in.

We're generating 2.5.45 patches now, and we ask that you include
the patches when they are posted.

I don't know what else to say except that people really want this
stuff and all of us in the LKCD community work really hard together
to make this project useful for everyone.

Please include this in your next snapshot.

--Matt

P.S.  Copying some of the users and developers.
==========================================================
Date: Thu, 31 Oct 2002 07:46:08 -0800 (PST)
From: Linus Torvalds <torvalds na transmeta.com>
To: Matt D. Robinson <yakker na aparity.com>
Cc: Rusty Russell <rusty na rustcorp.com.au>, linux-kernel na vger.kernel.org,
     lkcd-general na lists.sourceforge.net, lkcd-devel na lists.sourceforge.net
Subject: Re: What's left over.


On Wed, 30 Oct 2002, Matt D. Robinson wrote:

> Linus Torvalds wrote:
> > > Crash Dumping (LKCD)
> >
> > This is definitely a vendor-driven thing. I don't believe it has any
> > relevance unless vendors actively support it.
>
> There are people within IBM in Germany, India and England, as well as
> a number of companies (Intel, NEC, Hitachi, Fujitsu), as well as SGI
> that are PAID to support this.

That's fine. And since they are paid to support it, they can apply the
patches.

What I'm saying by "vendor driven" is that it has no relevance for the
standard kernel, and since it has no relevance to that, then I have no
incentives to merge it. The crash dump is only useful with people who
actively look at the dumps, and I don't know _anybody_ outside of the
specialized vendors you mention who actually do that.

I will merge it when there are real users who want it - usually as a
result of having gotten used to it through a vendor who supports it. (And
by "support" I do not mean "maintain the patches", but "actively uses it"
to work out the users problems or whatever).

Horse before the cart and all that thing.

People have to realize that my kernel is not for random new features. The
stuff I consider important are things that people use on their own, or
stuff that is the base for other work. Quite often I want vendors to merge
patches _they_ care about long long before I will merge them (examples of
this are quite common, things like reiserfs and ext3 etc).

THAT is what I mean by vendor-driven. If vendors decide they really want
the patches, and I actually start seeing noises on linux-kernel or getting
requests for it being merged from _users_ rather than developers, then
that means that the vendor is on to something.

                Linus
==========================================================
Date: Thu, 31 Oct 2002 12:10:20 -0500 (EST)
From: Patrick Finnegan <pat na purdueriots.com>
To: linux-kernel na vger.kernel.org, lkcd-general na lists.sourceforge.net,
    lkcd-devel na lists.sourceforge.net
Subject: Re: What's left over.

On Thu, 31 Oct 2002, Linus Torvalds wrote:

>
> On Wed, 30 Oct 2002, Matt D. Robinson wrote:
>
> > Linus Torvalds wrote:
> > > > Crash Dumping (LKCD)
> > >
> > > This is definitely a vendor-driven thing. I don't believe it has any
> > > relevance unless vendors actively support it.
> >
> > There are people within IBM in Germany, India and England, as well as
> > a number of companies (Intel, NEC, Hitachi, Fujitsu), as well as SGI
> > that are PAID to support this.

To add to that list, here at Purdue University, we actively look at crash
dumps on other architectures, such as IBM AIX, and are starting to do the
same on Linux machines, after discovery of LKCD.

> What I'm saying by "vendor driven" is that it has no relevance for the
> standard kernel, and since it has no relevance to that, then I have no
> incentives to merge it. The crash dump is only useful with people who
> actively look at the dumps, and I don't know _anybody_ outside of the
> specialized vendors you mention who actually do that.

This has much relevance for the standard kernel, as much relevance as gdb
has for people using applications.  While a majority of non-techno-geek
end-users probably don't care about the patch, I'm certain that there are
plenty of organizations out there like Purdue that WANT lkcd to become a
standard part of the Linux kernel.   Until then, we're forced to do our
own kernel patching every time we push out a new kernel.

> I will merge it when there are real users who want it - usually as a
> result of having gotten used to it through a vendor who supports it. (And
> by "support" I do not mean "maintain the patches", but "actively uses it"
> to work out the users problems or whatever).

We actively use it.

> People have to realize that my kernel is not for random new features. The
> stuff I consider important are things that people use on their own, or
> stuff that is the base for other work. Quite often I want vendors to merge
> patches _they_ care about long long before I will merge them (examples of
> this are quite common, things like reiserfs and ext3 etc).

LKCD isn't a 'random new feature'.  It's something that is present in
nearly ever other "Unix" on the market. (Yes I know Unix != Linux).  It's
a feature that should have been integrated by now IMHO.

> THAT is what I mean by vendor-driven. If vendors decide they really want
> the patches, and I actually start seeing noises on linux-kernel or getting
> requests for it being merged from _users_ rather than developers, then
> that means that the vendor is on to something.

Again, we're the end-user, not the vendor, and we're trying to drive to
have it included.  I've talked with outher sys admins in my department
here at Purdue, and have gotten a unanimous response that "It would be a
good and useful feature to have."

Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu

==========================================================
Date: Thu, 31 Oct 2002 09:25:21 -0800 (PST)
From: Linus Torvalds <torvalds na transmeta.com>
To: Matt D. Robinson <yakker na aparity.com>
Cc: Rusty Russell <rusty na rustcorp.com.au>, linux-kernel na vger.kernel.org,
     lkcd-general na lists.sourceforge.net, lkcd-devel na lists.sourceforge.net
Subject: Re: What's left over.

[ Ok, this is a really serious email. If you don't get it, don't bother
  emailing me. Instead, think about it for an hour, and if you still don't
  get it, ask somebody you know to explain it to you. ]

On Thu, 31 Oct 2002, Matt D. Robinson wrote:
>
> Sure, but why should they have to?  What technical reason is there
> for not including it, Linus?

There are many:

 - bloat kills:

        My job is saying "NO!"

        In other words: the question is never EVER "Why shouldn't it be
        accepted?", but it is always "Why do we really not want to live
        without this?"

 - included features kill off (potentially better) projects.

        There's a big "inertia" to features. It's often better to keep
        features _off_ the standard kernel if they may end up being

        further developed in totally new directions.

        In particular when it comes to this project, I'm told about
        "netdump", which doesn't try to dump to a disk, but over the net.
        And quite frankly, my immediate reaction is to say "Hell, I
        _never_ want the dump touching my disk, but over the network
        sounds like a great idea".

To me this says "LKCD is stupid". Which means that I'm not going to apply
it, and I'm going to need some real reason to do so - ie being proven
wrong in the field.

(And don't get me wrong - I don't mind getting proven wrong. I change my
opinions the way some people change underwear. And I think that's ok).

> I completely don't understand your reasoning here.

Tough. That's YOUR problem.

                Linus
==========================================================
Date: Thu, 31 Oct 2002 09:54:54 -0800 (PST)
From: Linus Torvalds <torvalds na transmeta.com>
To: Matt D. Robinson <yakker na aparity.com>
Cc: Rusty Russell <rusty na rustcorp.com.au>, linux-kernel na vger.kernel.org,
     lkcd-general na lists.sourceforge.net, lkcd-devel na lists.sourceforge.net
Subject: Re: What's left over.


On Thu, 31 Oct 2002, Matt D. Robinson wrote:
>
> This isn't bloat.  If you want, it can be built as a module, and
> not as part of your kernel.  How can that be bloat?

I don't care one _whit_ about the size of the binary. I don't maintain
binaries, adn the binary can be gigabytes for all I care.

The only thing I care about is source code. So the "build it as a module
and it is not bloat" argument is a total nonsense thing as far as I'm
concerned.

Anyway, new code is always bloat to me, unless I see people using them.

Guys, why do you even bother trying to convince me? If you are right, you
will be able to convince other people, and that's the whole point of open
source.

Being "vendor-driven" is _not_ a bad thing. It only means that _I_ am not
personally convinced. I'm only one person.

                Linus
==========================================================
From: Linus Torvalds <torvalds na transmeta.com>
To: Chris Friesen <cfriesen na nortelnetworks.com>
Cc: Matt D. Robinson <yakker na aparity.com>,
     Rusty Russell <rusty na rustcorp.com.au>, linux-kernel na vger.kernel.org,
     lkcd-general na lists.sourceforge.net, lkcd-devel na lists.sourceforge.net
Subject: Re: What's left over.


On Thu, 31 Oct 2002, Chris Friesen wrote:
>
> How do you deal with netdump when your network driver is what caused the
> crash?

Actually, from a driver perspective, _the_ most likely driver to crash is
the disk driver.

That's from years of experience. The network drivers are a lot simpler,
the hardware is simpler and more standardized, and doesn't do as many
things. It's just plain _easier_ to write a network driver than a disk
driver.

Ask anybody who has done both.

But that's not the real issue. The real issue is that I have no personal
incentives to try to merge the thing, and as a result I think I'm the
wrong person to do so. I've told people over and over again that I think
this is a "vendor merge", and I'm fed up with people not _getting_ it.

Don't bother to ask me to merge the thing, that only makes me get even
more fed up with the whole discussion. This is open source, guys. Anybody
can merge it. Because I don't particularly believe in it doesn't mean that
it cannot be used. It only means that I want to see users flock to it and
show my beliefs wrong.

                Linus
==========================================================
Gratuluji tomu, kdo to vsechno precetl :-)

Doufam, ze uz vsichni chapou, proc se dava velikost
  swap = 2*RAM
:-)

Zdravi
Lada Dobias

--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  ##       ##   #####   #####                     ,v
  ##      ####  ##  ## ##O-O##       Ladislav DOBIAS
  ##     ##  ## ##  ## ## > ##      lada @ dobias.info
  ##     ###### ##  ## ## v ##      http://dobias.info
  ###### ##  ## #####   #####  Interests: Unix, TeX, music
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



Další informace o konferenci Linux