Hi Bernhard,
2007/07/19 01:10:50 +0200, Bernhard Walle <[EMAIL PROTECTED]> wrote:
>[1] didn't we agree to vmcoreinfo?
I agree to vmcoreinfo.
I'll rename makedumpfile's config file to "vmcoreinfo".
Thanks
Ken'ichi Ohmichi
-
To unsubscribe from this list: send the line "unsubscribe
Hi Dan,
2007/07/23 16:02:39 +0300, Dan Aloni <[EMAIL PROTECTED]> wrote:
>> Dan Aloni, I'd like to cooperate with you for implementing this feature.
>> If you have some patches other than 2007/07/10 patches, could you send
>> me them ? I will update them.
>
>Sure, though I haven't made new
Hi Dan,
2007/07/23 16:02:39 +0300, Dan Aloni [EMAIL PROTECTED] wrote:
Dan Aloni, I'd like to cooperate with you for implementing this feature.
If you have some patches other than 2007/07/10 patches, could you send
me them ? I will update them.
Sure, though I haven't made new patches (was
Hi Bernhard,
2007/07/19 01:10:50 +0200, Bernhard Walle [EMAIL PROTECTED] wrote:
[1] didn't we agree to vmcoreinfo?
I agree to vmcoreinfo.
I'll rename makedumpfile's config file to vmcoreinfo.
Thanks
Ken'ichi Ohmichi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Mon, Jul 23, 2007 at 04:02:39PM +0300, Dan Aloni wrote:
> On Mon, Jul 23, 2007 at 08:47:23PM +0900, Ken'ichi Ohmichi wrote:
> >
> > Hi,
> >
> > 2007/07/23 10:31:47 +0530, Vivek Goyal <[EMAIL PROTECTED]> wrote:
> [..]
> > >
> > >I am also in favour of a complete kernel based solution. Export
On Mon, Jul 23, 2007 at 08:47:23PM +0900, Ken'ichi Ohmichi wrote:
>
> Hi,
>
> 2007/07/23 10:31:47 +0530, Vivek Goyal <[EMAIL PROTECTED]> wrote:
[..]
> >
> >I am also in favour of a complete kernel based solution. Export required
> >info from kernel and let kexec-tools parse that info, pass it to
Hi,
2007/07/23 10:31:47 +0530, Vivek Goyal <[EMAIL PROTECTED]> wrote:
>On Thu, Jul 19, 2007 at 12:39:15PM -0400, Don Zickus wrote:
>[..]
>>
>> I am not a big fan of this approach as it forces distros to require
>> kexec-tools when building a kernel. Even Joe Hacker who wants a custom
>> kernel
Hi,
2007/07/23 10:31:47 +0530, Vivek Goyal [EMAIL PROTECTED] wrote:
On Thu, Jul 19, 2007 at 12:39:15PM -0400, Don Zickus wrote:
[..]
I am not a big fan of this approach as it forces distros to require
kexec-tools when building a kernel. Even Joe Hacker who wants a custom
kernel (and not
On Mon, Jul 23, 2007 at 08:47:23PM +0900, Ken'ichi Ohmichi wrote:
Hi,
2007/07/23 10:31:47 +0530, Vivek Goyal [EMAIL PROTECTED] wrote:
[..]
I am also in favour of a complete kernel based solution. Export required
info from kernel and let kexec-tools parse that info, pass it to second
On Mon, Jul 23, 2007 at 04:02:39PM +0300, Dan Aloni wrote:
On Mon, Jul 23, 2007 at 08:47:23PM +0900, Ken'ichi Ohmichi wrote:
Hi,
2007/07/23 10:31:47 +0530, Vivek Goyal [EMAIL PROTECTED] wrote:
[..]
I am also in favour of a complete kernel based solution. Export required
info
On Thu, Jul 19, 2007 at 12:39:15PM -0400, Don Zickus wrote:
[..]
>
> I am not a big fan of this approach as it forces distros to require
> kexec-tools when building a kernel. Even Joe Hacker who wants a custom
> kernel (and not interested in kexec) would have to not only download the
>
On Thu, Jul 19, 2007 at 12:39:15PM -0400, Don Zickus wrote:
[..]
I am not a big fan of this approach as it forces distros to require
kexec-tools when building a kernel. Even Joe Hacker who wants a custom
kernel (and not interested in kexec) would have to not only download the
kernel.src.rpm
On Thu, Jul 19, 2007 at 06:49:53PM +0200, Bernhard Walle wrote:
> * Don Zickus <[EMAIL PROTECTED]> [2007-07-19 18:39]:
> >
> > I am not a big fan of this approach as it forces distros to require
> > kexec-tools when building a kernel. Even Joe Hacker who wants a custom
> > kernel (and not
* Don Zickus <[EMAIL PROTECTED]> [2007-07-19 18:39]:
>
> I am not a big fan of this approach as it forces distros to require
> kexec-tools when building a kernel. Even Joe Hacker who wants a custom
> kernel (and not interested in kexec) would have to not only download the
> kernel.src.rpm but
On Wed, Jul 18, 2007 at 11:07:40PM +0900, Ken'ichi Ohmichi wrote:
> The content of mkdfinfo file has been increasing whenever adding
> features and correcting bugs. The content is increasing even now.
> And, the feature addition is done not only for new kernels but also
> for old upstream kernels.
On Wed, Jul 18, 2007 at 11:07:40PM +0900, Ken'ichi Ohmichi wrote:
>
> Hi,
>
> 2007/07/16 18:06:33 +0530, Vivek Goyal <[EMAIL PROTECTED]> wrote:
> >On Mon, Jul 16, 2007 at 02:28:54PM +0200, Bernhard Walle wrote:
> >> * Vivek Goyal <[EMAIL PROTECTED]> [2007-07-16 14:25]:
> >> >
> >> > Ok. Now
On Wed, Jul 18, 2007 at 11:07:40PM +0900, Ken'ichi Ohmichi wrote:
Hi,
2007/07/16 18:06:33 +0530, Vivek Goyal [EMAIL PROTECTED] wrote:
On Mon, Jul 16, 2007 at 02:28:54PM +0200, Bernhard Walle wrote:
* Vivek Goyal [EMAIL PROTECTED] [2007-07-16 14:25]:
Ok. Now there seems to be two
On Wed, Jul 18, 2007 at 11:07:40PM +0900, Ken'ichi Ohmichi wrote:
The content of mkdfinfo file has been increasing whenever adding
features and correcting bugs. The content is increasing even now.
And, the feature addition is done not only for new kernels but also
for old upstream kernels.
* Don Zickus [EMAIL PROTECTED] [2007-07-19 18:39]:
I am not a big fan of this approach as it forces distros to require
kexec-tools when building a kernel. Even Joe Hacker who wants a custom
kernel (and not interested in kexec) would have to not only download the
kernel.src.rpm but
On Thu, Jul 19, 2007 at 06:49:53PM +0200, Bernhard Walle wrote:
* Don Zickus [EMAIL PROTECTED] [2007-07-19 18:39]:
I am not a big fan of this approach as it forces distros to require
kexec-tools when building a kernel. Even Joe Hacker who wants a custom
kernel (and not interested in
Hello,
* Ken'ichi Ohmichi <[EMAIL PROTECTED]> [2007-07-18 16:07]:
> I propose the solution including Dan's, Vivek's and Bernhard's opinions.
> How about the following sequence for distributors ?
> (It is not necessary to rebuild 2nd-kernel initrd even if 1st-kernel changes.
> A new option
Hi,
2007/07/16 18:06:33 +0530, Vivek Goyal <[EMAIL PROTECTED]> wrote:
>On Mon, Jul 16, 2007 at 02:28:54PM +0200, Bernhard Walle wrote:
>> * Vivek Goyal <[EMAIL PROTECTED]> [2007-07-16 14:25]:
>> >
>> > Ok. Now there seems to be two ways for accessing such info.
>> > - Through global variables
Hi,
2007/07/16 18:06:33 +0530, Vivek Goyal [EMAIL PROTECTED] wrote:
On Mon, Jul 16, 2007 at 02:28:54PM +0200, Bernhard Walle wrote:
* Vivek Goyal [EMAIL PROTECTED] [2007-07-16 14:25]:
Ok. Now there seems to be two ways for accessing such info.
- Through global variables
- Export
Hello,
* Ken'ichi Ohmichi [EMAIL PROTECTED] [2007-07-18 16:07]:
I propose the solution including Dan's, Vivek's and Bernhard's opinions.
How about the following sequence for distributors ?
(It is not necessary to rebuild 2nd-kernel initrd even if 1st-kernel changes.
A new option --mkdfinfo
* Vivek Goyal <[EMAIL PROTECTED]> [2007-07-17 05:50]:
>
> Thinking more about it. These config variables are accessible in user
> space in first kernel through sysconf() interface. In that case kexec
> can pack required config variables into an ELF note and kernel does not
> have to intervene.
* Vivek Goyal [EMAIL PROTECTED] [2007-07-17 05:50]:
Thinking more about it. These config variables are accessible in user
space in first kernel through sysconf() interface. In that case kexec
can pack required config variables into an ELF note and kernel does not
have to intervene.
That's a
On Mon, Jul 16, 2007 at 01:57:07PM +0200, Bernhard Walle wrote:
> * Vivek Goyal <[EMAIL PROTECTED]> [2007-07-16 06:19]:
> > On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote:
> > > * Ken'ichi Ohmichi <[EMAIL PROTECTED]> [2007-07-13 13:05]:
> > > >
> > > > BTW, I'd like to remove
On Mon, Jul 16, 2007 at 02:28:54PM +0200, Bernhard Walle wrote:
> * Vivek Goyal <[EMAIL PROTECTED]> [2007-07-16 14:25]:
> >
> > Ok. Now there seems to be two ways for accessing such info.
> > - Through global variables
> > - Export through ELF notes.
> >
> > Personally, I like the approach taken
* Vivek Goyal <[EMAIL PROTECTED]> [2007-07-16 14:25]:
>
> Ok. Now there seems to be two ways for accessing such info.
> - Through global variables
> - Export through ELF notes.
>
> Personally, I like the approach taken by Dan Aloni of exporting required
> info through ELF notes. That seems to be
* Vivek Goyal <[EMAIL PROTECTED]> [2007-07-16 14:25]:
>
> Ok. Now there seems to be two ways for accessing such info.
> - Through global variables
> - Export through ELF notes.
>
> Personally, I like the approach taken by Dan Aloni of exporting required
> info through ELF notes. That seems to be
On Mon, Jul 16, 2007 at 01:57:07PM +0200, Bernhard Walle wrote:
> * Vivek Goyal <[EMAIL PROTECTED]> [2007-07-16 06:19]:
> > On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote:
> > > * Ken'ichi Ohmichi <[EMAIL PROTECTED]> [2007-07-13 13:05]:
> > > >
> > > > BTW, I'd like to remove
* Vivek Goyal <[EMAIL PROTECTED]> [2007-07-16 06:19]:
> On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote:
> > * Ken'ichi Ohmichi <[EMAIL PROTECTED]> [2007-07-13 13:05]:
> > >
> > > BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
> > > While 2nd-kernel is running, new
* Vivek Goyal [EMAIL PROTECTED] [2007-07-16 06:19]:
On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote:
* Ken'ichi Ohmichi [EMAIL PROTECTED] [2007-07-13 13:05]:
BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
While 2nd-kernel is running, new makedumpfile comes to
On Mon, Jul 16, 2007 at 01:57:07PM +0200, Bernhard Walle wrote:
* Vivek Goyal [EMAIL PROTECTED] [2007-07-16 06:19]:
On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote:
* Ken'ichi Ohmichi [EMAIL PROTECTED] [2007-07-13 13:05]:
BTW, I'd like to remove PAGESIZE from a
* Vivek Goyal [EMAIL PROTECTED] [2007-07-16 14:25]:
Ok. Now there seems to be two ways for accessing such info.
- Through global variables
- Export through ELF notes.
Personally, I like the approach taken by Dan Aloni of exporting required
info through ELF notes. That seems to be more
* Vivek Goyal [EMAIL PROTECTED] [2007-07-16 14:25]:
Ok. Now there seems to be two ways for accessing such info.
- Through global variables
- Export through ELF notes.
Personally, I like the approach taken by Dan Aloni of exporting required
info through ELF notes. That seems to be more
On Mon, Jul 16, 2007 at 02:28:54PM +0200, Bernhard Walle wrote:
* Vivek Goyal [EMAIL PROTECTED] [2007-07-16 14:25]:
Ok. Now there seems to be two ways for accessing such info.
- Through global variables
- Export through ELF notes.
Personally, I like the approach taken by Dan Aloni
On Mon, Jul 16, 2007 at 01:57:07PM +0200, Bernhard Walle wrote:
* Vivek Goyal [EMAIL PROTECTED] [2007-07-16 06:19]:
On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote:
* Ken'ichi Ohmichi [EMAIL PROTECTED] [2007-07-13 13:05]:
BTW, I'd like to remove PAGESIZE from a
On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote:
> * Ken'ichi Ohmichi <[EMAIL PROTECTED]> [2007-07-13 13:05]:
> >
> > BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
> > While 2nd-kernel is running, new makedumpfile comes to consider
> > 2nd-kernel PAGESIZE as 1st-kernel
On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote:
* Ken'ichi Ohmichi [EMAIL PROTECTED] [2007-07-13 13:05]:
BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
While 2nd-kernel is running, new makedumpfile comes to consider
2nd-kernel PAGESIZE as 1st-kernel PAGESIZE
* Ken'ichi Ohmichi <[EMAIL PROTECTED]> [2007-07-13 13:05]:
>
> BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
> While 2nd-kernel is running, new makedumpfile comes to consider
> 2nd-kernel PAGESIZE as 1st-kernel PAGESIZE without getting PAGESIZE
> from a mkdfinfo file.
I don't think
Hi all,
2007/07/10 08:02:43 -0400, Neil Horman <[EMAIL PROTECTED]> wrote:
>> Besides Dan's plan, I'm planning the change of CONFIGFILE for distributors.
>> In the kernel building process, distributors need to make CONFIGFILE
>> on an older kernel (ex. RHEL5 kernel is built on RHEL4), and
* Vivek Goyal <[EMAIL PROTECTED]> [2007-07-13 05:58]:
> Given the fact that more and more architectures are supporting multiple
> page sizes. Now one can also export relevant kernel CONFIG variables
> through this ELF note. makedumpfile's job will be simpler. You don't have
> to make any guesses
* Vivek Goyal [EMAIL PROTECTED] [2007-07-13 05:58]:
Given the fact that more and more architectures are supporting multiple
page sizes. Now one can also export relevant kernel CONFIG variables
through this ELF note. makedumpfile's job will be simpler. You don't have
to make any guesses about
* Ken'ichi Ohmichi [EMAIL PROTECTED] [2007-07-13 13:05]:
BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
While 2nd-kernel is running, new makedumpfile comes to consider
2nd-kernel PAGESIZE as 1st-kernel PAGESIZE without getting PAGESIZE
from a mkdfinfo file.
I don't think that's a
Hi all,
2007/07/10 08:02:43 -0400, Neil Horman [EMAIL PROTECTED] wrote:
Besides Dan's plan, I'm planning the change of CONFIGFILE for distributors.
In the kernel building process, distributors need to make CONFIGFILE
on an older kernel (ex. RHEL5 kernel is built on RHEL4), and OSRELEASE
may
On Wed, Jul 11, 2007 at 10:43:04PM +0900, Ken'ichi Ohmichi wrote:
>
> Hi Dan,
>
> 2007/07/11 10:32:16 +0300, Dan Aloni <[EMAIL PROTECTED]> wrote:
> >> This implementation looks interesting. No need of debug compiled
> >> vmlinux for dump filtering purposes. No run time vmlinux binary
> >>
On Wed, Jul 11, 2007 at 10:32:16AM +0300, Dan Aloni wrote:
[..]
> > This implementation looks interesting. No need of debug compiled
> > vmlinux for dump filtering purposes. No run time vmlinux binary
> > modifications
> > as suggested by your previous mails. People can export kernel CONFIG info
On Wed, Jul 11, 2007 at 10:43:04PM +0900, Ken'ichi Ohmichi wrote:
Hi Dan,
2007/07/11 10:32:16 +0300, Dan Aloni [EMAIL PROTECTED] wrote:
This implementation looks interesting. No need of debug compiled
vmlinux for dump filtering purposes. No run time vmlinux binary
modifications
as
On Wed, Jul 11, 2007 at 10:32:16AM +0300, Dan Aloni wrote:
[..]
This implementation looks interesting. No need of debug compiled
vmlinux for dump filtering purposes. No run time vmlinux binary
modifications
as suggested by your previous mails. People can export kernel CONFIG info
like
Hi Dan,
2007/07/11 10:32:16 +0300, Dan Aloni <[EMAIL PROTECTED]> wrote:
>> This implementation looks interesting. No need of debug compiled
>> vmlinux for dump filtering purposes. No run time vmlinux binary modifications
>> as suggested by your previous mails. People can export kernel CONFIG
On Tue, Jul 10, 2007 at 11:36:45PM +0300, Dan Aloni wrote:
> On Tue, Jul 10, 2007 at 03:00:09PM -0400, Neil Horman wrote:
> > On Tue, Jul 10, 2007 at 08:35:41PM +0300, Dan Aloni wrote:
> >[...]
> > >
> > > Isn't there some sort of a circular dependency going on here? As I
> > > understand it the
* Vivek Goyal <[EMAIL PROTECTED]> [2007-07-11 08:07]:
> On Tue, Jul 10, 2007 at 07:52:01PM +0300, Dan Aloni wrote:
> > On Tue, Jul 10, 2007 at 08:09:04AM -0400, Neil Horman wrote:
> > > On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> > > > On Fri, Jul 06, 2007 at 05:58:04PM +0300,
On Wed, Jul 11, 2007 at 11:37:26AM +0530, Vivek Goyal wrote:
> On Tue, Jul 10, 2007 at 07:52:01PM +0300, Dan Aloni wrote:
> > On Tue, Jul 10, 2007 at 08:09:04AM -0400, Neil Horman wrote:
> > > On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> > > > On Fri, Jul 06, 2007 at 05:58:04PM
On Tue, Jul 10, 2007 at 07:52:01PM +0300, Dan Aloni wrote:
> On Tue, Jul 10, 2007 at 08:09:04AM -0400, Neil Horman wrote:
> > On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> > > On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > > > On Fri, Jul 06, 2007 at 03:28:14PM
On Tue, Jul 10, 2007 at 07:52:01PM +0300, Dan Aloni wrote:
On Tue, Jul 10, 2007 at 08:09:04AM -0400, Neil Horman wrote:
On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
On Fri, Jul 06, 2007 at 03:28:14PM +0200,
On Wed, Jul 11, 2007 at 11:37:26AM +0530, Vivek Goyal wrote:
On Tue, Jul 10, 2007 at 07:52:01PM +0300, Dan Aloni wrote:
On Tue, Jul 10, 2007 at 08:09:04AM -0400, Neil Horman wrote:
On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan
* Vivek Goyal [EMAIL PROTECTED] [2007-07-11 08:07]:
On Tue, Jul 10, 2007 at 07:52:01PM +0300, Dan Aloni wrote:
On Tue, Jul 10, 2007 at 08:09:04AM -0400, Neil Horman wrote:
On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni
On Tue, Jul 10, 2007 at 11:36:45PM +0300, Dan Aloni wrote:
On Tue, Jul 10, 2007 at 03:00:09PM -0400, Neil Horman wrote:
On Tue, Jul 10, 2007 at 08:35:41PM +0300, Dan Aloni wrote:
[...]
Isn't there some sort of a circular dependency going on here? As I
understand it the vmlinux
Hi Dan,
2007/07/11 10:32:16 +0300, Dan Aloni [EMAIL PROTECTED] wrote:
This implementation looks interesting. No need of debug compiled
vmlinux for dump filtering purposes. No run time vmlinux binary modifications
as suggested by your previous mails. People can export kernel CONFIG info
like
On Tue, Jul 10, 2007 at 03:00:09PM -0400, Neil Horman wrote:
> On Tue, Jul 10, 2007 at 08:35:41PM +0300, Dan Aloni wrote:
>[...]
> >
> > Isn't there some sort of a circular dependency going on here? As I
> > understand it the vmlinux binary already contains the initramfs as
> > built-in data
On Tue, Jul 10, 2007 at 08:35:41PM +0300, Dan Aloni wrote:
> On Tue, Jul 10, 2007 at 01:17:40PM -0400, Neil Horman wrote:
> > On Tue, Jul 10, 2007 at 08:30:37PM +0530, Vivek Goyal wrote:
> > > I am still thinking that why can't we change initrd building process
> > > (Be it mkinitrd or mkdumprd
On Tue, Jul 10, 2007 at 08:35:41PM +0300, Dan Aloni wrote:
> On Tue, Jul 10, 2007 at 01:17:40PM -0400, Neil Horman wrote:
> > On Tue, Jul 10, 2007 at 08:30:37PM +0530, Vivek Goyal wrote:
> > > I am still thinking that why can't we change initrd building process
> > > (Be it mkinitrd or mkdumprd
On Tue, Jul 10, 2007 at 01:17:40PM -0400, Neil Horman wrote:
> On Tue, Jul 10, 2007 at 08:30:37PM +0530, Vivek Goyal wrote:
> > I am still thinking that why can't we change initrd building process
> > (Be it mkinitrd or mkdumprd depending on distriution). Whole idea is
> > that while building an
On Tue, Jul 10, 2007 at 08:30:37PM +0530, Vivek Goyal wrote:
> On Mon, Jul 09, 2007 at 02:41:31PM +0300, Dan Aloni wrote:
> >
> > I don't think it would add much complexity to build process as it
> > is now, just like the other tools that transparently do post-linking
> > modifications. As far
On Tue, Jul 10, 2007 at 08:09:04AM -0400, Neil Horman wrote:
> On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> > On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > > On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > > > Hello,
[...]
> > > It contains
On Mon, Jul 09, 2007 at 02:41:31PM +0300, Dan Aloni wrote:
>
> I don't think it would add much complexity to build process as it
> is now, just like the other tools that transparently do post-linking
> modifications. As far as the developer is concerned, there's just
> the vmlinux and/or
Hello,
* Dan Aloni <[EMAIL PROTECTED]> [2007-07-10 06:45]:
> > >
> > > Not exactly. Let me describe the procedure in greater detail.
> > > Basically, it would go like this:
> > >
> > > 1.
> > > 2.
> > > 3. embed_configfile /proc/kcore.info /vmlinux-kdump
> > > 4. kexec -l vmlinux-kdump <>
* Neil Horman <[EMAIL PROTECTED]> [2007-07-10 14:12]:
> On Tue, Jul 10, 2007 at 11:14:14AM +0300, Dan Aloni wrote:
> > On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> > > On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > > >
> > >[..]
> > > > It contains enough
* Vivek Goyal <[EMAIL PROTECTED]> [2007-07-10 08:36]:
> > does anybody know a _reliable_ way to determine the version the kernel
> > that produced a vmcore file? This means not scanning for a specific
> > string or something like that which can fail on random memory.
> >
> > Would it make sense
Hi,
* Ken'ichi Ohmichi <[EMAIL PROTECTED]> [2007-07-10 05:13]:
> Plan 1:
> A new option [--osrelease="string"] is added.
> The OSRELEASE of CONFIGFILE is overwritten by "string".
> In the kernel building process, distributors should specify "string"
> as the building kernel version.
>
>
On Tue, Jul 10, 2007 at 11:14:14AM +0300, Dan Aloni wrote:
> On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> > On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > >
> >[..]
> > > It contains enough information in order to make a compact kernel
> > > dump (makedumpinfo
On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > > Hello,
> > >
> > > does anybody know a _reliable_ way to determine the version the kernel
> > > that
On Tue, Jul 10, 2007 at 12:13:15PM +0900, Ken'ichi Ohmichi wrote:
>
> Hi,
>
> On Fri, 6 Jul 2007 17:58:04 +0300, Dan Aloni <[EMAIL PROTECTED]> wrote:
> > On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > > Hello,
> > >
> > > does anybody know a _reliable_ way to determine the
On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> >
>[..]
> > It contains enough information in order to make a compact kernel
> > dump (makedumpinfo needs to go over the struct page arrays). As
> > you see, it also
On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > Hello,
> >
> > does anybody know a _reliable_ way to determine the version the kernel
> > that produced a vmcore file? This means not scanning for a specific
> > string
On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> Hello,
>
> does anybody know a _reliable_ way to determine the version the kernel
> that produced a vmcore file? This means not scanning for a specific
> string or something like that which can fail on random memory.
>
> Would it
On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
Hello,
does anybody know a _reliable_ way to determine the version the kernel
that produced a vmcore file? This means not scanning for a specific
string or something like that which can fail on random memory.
Would it make
On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
Hello,
does anybody know a _reliable_ way to determine the version the kernel
that produced a vmcore file? This means not scanning for a specific
string or
On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
[..]
It contains enough information in order to make a compact kernel
dump (makedumpinfo needs to go over the struct page arrays). As
you see, it also contains the
On Tue, Jul 10, 2007 at 12:13:15PM +0900, Ken'ichi Ohmichi wrote:
Hi,
On Fri, 6 Jul 2007 17:58:04 +0300, Dan Aloni [EMAIL PROTECTED] wrote:
On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
Hello,
does anybody know a _reliable_ way to determine the version the
On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
Hello,
does anybody know a _reliable_ way to determine the version the kernel
that produced a
On Tue, Jul 10, 2007 at 11:14:14AM +0300, Dan Aloni wrote:
On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
[..]
It contains enough information in order to make a compact kernel
dump (makedumpinfo needs to go over
Hi,
* Ken'ichi Ohmichi [EMAIL PROTECTED] [2007-07-10 05:13]:
Plan 1:
A new option [--osrelease=string] is added.
The OSRELEASE of CONFIGFILE is overwritten by string.
In the kernel building process, distributors should specify string
as the building kernel version.
Plan2:
* Vivek Goyal [EMAIL PROTECTED] [2007-07-10 08:36]:
does anybody know a _reliable_ way to determine the version the kernel
that produced a vmcore file? This means not scanning for a specific
string or something like that which can fail on random memory.
Would it make sense to add a ELF
* Neil Horman [EMAIL PROTECTED] [2007-07-10 14:12]:
On Tue, Jul 10, 2007 at 11:14:14AM +0300, Dan Aloni wrote:
On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
[..]
It contains enough information in order to
Hello,
* Dan Aloni [EMAIL PROTECTED] [2007-07-10 06:45]:
Not exactly. Let me describe the procedure in greater detail.
Basically, it would go like this:
1. normal bootloader boot
2. normal initramfs
3. embed_configfile /proc/kcore.info /vmlinux-kdump
4. kexec -l
On Mon, Jul 09, 2007 at 02:41:31PM +0300, Dan Aloni wrote:
I don't think it would add much complexity to build process as it
is now, just like the other tools that transparently do post-linking
modifications. As far as the developer is concerned, there's just
the vmlinux and/or bzImage
On Tue, Jul 10, 2007 at 08:09:04AM -0400, Neil Horman wrote:
On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
Hello,
[...]
It contains enough
On Tue, Jul 10, 2007 at 08:30:37PM +0530, Vivek Goyal wrote:
On Mon, Jul 09, 2007 at 02:41:31PM +0300, Dan Aloni wrote:
I don't think it would add much complexity to build process as it
is now, just like the other tools that transparently do post-linking
modifications. As far as the
On Tue, Jul 10, 2007 at 01:17:40PM -0400, Neil Horman wrote:
On Tue, Jul 10, 2007 at 08:30:37PM +0530, Vivek Goyal wrote:
I am still thinking that why can't we change initrd building process
(Be it mkinitrd or mkdumprd depending on distriution). Whole idea is
that while building an
On Tue, Jul 10, 2007 at 08:35:41PM +0300, Dan Aloni wrote:
On Tue, Jul 10, 2007 at 01:17:40PM -0400, Neil Horman wrote:
On Tue, Jul 10, 2007 at 08:30:37PM +0530, Vivek Goyal wrote:
I am still thinking that why can't we change initrd building process
(Be it mkinitrd or mkdumprd depending
On Tue, Jul 10, 2007 at 08:35:41PM +0300, Dan Aloni wrote:
On Tue, Jul 10, 2007 at 01:17:40PM -0400, Neil Horman wrote:
On Tue, Jul 10, 2007 at 08:30:37PM +0530, Vivek Goyal wrote:
I am still thinking that why can't we change initrd building process
(Be it mkinitrd or mkdumprd depending
On Tue, Jul 10, 2007 at 03:00:09PM -0400, Neil Horman wrote:
On Tue, Jul 10, 2007 at 08:35:41PM +0300, Dan Aloni wrote:
[...]
Isn't there some sort of a circular dependency going on here? As I
understand it the vmlinux binary already contains the initramfs as
built-in data (at least
On Mon, Jul 09, 2007 at 10:49:38PM +0200, Bernhard Walle wrote:
> Hi,
>
> * Dan Aloni <[EMAIL PROTECTED]> [2007-07-09 13:41]:
> > > > A patch that I am working on will make it possible to integrate
> > > > the output of 'makedumpinfo -g' into vmlinux as the final build
> > > > stage of the
Hi,
On Fri, 6 Jul 2007 17:58:04 +0300, Dan Aloni <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > Hello,
> >
> > does anybody know a _reliable_ way to determine the version the kernel
> > that produced a vmcore file? This means not scanning for a
Hi,
* Dan Aloni <[EMAIL PROTECTED]> [2007-07-09 13:41]:
> > > A patch that I am working on will make it possible to integrate
> > > the output of 'makedumpinfo -g' into vmlinux as the final build
> > > stage of the kernel. This information will be presented itself
> > > as /proc/kcore.info for
On Mon, Jul 09, 2007 at 11:21:54AM +0200, Bernhard Walle wrote:
> Hello,
>
> * Dan Aloni <[EMAIL PROTECTED]> [2007-07-06 16:58]:
> >
> > Redhat has a makedumpinfo util which they intend to use as slim
> > kernel-version-independent utility on kdump rootfs in order to
> > save /proc/vmcore in a
Hello,
* Dan Aloni <[EMAIL PROTECTED]> [2007-07-06 16:58]:
>
> Redhat has a makedumpinfo util which they intend to use as slim
> kernel-version-independent utility on kdump rootfs in order to
> save /proc/vmcore in a compact manner.
I think you mean makedumpfile, don't you?
> A patch that I am
Hello,
* Dan Aloni [EMAIL PROTECTED] [2007-07-06 16:58]:
Redhat has a makedumpinfo util which they intend to use as slim
kernel-version-independent utility on kdump rootfs in order to
save /proc/vmcore in a compact manner.
I think you mean makedumpfile, don't you?
A patch that I am
1 - 100 of 108 matches
Mail list logo
