From: Matt D. R. <ya...@ap...> - 2002-01-05 17:39:45
|
To address Andreas' and Suparna's concerns about 4.0.1, I totally agree. I just wanted to start opening up the dialogue for 2.5 while at the same time pursuing the work on 4.X. I suspect we'll continue to have multiple 4.X releases over the coming months, as I don't think vendors will be moving to 2.5 anytime soon. I'll start work on this on Monday. I've been away from LKCD and lots of other things over the holidays, but I'm pretty much back now. LinuxWorldExpo LKCD slides are done, and I can get back to coding now. :) I'll send out a "bug set" -- the items I think are left to fix for 4.0.1 -- once I go through the last set of patches I've received. I know Bharata just sent a patch to this list, and Tony's sent me at least one patch that must go in. Beyond that, knowing Pete's ia64 and Andreas' s390{,x} issues are okay, then we can snap and release. And _then_ I'll move to the 2.5 tree, so we have a common base to compare against. :) Sound good? --Matt On Thu, 3 Jan 2002, Suparna Bhattacharya wrote: |>Hello Matt, |> |>Nice beginning for a new year :) |>Yes, I think its a good idea to have this mailing list. And to start making |>all those discussions and visions turn into reality. |> |>But before we move on to 2.5 and all the new stuff, could we focus on |>closing out on a working 4.01 release (good to have it for a more recent |>kernel, if possible), so that it can be used as a stable base for future |>work ? There are multiple patches/fixes in there which haven't made it to |>users, because they aren't in an official release.The code in cvs tree |>probably still doesn't work for all architectures (390 and x86, yes, but |>not clear about the others) since per-CPU register & stack snapshot support |>is currently implemented only for x86, a quick solution. A quick solution |>as Bharata had suggested would be to do the same thing as in the 390 case |>for all other architectures (i..e make the arch specific function |>kl_fix_vaddr essentially a nop which just returns the same address that is |>passed to it, for all architectures other than x86). Does that sound |>reasonable ? I'm not sure if Pete wanted to do things differently for ia64, |>in terms of adding the necessary kernel support. |> |>In any case, it would be nice if we could sort this out soon, so we can |>make a clean start for the 2.5 work. |> |>Regards |>Suparna |> |> Suparna Bhattacharya |> Linux Technology Center |> IBM Software Lab, India |> E-mail : bsu...@in... |> Phone : 91-80-5044961 |> |> |> |> |> "Matt D. Robinson" |> <ya...@ap...> To: <lkc...@li...> |> Sent by: cc: Matt Robinson <ya...@ap...> |> lkc...@li...urc Subject: [lkcd-devel] New E-mail List: |> eforge.net lkcd-devel |> |> |> 01/03/02 03:35 PM |> |> |> |> |> |> |>Hi, everyone. |> |>I apologize if I've placed you on this list, and you would |>prefer not to be ... I went through a number of posts and tried |>to narrow down those people in the LKCD community that are doing |>some type of LKCD development, and would probably be interested |>in providing more direct/detailed feedback, thoughts, code, |>suggestions, or banter on current and future development details. |> |>I was ready to start sending off some code to the LKCD general |>mailing list when I realized a number of people out there may not |>want to start into those discussions (code-wise). General |>direction is okay, but I didn't want to start spamming patches, |>code, etc., to people that don't want to have it in their mailboxes |>(and don't filter the stuff). |> |>If you don't want to be on this list, let me know and I can unsubscribe |>you. If I've left someone off, please add them or let me know who to |>add. I'll send off an E-mail to the main lkcd-general list after I hear |>back from a few of you tomorrow on your thoughts about this list. If |>it's a good thing, I'll invite others on lkcd-general, making it clear |>what this list is intended for. |> |>The first thing on the agenda is the 2.5 structure and mechanisms |>for dumping. We've spent a lot of time talking/writing on it, now |>it's about time to move the tree forward, finish any design details |>and get into the implementation of this beast. This is also an |>opportunity to re-structure lcrash to deal with multiple dump |>types, and maybe add tie-ins to some of IBM's LTC code to provide |>a more cohesive RAS package. |> |>I also have to fix a couple of bugs that came in during the end |>of 2001 (Tony, I have your E-mail and I still have to fix your |>bug). |> |>Thanks, all. Let me know what you think. |> |>--Matt |> |> |>_______________________________________________ |>lkcd-devel mailing list |>lkc...@li... |>https://lists.sourceforge.net/lists/listinfo/lkcd-devel |> |> |> |> |>_______________________________________________ |>lkcd-devel mailing list |>lkc...@li... |>https://lists.sourceforge.net/lists/listinfo/lkcd-devel |> |