Masashige Kotani wrote:
>
> > I guess what I mean is more like the following:
> >
> > Assume there are multiple dump devices in /dev:
> >
> > /dev/dump/dump0 (major 227, minor 0)
> > /dev/dump/dump1 (major 227, minor 1)
> > /dev/dump/dumpN (major 227, minor N)
> >
> > All of these are configurable via open() and ioctl(), and each can have
> > their own individual dumping strategies based on configuration. For
> > example, let's say /dev/dump/dump0 is configured with dump method A,
> > RLE compression, and is non-disruptive. /dev/dump/dump1 is configured
> > with dump method B (let's say it's Mission Critical Linux's MCLX crash
> > utility), no compression, and is disruptive. Etc., etc., etc.
> >
> > Each can be triggered via dprobes, or a system crash, SysRQ, or
> > any other mechanism.
> >
> > As far as dump methods are concerned, we'd take dump_execute() and
> > turn it into a dump method launch. So, if it gets called, it walks
> > through the dump methods and determines which one to execute based
> > on what is configured. The final step is to make each dump method
> > a module rather than something statically built into the kernel.
> > This eliminates the need for massive dump overhead in the kernel
> > code -- each module can do its own thing with respect to method,
> > compression, etc. It can even determine whether it wants the kernel
> > to go silent or not (like what IBM's trying to do).
> >
> > So, 'lsmod' might show:
> >
> > [root@watereye /root]# lsmod
> > Module Size Used by
> > dump_rle 1104 0 (unused)
> > dump_gzip 8906 0 (unused)
> > dump_method_lkcd 89712 0 (unused)
> > dump_method_mclx 22319 0 (unused)
> > dump 17248 0 [dump_rle]
>
> Are the method modules and the compress modules used
> two or more in once dumping?
Yes -- as they can be launched under different circumstances. Vamsi
at IBM has come up with what I think to be a pretty cool way to get
us to dump methods (using a kernel thread). I hope he can send off
some comments on this.
> > So a dump method module, when loaded, can then be used by a dump
> > device for crashing. The only complexity is writing a nice user
> > utility that configures how crashing is performed, and loads all
> > the right modules for you (or sets them up to load).
> >
> > Does this make any sense at all? :) What do you think?
> > Anyone have any thoughts on this?
>
> I didn't imagine such construction. Since it comes to be simply changed
> according to environment even if without rebuilding a kernel,
> I think that it becomes easy to use LKCD for user.
Definitely. Then it becomes a matter of coming up with user level
software to make dump configuration easy and clear.
> Thank you for detailed explanation.
Thanks, Masashige-san. If anyone else has comments, feel free to let
me know if this is way off base or not.
--Matt
> >
> > --Matt
> >
>
> --Masashige
|