Date: Fri, 03 May 2002 09:50:14 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: "M. Warner Losh" <imp@village.org> Cc: jhb@FreeBSD.ORG, tlambert2@mindspring.com, arch@FreeBSD.ORG Subject: Re: savcore dump names? Message-ID: <12088.1020412214@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 02 May 2002 21:40:36 MDT." <20020502.214036.88733477.imp@village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20020502.214036.88733477.imp@village.org>, "M. Warner Losh" writes:
>In message: <XFMail.20020502182336.jhb@FreeBSD.org>
> John Baldwin <jhb@FreeBSD.ORG> writes:
>: IMO, it is unacceptable to come in and break stuff and then say it's
>: not your problem to fix it.
>
>I'd tend to agree you and terry on this. If this work can't be capped
>off such that people can use it, then it should be backed out.
>
>>From the rest of the thread, it looks like there are two complaints
>here? One that the dump names are now insane, and two that it doesn't
>work on some systems (eg you can't take a kernel dump on alpha). Is
>that correct, or am I missing something?
re 1. That the names are "insane" is a matter of taste, not of
functionality.
re 2. I have asked for somebody with an alpha to help me but received
exactly zero replies.
And now, Poul-Hennings perspective:
We had a number of diskdrivers which had dump facilities.
All of these implemented in the diskdriver a dump method which was
only applicable to certain architectures and which in particular
were not applicable to sparc64 and ia64.
The layout of stuff in the dump on the disk is an obvious MD piece
of code that should not live in disk drivers.
So I cleaned this up, I changed the driver dump support to be just
"write this data on disk" and moved the layout stuff to a MD file
in i386 and asked for helpers to get it working on other archs.
Peter persuaded me that corrupt and partial dumps were a significant
problem, so for that reason and for general multi-arch sanity I
added a dump header on the media, which amongst other things record
information about the dump so that a MI savecore could pull out the
dump without even running on the same kernel or even architecture.
Then I wrote a savecore which pulled out a dump that way, and noted
that I didn't really have time to do this properly, and would like
to get assistance from some anyone interested.
One of the first things which happens was that marcel jumps in and
implements dump support on ia64. This would not have been possible
without my work.
Next thing is that DES raises a stink about his uncommitted patches,
but lets leave that saga out of the story for now.
What happens after that can best be described as "A number of people
spend far more time whining and bitching about the userinterface
to a trivial user-land program than it would have taken them to
implement anything they have whined about and then some".
For goodness sake people, savecore is only marginally more complex
than hello.c! Several people have submitted patches for it. Why
doesn't anybody just commit the shit instead of whining ?
All the hypocritical whining about removing things or leaving them
half broken coming from people like Terry who talks and talks and
talks and talks and talks but never actually _do_ anything can be
stuffed up where the sun only shines when you pick strawberries
without clothes on: Sometimes a forward stride starts with a
backwards step.
Remember SMPng ? It started out by totally disabling the spl*()
priority protection in the kernel.
If people spent more time coding than whining, imagine what we could
do.
And as for the MII changes: The patch was posted and announced, if you
havn't tested it: do so or shut up.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12088.1020412214>