lkml.org 
[lkml]   [2005]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Fastboot] Re: [RFC/PATCH 0/17][Kdump] Overview

Vivek, perhaps a little more context about the background of the
changes would have helped here. Not everyone has been following
the details of fastboot/kdump discussion for the last few months.

Let me give this a try - Eric/Vivek please pitch in and correct me,
where I go wrong since even I haven't been that tightly plugged
in all the time.

Sometime back kexec underwent a major redesign in some respect. This
was mainly in terms of the division of responsibilities between the
kernel and user-space kexec-tools. For kdump in particular this also
had to do with the real groundwork being set for better integration
into kexec mainstream, and a more reliable and cleaner interface between
what happens in kexec-tools, in the old kernel's context and in the
new kernel's context. On the whole, a better world for all :)

However, at that time, when this new revamped kexec was integrated
into -mm, the corresponding kdump redesign was still pending -- which
is why the *old* crash dump patches in -mm were kind of irrelevant
and broken because they hadn't caught up with the kexec revamp. Which
is also why kdump wasn't being tested on -mm ... it didn't even work !

Sorting this all out is really what I see Vivek's latest patches being
intended for -- and I believe it is the outcome of the work that has
been happening on fastboot over the last several months ?
This is why, I guess, it made sense for him to take the route of
throwing out most of the old patches and starting afresh with new
ones, because these are *built* on a different foundation altogether,
so incremental patches would have been rather confusing.

This should not be a continuing trend from here on (I hope not
at least, since major revamps are quite costly on stability !),
so shouldn't be a cause for worry. The bullet has been bitten. From
here on, changes must be incremental.

Regards
Suparna

On Tue, Mar 29, 2005 at 10:29:13AM +0530, Vivek Goyal wrote:
> On Mon, 2005-03-28 at 17:48 -0800, Andrew Morton wrote:
> > Vivek Goyal <vgoyal@in.ibm.com> wrote:
> > >
> > > Following patches (as in series file) need to be dropped before applying
> > > the fresh ones.
> > >
> > > crashdump-documentation.patch
> > > crashdump-memory-preserving-reboot-using-kexec.patch
> > > crashdump-routines-for-copying-dump-pages.patch
> > > crashdump-routines-for-copying-dump-pages-fixes.patch
> > > crashdump-elf-format-dump-file-access.patch
> > > crashdump-linear-raw-format-dump-file-access.patch
> > > crashdump-linear-raw-format-dump-file-access-coding-style.patch
> >
> > At some point we should stop tossing out patches and replacing them in this
> > manner.
>
>
> Andrew, I shall take care of sending incremental patches only next time
> onwards. The reason why I did this because changes were relatively large
> and I thought dropping the existing series and replacing it with new
> series (some patches retaining the old name) might be a better idea.
>
>
> > Because doing so makes it hard for people to see what has changed.
> >
> > It makes it hard for people to see that changes in the above patches
> > haven't been simply lost.
> >
> > And the fact that you were probably working against some kernel other than
> > -mm gives little confidence that the kdump development team have been
> > testing the patches which are presently in -mm. And that is what they are
> > there for.
> >
> >
> >
>

> _______________________________________________
> fastboot mailing list
> fastboot@lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/fastboot


--
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Lab, India

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-06 13:31    [W:0.043 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site